Entry 2: Recursion- The Ever Expanding Hole

   Ah the enigmatic recursion. I didn't know it, but I had oft experienced it as a youngling when placing two mirrors parallel to each other: the image of the mirror was the image in the reflection, and the image within that mirror in the reflection was the image within the reflection and on and on went a series of reflections, representing the infinite recursion caused by these two mirrors. When you search recursion in Google, it asks if you meant recursion- clicking it will lead you to the same place. Last year, curious about the then unfamiliar topic, I asked a friend if he could tell me a little bit about it. With a smirk on his face, he said, 'to know recursion, you gotta know recursion'. Ha. Ha. Ha. I laughed up all the jokes not fully knowing what they meant, which brings us to the now.
 
   Recursion, as defined by this novice computer scientist, is a function or object that calls upon itself to yield its output.To understand this, I like to picture my function as a square- when I call it, and it calls itself (through recursion) I go a layer deeper into it- visually, into a slightly smaller square right below. As long as I keep recursing, I'll go into deeper, smaller square layers. As a novice computer scientist, and regular homo sapien, this is not useful for two reasons: a) my function will never return a value, and is by that merit, futile and b) being in a pit of infinitely shrinking squares sounds no fun; if there was a hope that I would stop sinking, it would take me an awful long time to climb to the top(did I mention I was sinking along with my recursing function?).Considering the previous examples, I'd be stuck clicking on Google's 'did you mean recursion' until the sun exploded( assuming I am immortal), and I'd be asking my friend the same incessant question until the above also occurred. For this reason, I need base cases- points at which my function will stop recursing by returning a value. At the moment that I get a value, the layer above me uses it as its input, and I can climb the layers to the top to yield a final value. As this novice computer scientist has learned, to implement an effective recursive function, one must then determine the base cases (the point of STOP),what I like to call the recursive factor (by how much or how is the function sinking), and as with every function, the operations that need to be applied to it (standard stuff).

   Recursion is useful in that it allows the breakup of a problem into smaller subsets. In my brief experience with this topic, it has been most useful to evaluate nested lists, which I previously had to do with cleverly crafter for loops. Thus, recursion allows for much simpler, less cluttered code.

For all novice computer scientist out there, I instil some advice: patience is key to understanding this stuff -recursion is not for the faint of heart. If like me, you happen to be a regular homo sapien with pretty standard cognitive powers, be prepared to spend some time on it. Sharpening your climbing skills couldn't hurt either.

Entry 1: Object Oriented Programming - The Metaphor

  Object oriented programming(OOP): the name says it all. Essentially, it's a style of coding that treats data as objects. At first, it's relevance seemed trivial; and when my professor went over a paragraph getting us to pick verbs and adjectives to construct a specific class of object, it seemed comical (surely, grammar was superfluous in the world of coding). A little research, however, was enough to make me see its practicality and appreciate the metaphor-who knew computer scientists could be so poetic?

   To understand the metaphor, I first looked at individual objects- each contained a set of attributes and methods- the respective analogues to the adjectives and verbs that my professor was talking about. If I want to make a class called Gear, for instance, I have to fill it with attributes: number of cogs, diameter- to name a few- and methods: turn right, turn left. I can make varying instances of this Gear class and cause them to interact with each other, as long as I write the correct code, and hypothetically construct my own clock. This way, though my clock is abstract, in that I can't see it and it's strictly represented by data, I understand it in the same way that I do a physical clock: it is a series of interacting objects whose collective collaboration yields a final output.

  Thus, when considering complex programs, OPP is very useful in that it allows the user to break apart the code into its constituents- the objects from which its built up- and understand the code dynamically, according to sub-functions, rather than line per line. If a program utilizes various user defined objects, the integrity of the entire program's functionality is not jeopardized by examining one class at a time, while treating the others as 'intelligent' black boxes, thereby facilitating the process of debugging.
   
   In terms of inter-programmer coding, OPP is useful in that the underlying code behind user defined classes may be distinct without altering the surface characteristics of the final program's output. Thus, programs (and  abstract data types, whose semantics must remain the same but implementation differs) can be shared, and effectively modified by different users.

Introduction

Non boolean thoughts of wisdom: the true account of a novice computer scientist's first glance into the mind* of the machine.

(* This, of course, varying on which philosophical stance, you,reader of this esoteric blog, take on matters of the mind. For all you Descartes' out there, 'tis but a mere metaphor)