W12: End of the Year!

Today was the last day of class!! CLASSES ARE OVER!!!

I'm so ecstatic that finally after all these hours, days and weeks of university, never-ending assignments and stress, that classes are finally over!! I'm also amazed at how fast the year has gone by... one year of university passed in a snap.

Still, despite how fast it went by, university certainly is NOT a snap (whoever says so is either not human or lying or in a bogus university, no offense). As a beginner in CS, I can't even describe how much I learned in CSC108 and CSC148. In September I'd barely touched coding, and in the past months I've done hours and hours of it, learning about syntax, exceptions and errors, object-oriented programming, recursion, lists and binary search trees and run-time. WOW!

Still, I think the most important thing I've learned is what computer science is about and furthermore, how much of it there is still to learn. I've barely stepped a toe onto the vast field of computer science. It's been an eyeopener to realize, also, that computer science is not at all about the computer; the more important thing is the programmer's ability to solve problems and translate their solution into code. I thought coming into university that the most difficult aspect would be learn the Python language and syntax. I was dead wrong. The computer can tell you where you've made a syntax error, but nobody can solve a problem for you (unfortunately).

Despite my difficulties with computer science (I definitely have a lot of studying to do for the exam), after this year I am certain I want to pursue a computer science POSt and career. The appeal with CS is that although it is challenging, it is also extremely rewarding. It engages the programmer by exercising their creativity, problem-solving skills and communication abilities. And the feeling you get once you finish a problem is unrivaled!

Thank you CS148 for showing me something I can see myself doing in the future. You were an extremely difficult course, but I learned a lot from you!

To end off this SLOG, a quote that I feel accurately sums up all of my realizations this year:

Accomplishment will prove to be a journey, not a destination. 
– Dwight Eisenhower

W11: Sorting and Efficiency

As with any real-life objects, sorting in computer science refers to the action or various steps of arranging objects into some logical order. It is also essential that a sorting algorithm is efficient; computer scientists want to achieve their goals in the most time-efficient manner. Thus, we are introduced with the concept of big-Oh and the issue of analyzing run-times.

What is Run-Time?

"Independent of hardware, programming language and random events" run-time refers to the number of steps that is required to complete a task. When analyzing the run-time of a program, we generally focus on the size n of a list. Consequently, as the size of a list changes, the run-time changes. The run-time of an algorithm is thus modeled as a function, with n as the independent variable and time as the dependent variable.

What is Big-Oh?

Even if a program's run-time is modeled as a function, the information is not very useful if the function is too complicated. Consequently, an upper bound on the run-time is needed. This is where big-Oh comes in. If function f is O(g), we say that the run time of f is like function g in the worst case. Why is this useful information, you ask? First, this allows us to simplify the run-time of a program (function g) so that the performance comes more intuitively. Second, computer programmers and their clients want to achieve their goal in the most efficient way and be certain about it. By providing the performance of code under the worst conditions, one makes a guarantee about your program (i.e. "it can't get any worse than that").

Not All Lists are Equal

When you think about the variables that may factor into a sorting algorithm's run-time, there are several things to consider:

> How large is the list? A smaller list will generally be sorted faster than a larger list.
> Is the list sorted? For some sorts, a sorted list requires very little work to be done.
> Is the list reverse sorted? For some sorts, a reverse sorted list is the worst-case.
> Maybe items in the list are in random order? You can consider this the average case.

Divide and Conquer!

In CSC108 we learned about bubble sort, insertion sort and selection sort. However, this term we've focused on a two new sorting algorithms (merge and quick sort) that use a method of dividing-and-conquering.

Recall the concept of dividing-and-conquering that was first introduced with binary search trees. By knowing whether a value is less than or greater than the root, the searcher can ignore half of the tree. Each time you go one level deeper into the tree, you split the tree in half and ignore one side. How many times you can split the tree is log n times. Thus, binary search is O(log n).

