OBJECTS ORIENTED WITH PROGRAMMING POW

Python, though it is named after the delightful sketch comedy group, in essence actually best resembles the mythological monster which gave every other python (snake or comedian) its name.

Nonetheless, this Course bLOG (courSe bLOG is a lame name) begins with a little discussion of Object Oriented Programming [Stuff] (OOP[S]).

Dealing with this form of programming was a bit jarring at first. I had some experience with objects at first from the last semester's computer science class, but I was not out of the proverbial jungle yet. My old knowledge was simple and undeveloped. Now was the time to enhance.

Our first forays into OOP involved actually conceptualizing those very objects that we were to orient using programming. Points, turtles, graphs - nothing was safe. We drilled through it all. It was fast (and occasionally furious), but it made sense with the help of additional online information and the variety of painful educational exercises upon which we embarked.

So it came that we were building classes, which are really cool and useful. Extremely cool and useful. I like classes and objects a lot, and the magical combinations they create. Basically, we were developing a variety of classes based on what we had to complete (so for Point, we needed an n-dimensional point). This is the fun part, because we got to plow through what kinds of tools we should use to create the Point (at this point [ha ha] we were working with ADTs). The methods are fun and all, but what was fascinating is how logical and simple this process is. Much like how we organize our various tools for each problem we encounter in the regular world (for instance, if you're building IKEA furniture, you prepare to lift things, use the little allan-key thing, or screw stuff in). Python's OOP works the same, which was really refreshing to understand (given that I made the connection independently) and made it seem clear how we were supposed to approach these kinds of problems.

Actually writing methods was simple enough. We had done plenty of that in the past; albeit, without the conveniences of the classes. What was ultimately the most interesting about using objects was the way it organized development. If we wanted to develop a class that stored how a person did something complicated, like fill a spreadsheet, it was possible to do so. That was vastly daunting before as a pile of methods would have redundancies and ambiguities, but using classes we can signal what we want to do clearly and concisely in an organized way. It was heaven.

This week has nonetheless been an effort in compiling thoughts. The increased amount of abstraction is a boon and a curse: on the one hand, it gives us the possibility to develop code that is specific enough to accomplish our tasks (a class for a graph, for a restaurant menu, or for a calculator), but which also requires us to think about how we divide up the concepts (for the above examples: putting points or lines, adding meals or wine items, or adding mathematical operators). The topics we discussed in the lecture: developing superclasses or subclasses just bring the whole thing together. Now we can create even more specific functions within our code: a menu of operations for the graph, or a form of the calculator that only performs simple arithmetic (i.e. it can only compare two operands at a time). The power is almost overwhelming.

Ultimately, the first few experiences have felt disorienting and confusing at times -- but also really cool. It's clear that the way object oriented programming is going to work will be really useful for solving problems, in the sense that there is a giant pile of information before you, and you organize it into meaningful chunks which perform clear tasks. It's more cooperative, and it feels like I may be edging towards actually being able to finally build a program that will live my life for me and win fame and fortune in my stead. I can't wait.