Object Oriented Programming (OOP) and Recursion

OOP is the practice of creating 'objects' that have associated attributes and functions known as methods. Instances of these objects interact with each other to form a program of some sort. This method of programming is almost integral with everything we use today. Main languages such as C#, PHP, and Python, all use OOP and OOP is used practically everywhere. Video games, websites, enterprise software, and many others, all use OOP as a foundation for their programming languages of choice. There really isn't much in the way of non-OOP languages in terms of front-end programming. Of course languages which focus on other things need different solutions to their problems, such as assemblers, but OOP, at least for most people, is the way to go.

Recursion, the practice of repeating things in a self-similar manner, is one of the most useful tool a programmer has at his disposal to shorten (and perhaps complicate or simplify) code. Recursion, unlike standard iteration, is able to reduce code down to very small and dense portions if necessary. Recursion is a powerful tool which lets one create small methods instead of large, iterative ones if the proper requirements are met (those that all require similar inputs and outputs, etc.). In general, recursion is a useful but not necessary method to some of the problems encountered while writing code.

Tour of Anne Hoy // Trial by Cheese

I've never been a fan of completing another person's work or debugging someone else's work. My ideas aren't there and I can only use them to fix or implement something into code someone else has already written. This particular worked out almost like that.

For this assignment we were given a large portion of code completed for most of the actual 'guts' of the assignment and had to make certain implementations which used these 'guts' in a very particular manner. I didn't exactly find this the easiest of things to do. I attempted to complete the assignment in its entirety but ultimately failed. I decided to procrastinate and only then realize that I don't function very well when under time pressure, at least when programming. Oh well. Better luck next time.

Pair Programming Model

Unlike when writing code on your own, the pair programming model seems to emphasize verbal expression of code and thorough understanding of ideas when writing code (even if it is simple to write). Usually, I'm not very hard pressed to understand my code but being able to express it verbally is a separate issue. Usually, I'd be able to express it through writing with comments in code and transferring that verbally isn't much more difficult, really. However, the real challenge is when either myself or my lab partner do not understand what the other wrote or is trying to write for the task at hand that is really comes into play.

In the academic world, I can see this system making sense. Grasp what you're writing and be sure you can explain it. Though I'll be pretty surprised if I find anyone working on enterprise software to be a pair programming model.