Similarly, merge sort and quick sort both split the given list and run recursively on the sublists. Thus the depth of recursive calls is log n. However, with each split of the list, every element in the sublist is compared. By adding up the size of the sublists, we naturally get a total of n comparisons. Thus by dividing and conquering, merge sort and quick sort (for a good pivot choice) run at O(n log n).

An Opportunistic Sort

Although dividing-and-conquering algorithms obviously run much better than linear and quadratic ones, the built-in sorting function in Python is even better. Called "timsort", the built-in sort begins by briefly looking at the list it is given. Depending on the circumstances, the algorithm will choose a different method of sorting the list.

Why is this important? First of all, with many algorithms in computer science, there is always a "special" case where the algorithm runs extremely well or terribly. One algorithm is never the best choice for every type of list. Methods like timsort thus better follow the human process of problem solving (as I have mentioned in older posts).

W11: Test Two

If the last test went badly, this one went even worse (and that's saying something).

Last time, although I procrastinated, in the end I still had a solid three days before the test to study. This time, I wasn't so lucky. On top of two other horrible tests last week, as well as a major group presentation... well, I was doomed.

I admit, the group presentation won out – not only was it a research project with an interesting topic, but if I failed to do my share of the work it would not have been pretty. At least if I fail to do the work for something of my own responsibility, it is only my problem. Nevertheless, after so much hard-work it was pretty much impossible to keep my inner procrastinator at bay. It was only two nights before the test that I really started to worry and make the connections to my Test One experience.

Major Mistakes

> Reading the tutorials and not re-doing them. They were very difficult... and the test was difficult too.
> Not working problems out on paper before attempting to code. I realized that computer science is not at all about the computer... it's about being able to problem-solve with your brain, and then translate that into code after the fact.
> Spending my last moments of studying typing up an aid sheet. Although the aid sheet was useful for the last test, this test which was all about writing new methods and functions. Thus, the aid sheet was useless. I kept it beneath my test paper for the whole 50 minutes of the test.

The only thing I can say for myself is that I think I had at least half an hour more sleep than last time.

W10: Sorting

This past week I missed the lectures, which were unfortunately about sorting algorithms and run times – my worst and least favorite topic from CSC108 and CSC165.

In addition to sorting algorithms we learned in CSC108, the prof talked about two new sorting methods in lecture: merge sort and quick sort. After reading through his slides a few times and sorting by hand a few short lists, I began to understand what the two sorts were. However, I didn't understand the run times that they had. Why were the run times for merge and quick sort both in O(n log n)? Are there n comparisons or log n comparisons? But apparently quick sort can have a quadratic run time if a bad pivot is chosen? I was extremely confused.

Thus, this post is not about detailing what bubble sort, insertion sort, selection sort, merge sort, quick sort, timsort and count sort do, but rather the tale of my self-learning.

When in trouble, always turn to Google.

At first, I read Wikipedia articles and other SLOG posts about sorting, but because I found the topic so dry I wasn't absorbing any of the information. Luckily however there are countless computer science videos on YouTube. I find myself someone that learns best when I someone is teaching me, so next to attending lecture videos were certainly the best option for me. With the help of some amazing YouTube channels, I was able to sort out my confusion. For merge sort and quick sort, there are log n splits of the list. However, with each sublist, each element in examined. Thus there are n examinations and log n splits, resulting in an O(n log n) run time. Pictures of merge sort were amazingly helpful also. Although I had worked out problems on paper, seeing very organized diagrams of the two sorts helped a great deal. 

Image of how a list is split by merge sort.

Retrieved from http://www.codenlearn.com/

For anybody reading this SLOG post, I highly recommend the following videos! I found these to be the clearest and most helpful.

Quicksort Explained

Sorting: Ep 09 Merge Sort

Merge Sort

And, for some odd reason, this extremely entertaining Hungarian Dance of quick sort!

Quick-sort with Hungarian (Küküllőmenti Legényes) Folk Dance

W10: A2, Next Test, Next Test, NEXT TEST?!

How I feel about computer science right now:

1) ECSTATIC!

