LinkedList domination

So this week was all about linked lists... From lectures to the lab, that's mostly what we did. And for some odd reason, I liked that we were almost exclusively focusing on linked lists. Reason? It's because I went from a stage of just beginning to learn about it, to understanding it, to using it, to being comfortable with it; just like everything to learn in this course as well as other courses should be. Once I felt I was good at writing linked list related code, I had fun. I realized this during our weekly lab when we had to write out a few functions for linked lists with the help of some already-written code of other similar functions. My partner and I finished the lab so quickly that I had over an hour or so to help out others with understanding and writing their code. It felt good to be back on top of things as I felt back in CSC108.
Unfortunately though, time is an issue that seems will be pressing me in the coming few days and weeks for the assignments and course material. I can already feel it...

Recursion

So we've been using recursion more often these days. Although it seemed a little intimidating at first, I think I've got the hang of it now. Scratch that, I confidently believe that I can use recursion to my advantage when coding nowadays. I have the constant practice during labs and exercises to thank for that; especially all the repetition. Till this day, I still use the mental approach that recursion is like a process where we have to infiltrate the deepest layer/level of the item we're recursively using and retrieve the "core"; or in more python related words, return the result we're looking for. Again, kinda like "Inception". Or maybe I just have a wild imagination. But to think, when starting this course, I was a worried I wouldn't be able to master recursion in time for this course. Not saying that I "mastered" it because I'm sure there is still much to learn and try out with recursion. I'd like to say that my progress with recursion gives me hope on understanding the more complicated topics that will be presented as we go through the rest of this course. Let's stay positive here shall we?

Weird lab instructions and still annoyed about the first assignment

Doing lab #5, my partner and I didn't have much trouble completing it. However, throughout the whole process of the lab, we were instructed many times to read over certain documents that were supposed to clear up concepts and aspects of the lab, which it did for the most part. One of those documents we had to read was about list comprehensions. This is exactly what I found odd: most students in this course (including myself) just learned about list comprehensions at the beginning of the semester during lecture; unless I am mistaken, there has not been a single lab where we were asked to use, practice and further understand list comprehensions. I mean, is that not the point of labs (especially with a term test just around the corner)? The instructions were specific in letting us know not to use list comprehensions, which would probably make writing the code much easier and more efficient (even though it would take us some time getting used to writing list comprehensions). In a course where efficiency and simplicity are key, I am still flustered at this.

On top of that, I am still very confused at the instructions that were provided for the first assignment. I admit, my partner and I did not start working on the assignment early enough (we were obviously too busy with other courses haha) but even then, only managing to solve the mysteries behind steps 1-4, we felt even more in the dark just reading the step 5 instructions. It never mentioned what direction we need to take or how exactly we needed to approach step 5. I really cannot wait to read the solutions to this assignment and laugh at how far fetch'd or how surprisingly simple the solutions might have been... Time and organization did get the best of us.

Struggles with the first assignment

This week we learned about the tower of Hanoi (or tower of Anne Hoy). It was an interesting "puzzle" sort of concept involving moving stacks of different size cheese (funny how we still speak of cheese even when programming). I didn't have much trouble understanding the whole concept behind how to solve getting the stack from one stool to another, even with the use of recursion.

Funny enough, assignment 1 turns out to mainly be about the Tower of Anne Hoy problem. You'd think then the assignment should be easy to get going and not confusing at all. Wrong. For some reason, this assignment felt like it was thrown at us like a big bundle of mess. Sure we're given steps for how to proceed in writing this program, but the number of files given to us as well as how unclear the use of each file and its contents is, makes the whole "getting started" part of the assignment very confusing. Of course, it could just be me. It may just be my fault for not re-reading carefully and analyzing the assignment properly. But I can also say this: I am not the only one who has mentioned they feel like we've been given a pile of junk to fix. I'm just hoping at this point my partner and I can get organized and figure this whole thing out before we run out of time (not to mention we both have a test for another course the day before due date). Still, I think we got this.

Recursion takes time, Inheritance doesn't and unittests are annoying

This week I found myself learning more about recursion. I see its uses but unfortunately I find myself still struggling a little to understand the process a recursion code goes through to complete itself. We went through the nested list example first which I think now, after lots of revising, I mostly understand the process. The second example we were given was called tree_burst. I feel like that one lost me on what it does exactly. I mean, I understand the recursion in it and the process the function goes through, but I don't quite get what the function does exactly. I don't know if its because maybe I was very tired that morning during 9am lecture or because the function seems very abstract unless you see it visually, but it may be something I have to revise and ask soon. On a side note, recursion reminds me of the movie Inception for some reason.

On the other hand, during our lab this week, we had to make use of inheritance on many occasions. Unlike recursion, I felt very comfortable with the use of this. It's a really simple concept that doesn't take very long to understand. Even with a different partner this week who missed the lecture on inheritance, we were able to finish all the tasks for the lab quickly enough and have my partner understand in a short amount of time the concept of inheritance. But if there was one thing that did frustrate us during the lab, it was unittest. For now, I am a firm believer that unittest is inefficient waste of time. Before we realized that we had to write a unittest to test our class and its functions, we tested our code ourselves manually and did so in much less time (and less typing) than writing and fixing up a unittest. Although neither of us were comfortable with unittests to begin with, I still find it is more time-consuming than just manually testing it (though this is probably because this is a relatively short code and might make more sense when testing huge stacks of code (so why give us this task for the lab in the first place)). I have yet to see someone prove me otherwise (which shouldn't take very long to do).

Object-Oriented Programming

Having programmed only in languages that are considered object-oriented languages (vb.net and python), I still find it difficult to visualize programming languages that do not fall under this category. If I understand correctly, object-oriented languages means the language focuses more on the creation of objects that contain characteristics that define it as well as having the objects provide certain functions. That makes sense and is easy to visualize. Then what about non-object-oriented programming? What exactly does one begin with creating in that case? What would be defined? It seems very abstract. Guess I'll have to find out one day and see for myself.

We recently have been going through useful features of object-oriented programming in our lectures on python such as inheritance and recursion (both of which I got the chance to touch on previously with vb.net). Its features like these that really distinguish object-oriented languages from other languages.Going back to the thought of imagining non-object-oriented programming as a really abstract concept, it really makes one think. But first things first, I've gotta make sure I get comfortable with recursion before moving on.