I finished A2! After a week of assignments (which did not go very well) and tests (which also did not go very well) I was absolutely dreading working on A2 and forgoing much-needed rest. To be sure, it was tough and at times mind-boggling, but because A1 was a killer, I had been anticipating much worse. At first, I was intimidated by the heavy recursion that was required, but once I just got down and tackled the assignment (with some handy, old-school paper and pencil) it was a much smoother experience.

The most important thing I've realized from A2: usually the code follows very closely to the actual instructions. I spent an inordinate amount of time considering the rules of a valid regexes and how to convert the rules into code when the answers were under my nose the whole time. Having my code follow the instructions, step-by-step, made everything much more understandable.

2) That feeling of success... VICTORY! RELIEF!

Well, we finally got our results for A1 back and I'm so unbelievably relieved to have done well that I can't really put it into words. A1 was undoubtedly one of the most stressful and yet memorable challenges I've had in university so far (I was still debugging my code one minute before the deadline... I was about to have a heart attack then). And, like I mentioned above, it's nice to get something right on an evaluation for once.

3) Today is the first day of spring...!?

Well, first of all, this is Canada, so the change in seasons doesn't really apply. Nonetheless, it is rather astonishing that we're already in the last three weeks of the university year, not considering the exam period. Assignments and tests and exercises have been going by so fast and in such rapid succession that I haven't had time to contemplate the time. Especially with computer science, once I get drawn into a problem or challenge I can sit in front of the computer for ages. I haven't been outside at all today, and I only recognized it was "spring" when I saw the Google Doodle.

4) Back pains.

What I LOVE about computer science that I haven't gotten from any other subject is that I can get very immersed in solving CS problems, when for many other things my attention span is about five minutes. It is very interesting converting "physical" entities into objects that can be handled on the computer – for example, Trees, which can be drawn out (physically) and manipulated in Python.

What I HATE about computer science: the back pains. I'm happy I've accomplished my work for today but my back is screaming in protest. Exercise may be a good idea.

5) Next...

Next week I have a major presentation on the same day as the second term test for CSC148, and unfortunately I have not begun to work on the presentation, nor do I understand anything about sorting. Oh, and I also didn't do very well on the last test, so I really need to do well on this one.

WELL.
That's the university life, eh?

W9: BSTs

My weakness is working with binary search trees... there was a week back when I skimped on BSTs by telling myself I knew them well enough. Well, that was certainly a lie.

First, the tutorial this week was killer. I mean I pretty much sat there watching my tutorial partner do all the work, and then afterwards had my partner (and the TA) explain everything to me. Even when I got home and tried the tutorial again, I botched it.

My biggest challenge and frustration from this week came in lecture, where I might as well have listened to the prof speak ancient Greek when he was demonstrating how to delete a node from a BST.

Later, after rereading the lecture notes multiple times, I've been able to get only the gist of it. Basically, if the node has no children, you can simply delete it. If it has only a right or only a left child, you can delete the node and reattach the child with no issues. However if it has both children, you replace it with a) the greatest value in the left child or b) the smallest value in the right child. This way, the order of the BST is maintained.

Although I've gotten that much understanding from revisiting the lecture notes, the code for this method evades me. There is the _delete helper method and then the delete method? I am SO confused.

EDIT: I've been able to get some help on this, thankfully, although I'm certainly not confident enough to write my own delete or insert method.

W8: A2 pt.1

This week has been a crazy, hectic week, but nonetheless I am happy to say that I accomplished A2 pt.1!

After A1, I promised myself that I would start the next big assignment at least a week beforehand. However, when the due date (yesterday) crept up on me, I could feel the fear again. Thankfully however, A2 pt.1 was as the professors promised and not intended to be extremely challenging; it just required very thorough thinking and coding.

Unlike previous exercises, the focus of A2 pt.1 was clearly to get students to learn about designing classes and make their own design choices. Before this assignment, we mostly had classes handed to us that we had to put further work into. Building a class from scratch, however, is a completely different matter.

For me, the toughest part about A2 pt.1 was simply beginning. Since the assignment was all about design, I knew I needed to first design on paper the structure of my class, and then code for it. At first, I was unsure whether it should be something like a parent class, and then a star, bar, dot and leaf child class. It seemed a little odd to me that to build a tree, the user would have to use different constructors. And then how would the __repr__ method work? I also had to be careful with duplicating code, because that would be a major design flaw. This assignment really put into the light the difference between coding and designing a program. It's much more work making decisions and being sure that they are the correct ones!

W8: LinkedLists

Although it is confusing, I enjoyed learning the two methods of thinking about LinkedLists. However, while the distinction between the two methods seems crystal clear as the prof explains it in class, sitting alone before my computer, it suddenly becomes difficult to distinguish them.

So first, before I reflect on LinkedLists, a short note on the two methods (see link):

1) This is the "list within a list" structure, where a LinkedList has a "head" or "value" and the rest of it, which is also a LinkedList. A format like this is useful, because each list has is the same and so the same operations can be performed on them.

2) The "node and reference" structure, where a LinkedList is more like a chain. Each chain is node, that contains a value and a reference to the next node. This format is useful because a programmer doesn't delve layer by layer into the list, but rather jump from node to node.

Right now, I think I'm more familiar with the first method, just because we've been focusing a great deal on recursion and the nested lists idea goes way back to the first weeks of this semester. However, I'm getting the feeling that the prof leans more towards the second method, which I must admit, seems like it'd been easier if only I could master it.

Though I'm not quite there yet, I am slowly understanding both methods better (the lab tutorials are extremely challenging but informative). Also, did I mention how much I've come to appreciate tuple unpacking?! It comes back full force with LinkedLists, and finally I've understood why a programmer would do tuple unpacking rather than conventional line by line variable assignments. If you do separate variable assignments, its possible that a value (especially in a mutable class) has changed before you assign it. However, with tuple unpacking, the left side of the equation symbol is evaluated first, and then assigned to the right side. MAGIC!

W7: Recursion

To state it simply, recursion in computer programming is when a function calls itself. One might ask, like I did at first, how a recursive function is useful if its definition implies that it runs for eternity?

Trying to call an improperly written recursive function, for example:

    def f(x):
        return f(x)

will indeed get you:

    RuntimeError: maximum recursion depth exceeded.

Which basically means that Python apologizes for being unable to run the function infinitely. So the example above is not exactly a recursive function.

Good recursive functions will have two basic components. First, a "base case" which tells the computer what to do once a certain condition is met, and second, a "recursive step" where the function calls itself.

Consider the following example. Suppose you have jar containing two flavors of candy: mango and raspberry. You detest mango but love raspberry. You blindly pick out one piece of candy at a time. If it's raspberry, you eat it and walk off. If it's mango, you discard it, and reach again. If you reach the bottom of the jar, you walk off.

In this example, the function can be seen as you reaching into the candy jar. The base case is finding a raspberry candy, eating it, and walking off. Here, walking off the same as exiting the function and it also occurs if the jar is empty. The recursive step is finding a mango candy and reaching in the jar, again. This is the part where the function calls itself (i.e. you call on your arm to repeat the action).

As you can see from the example, the base case is equally as important as the recursive step. The base case is the entire purpose of the function and the recursive step is the means to get there. A bad base case is equally as detrimental as a faulty recursive step. Furthermore, although it is usually very easy to see when recursion is required (do you have to do the same thing multiple times?) it is not so easy to decide what exactly you want to get out of it.

It is apparent how useful recursion is in computer programming. A programmer may have something they want to achieve that will take several loops but they do not know exactly how many. Thus recursion is necessary:

    1) Recursion saves space by replacing the many lines of code for (regular) loops
    2) It is more readable and better follows the human process of problem-solving
    3) It can achieve something that may take zero loops or hundreds of loops.

The last point is especially demonstrated when working with objects such as Trees, where a Tree can be a single node or conversely hundreds upon hundreds of nodes and leafs. A single recursive function can, for example, count how many nodes there are in any type of Tree, no matter what size. Such cannot be achieved by a single regular function.

W7: Test One

I can't say that I studied very well for this first test, because even though I put effort into studying I only did so three days before of doomsday. However, I did feel like I knew the material decently well. I laboured over the labs, the exercises and (thought I did) pretty well on A1 (although we haven't really gotten marks back yet).

Except for linked lists and the linked implementation of a tree, I made sure I went through all practice code posted on the website. My downfall, however, came the night before. I spent a great deal of time studying the material, and left writing my aid sheet until yesterday night. Though I promised myself I would sleep at 12 am at the latest, the aid sheet took very long and lo and behold... I went to bed at 2:30.

Not smart.

Result: sitting in lecture this morning, 9:10 am, twitching from lack of sleep and nerves. The first few questions were perfectly fine for me... the last questions not so much. My test had one question about counting all the values beginning with "a" in a Tree... and somehow, because of my lack of sleep, I ended up interpreting that as returning True or False if all values began with "a". I finished the test with 20 minutes to spare and spent the rest of my good time re-reading the test. Then, in the last five minutes, I realized my mistake.

Oh the test was not fun.

Needless to say, my nerves and anxiety came back full force and I did not have enough time to fix my mistake and did extremely poorly on it...

Lesson learned: always sleep on time.

W6: DONE, DONE, DONE!

A1 IS DONE!!

I'm delighted to say that A1 was an extremely difficult assignment that challenged me but did not defeat me (of course, it has yet to be marked, so perhaps that cannot be said definitively at the moment). I learned a great deal about myself and computer science in general. Some are things I am happy to have discovered, others are things that bit me in the butt and so I will not forget them:

> Even if something seems impossible or confusing, try something (anything) anyways. If you sit around scratching your head you will not get anything done. Do something wrong, and work on it until it's right. It took me ages to figure out the M(n) function in for A1 step 5 because I stared at it without writing any code. If I had tried something sooner, I'm sure I'd have saved myself much stress.

> Don't leave those stupid "trailing whitespaces" at the end of lines. Unfortunately, writing code is not like writing in everyday English. If you leave a space before entering the next line – to be grammatically correct... but who cares about that – you WILL spend a mindless ten minutes deleting that "trailing whitespace" from HUNDREDS OF LINES OF CODE. Can you tell that I am very annoyed about this?

> To comment or not to comment? Earlier in the process of writing A1, I thought commenting was a waste of time, but I soon realized how difficult it was to decipher older code when A1 was such a long project. Not only was it useful to track my own train of thought and break down problems into simpler pieces, but I'm sure it will be useful for the TAs who mark my assignment. Especially since there were some solutions that I wrote in a round-about-way (forgive me if you're a TA who marked my assignment).

> Function is essential, but form is important too. On a day you are extremely sleep-deprived, stressed or anxious, you will regret not making your code readable and good-looking. It takes a few extra moments to put in those empty lines and spaces, but it's worth it if it makes coding less of a treasure-hunt.

> Last but certainly not least: assignments should be started more than one week before they are due. Unless, of course, one would like to sit in front of a computer for twelve hours straight on a Thursday and develop back aches, shaky hands and chicken-scratch handwriting on the following Friday. You would think a week is plenty of time, but for each step of A1, there was a lot of problem-solving and debugging involved.

I did also learn while doing this assignment that I have a lot of work to do in terms of understanding recursion. While I have no problem tracing calls on recursive functions, it's an entirely different story to build a recursive function. I spent many hours muddling through Tour.py due to my lack of understanding. Thankfully, reading week begins today and I have the opportunity to catch up on computer science (especially those readings) and the loads of other work that has stacked up in my other courses.

Well, even though I say that it remains to be seen whether the following days will be productive or... otherwise? Because, you know, it's the last week of the Olympics too...

HAVE A WONDERFUL READING WEEK EVERYBODY!

W6: SUCCESS!

For once it's past midnight and I've been productive. HURRAH!

I'M SUPER HAPPY! It's been a rough week and this assignment is super tough. I've been frustrated with trying to think of the problem in different ways that will make the coding work, and be efficient. Moreover, it's difficult to write so much code a keep track of where everything is, what it does, and make sure it's written with proper syntax and commenting.

I'm sleep deprived but I feel like I've overcome a good challenge!!

W5: Procrastination

12:49 am
Not doing anything but changing the design of this blog.

10:29 pm – next day
Watched a sad video and didn't finish homework.

1:18 am – the next, next day
I can't even blame this on the Olympics because I had plenty of time to be productive...

Summary of My Bad Week:
Due to the fact that I'm a major Olympic-holic, I must admit it's been pretty rough keeping away from the television... in fact I've been unsuccessful much of the time. Furthermore, while it's been wonderful that the professor has cleared up (and given some hints) about A1, it is not a confidence booster to realize you understand zilch of what he is talking about...

Procrastination is is a vicious cycle that makes me feel worse about the work I have to do (but I still have the Olympics to cheer me up!). I am EXTREMELY behind on my work, and feeling very not-confident about it. When I went back to redo some old tutorials, they took me an unnecessarily long amount of time. While it is a consolation that I was able to work through them slowly and fully understand the solutions in the end, my energy has been drained.

This basically sums up what I'm trying to tell myself to keep going:
"It is better to do the right problem the wrong way than the wrong problem the right way."
    - Richard Hamming

W5: The Most Difficult Thing

When learning a new language, the most difficult thing is to put all of your knowledge together, and with computer programming and computer science it is no different.

Which is why I currently have my lecture notes haphazardly sprawled across my desk and multiple, disorganized internet tabs of program examples from both CSC148 and CSC108.

Of course, A1 is mostly about recursion (more specifically, step 5), but unlike the previous exercises which focused on specific topics, the rest of A1 is about piecing together what we've learned in class:

> the proper way to build classes (make sure there are no floating functions!)
> ADTs (namely, Stacks and the lab tutorial, in which we learned removing and adding to the bottom of a stack is much more inefficient, and it would be assumed that the same goes for stacks of cheese)
> property control (I see many underscore-period combos in A1...)
> reusing functions and avoiding duplicate code (I'm still working on the organization of the functions and which ones are related)
> raising and catching Exceptions (it is an "IllegalMoveError" to add a larger cheese on a smaller one)
> is there inheritance and composition? If there is, I haven't gotten that far yet...

I'm sure there's some other component I'm missing, which is why I'm reading the A1 code multiple times over and then reading my notes in the same fashion, and then becoming doubly confused.

W5: Pet Peeve!

It's not like I'm anything close to a wizard when it comes to computer programming; I'm probably more like a quarter of a notch above beginner.

So, in terms of being a computer programmer, I should really focus on the practical skills but it really irks me when there are... aesthetic inconsistencies in code.

I HATE when code goes from using these quotation marks: """ to these ones: ''' (ahem, TOAHModel to ConsoleController, I'm looking at you). OR, double spaces between words! Whenever I see these I obsessively run through code and fix them.

So... that's the end of that rant. Back to actually improving my skills.

W4: Anne Hoy and Chinese Chess

One thing I've learned in university is that you have to find out how you learn best, and then do it. Unfortunately, I'm still lacking in the latter, but I would like to think that I (mostly) know how I learn best.

So, still confused after reading the A1 instructions a second time, I gave up on my language skills and decided to work-out my spatial ones.

I pulled out my ultimate weapon: a set of Chinese checkers.

Like its European counterpart, the pieces in Chinese checkers have ranks. But the most important feature for my purposes was that they are small, cylindrical blocks that stack well. My very own cheese rounds with different "sizes".

Playing Ann Hoy's game with four "stools" (other chess pieces flipped over), my best has been 7 cheeses in 25 moves.

Now the written instructions make much more, but not complete, sense. It feels nice to do something hands-on, especially when much of lecture is paying attention the professor (and usually, not even writing down very much because most of the content is examples of code).

To anybody else that's stuck: you just have to try something! Good luck to all of us for A1!

W4: Recursion... Uhh, What?

In the outline for SLOGs, it says that we'll be writing a post in recursion week 7. Honestly, right now I can't imagine understanding recursion enough to write a full out post on it.

Underneath the topic listings, there were the suggestions for weekly blog posts:

And I will easily answer questions several of the questions right here:

Something new I learned this week? That would be recursion.
What's something that frustrated me this week? Again, recursion.
How confident do you feel about material covered this week? Nil. Zilch. Not at all confident. AT ALL.
What was one of your achievements this week? I have had no achievements.
Ask, and then answer, some question you had about course content? I would if I knew enough about the topic to ask questions...

All jokes aside however, I am rather worried by recursion. By the professor's lengthy praise for the topic, I can tell that recursion is a major tool in the computer programming toolbox, and I'd better learn it fast.

While I understand the human process of going through a nested list and counting, I found it difficult at first to follow the prof's instructions on tracing. My first few tries at tracing, I traced every step to the bottom before I could condense the steps at the top-level.

EDIT: I've looked again at the code from lecture (depth of nested list, maximum in a nested list) which completely befuddled me in class. It helps, I find, to copy and paste the code into Python and try to understand each part of the code. Especially with the ternary if statements (which I am horrible at), it's useful to attempt to rewrite the function. If my rewritten function is faulty, I can look at the differences in code and eventually learn why each part is important.

W3: E2, A1, Help Me

This week I have three assignments and one test.

Next week I have two assignments, two quizzes and one test.

Not to mention it's a math test, which means I'm screwed.

If I was smart and learned from my past mistakes,

I would start E2 for 148 today.

Like, now.

If I wanted to be really smart I could start A1,

Especially since I didn't understand a word

Of what the prof mentioned about it in class.

But I have no motivation.

Help me.

W3: What is Object-Oriented Programming?

When I first heard the term “object-oriented programming” last semester in CSC108, I was confused as to what it meant and how it differed from the programming we had mostly been using thus far.

Over the winter break, I promised myself that I would review classes and be clear on the meaning of this phrase as it obviously would be important in the future. Alas, my self-discipline has never been strong and when the spring semester began I already felt behind.

Thankfully, the first reading posted for CSC148 explained object-oriented programming extremely clearly, even for a beginner like me. As opposed to procedural programming that creates functions to operate on data, object-oriented programming makes it easier to manage complex computer systems by creating objects in which both data and functionality are contained.

At first, this seemed like a small difference, but now after more exposure to object-oriented programming, I’m surprised at how significant this difference is. By defining objects and the methods that operate on them, a program better correlates with how humans mentally think about the world. In class, when we practiced reading a paragraph and recognizing a class, its attributes and methods, I was pleased at how methodical it was to translate the words into the outline of a computer program.

The example in lecture (class Point) was a concrete data type where the professor defined how it was to be implemented. However, abstract data types (or ADTs) which do not specify implementation – only operations and what they do – are useful because they can be written once and then stored in libraries for the use of many programmers in many different ways.

In lecture, I felt like I was doing a semi-good job of keeping up with the theory behind object-oriented programming, but when it came around to tutorials I was obviously lacking in my application skills. On the second lab day, the end of the exercise was to try and find a solution to make class Queue run faster. Although my partner and I got the solution, I still had to go home and think about it before I was clear on how the solution worked.

Likewise, I’m feeling frustrated with understanding inheritance. In one of the readings, inheritance is described as “the evil forest”. More specifically, it is when an object or class is based off another object or class. Thus, it allows for the reuse of code. For example, in class the IntStack subclass inherits from the Stack class but has been modified so that only integers can be pushed onto an IntStack.

On the other hand, inheritance can be a dangerous thing if it becomes too complex. With inheritance, the computer always checks for code in the subclass first and thus it’s possible for some code to never be executed depending on where it is placed. In lecture, the professor demonstrated this using Exceptions.

Although I did as recommended and played around with the code that was uploaded on the CSC148 site, I am still confused with what “try” and “except” mean. There are many variables to fool with (the order of the code, commenting, uncommenting, and “raise”) that I’m feeling lost with what the code means. Tomorrow in class, I will have to ask the professor to reiterate and clarify his words regarding inheritance.

Overall, three weeks in, I’m not feeling as behind as I thought I would – and I suppose this is a good thing – but at the same time I’m certainly lazy and dragging my feet regarding solidifying this new knowledge. Although the new material is interesting, I have to remember to review my old notes as well (and perhaps even rewrite them in the Python 3 format to familiarize myself with it). I also feel like I've been only skim reading the last assigned readings, thus leaving holes in my understanding of certain concepts, especially Exceptions and composition. Before the course moves on, I have to thoroughly review these readings.

W3: Property Control

This past week, we focused a great deal about property control in class. At first, being a new CS student I didn't understand why this was an important issue at all... not to mention I also didn't understand the professor's references to other programming languages as I've never worked with anything other than Python.

Consequently, I ended up doing a lot of at-home reading and research. First thing I realized: the "Code Like a Pythonista" link on the course website is not useful unless you like to torture yourself. In general, lengthy readings do nothing for my learning in CS. I've discovered that I just have to jump right into trying to solve a problem, and then go to the readings afterwards if I have difficulty articulating my ideas to myself. (I found that http://tomayko.com/writings/getters-setters-fuxors, which the prof posted online, was very helpful though. Scroll until you reach the section on getters in setters in Python, however.)

A major aspect in computer science is object oriented programming, which is basically creating classes in code that represent "objects" which can have methods performed on them. Objects have attributes which are what allow a programmer to manipulate said object.

In computer programming, somebody who knows how to find their way into the guts of a program has all the power. Consequently, the original coder uses property control to protect their ideas and intentions. A analogy would be something like the mail-slot in a door. Envelopes can be slipped in, but from the outside it is impossible to retrieve and/or change the mail.

Property control is somewhat the same. As a coder, you make it so that once an object's attributes are set, they cannot be changed and only viewed. Furthermore, they can be read without having to use the polite underscore prefix, for example: "attribute_name" instead of "_attribute_name." 

This is thanks to getters and setters. Although I won't get into the nitty-gritty of coding getters and setters, a getter is basically a function that returns the value of said attribute. A setter, on the other hand, is what the program looks at when someone tries to set an attribute. If the attribute has yet to be determined, the setter allows an outsider to do so. However, if the attribute value already exists, the program firmly rejects any changes.

While I see the important of property control, oddly enough we seem to have completely ignored it after learning it. Perhaps it's more important in actual client code, rather than assignments we submit for CSC148? 

W2: Greetings

Dear the worldwide web,

This is my first time as a blogger (or slogger) amongst you, so forgive me for any mishaps I may have as I test out Google's snazzy web-publishing tool. So far, so good (I admit to being immediately, slightly obsessed with the various design options, and made this post to see how my blog would look).

For anybody who came across my blog looking for content, feel free to ignore this post (but if you're reading this, that may be too late).