off-topic: Pokemon Yellow hack

I came across a video yesterday which I found frankly jaw-dropping. With the use of a Gameboy emulator and other purpose-made infrastructure, someone has managed to gain full control of the Gameboy using only legitimate moves in the game Pokemon Yellow.
In short, this hack uses a bug to corrupt the player's inventory, then places items in the inventory in a specific order based on their hexadecimal identity to spell out a short bootstrapping function in Gameboy machine code. Then, by switching the location of a pointer outside the limits of the corrupted inventory, the player forces the game to call his function.
After writing and executing another, more complex input function, the hack gains total control, and could conceivably run anything that could fit in the Gameboy's ~6KB of RAM.
All based on legal in-game moves. Ingenious and inspiring.

Video and additional explanation after the break.

MapReduce, term test results

First of all, I'm very pleased with my term test mark. The positive result has motivated me to keep working and studying diligently.
With that in mind, I've been thinking a little about map and reduce as discussed in lecture today, and it seems to me that either these are pretty simple concepts, or I'm missing some nuance present in their application (because I haven't tried to write any code using them yet). Hopefully I will get some practice, and gain some insight, in tomorrow's lab.
I don't have too much to say other than that; I'm anticipating some more interesting stuff will happen tomorrow.

Nov 13: Term test and thoughts on recursion

So, the term test this morning went as well as I possibly could have hoped. I consider this as much a stroke of luck as an effect of diligence, but I'm glad nonetheless. Though I feel comfortable, I don't want to grow complacent, so I am going to revisit A2 over the next week or two and attempt to find a full solution, due dates aside.
To flesh out this entry and in light of the content of the test, here are some general thoughts on recursion:
In short: seriously unintuitive, completely logical, difficult but workable. When recursion was first introduced earlier in the course I had some strange impressions: I found the examples given in lecture to be elegant and straightforward, but trying to apply the concepts in labs and exercises nigh on impossible. I suppose this is partly due to my previous follow-the-answer approach to authoring code - I tended to trace the execution in my head, because I hadn't come across anything complicated enough to make that impossible. After a few attempts at recursive reasoning this gave way to a more abstract view, considering only the actual datum/data a function would return and not how it had been computed. I feel like this change in perspective has seriously helped me as a programmer and will easily carry into new topics.
Cheers until tomorrow!

Nov 12: Term test prep

I'm a little nervous about tomorrow's term test. I've been reviewing lecture notes, code examples, lab worksheets and readings (whew, a veritable laundry list of stuff) but I'm concerned by the fact that I had a very bad time with assignment 2.
In terms of the concepts covered, I'm comfortable with linked lists, binary trees and search trees, recursion involving both of the above (in fact, this is perhaps the most straightforward application of recursion in my mind), sorting algorithms and big-oh notation. But the specific problem of binary regular expressions is still unclear to me, and if I had thought of it sooner I would spend a good chunk of time revisiting A2. For tonight, I will focus on my confidence with linked structures, and let the chips fall where they may on the rest. Good luck all!

Nov 11: Better late than never, object-oriented programming

Despite having badly neglected this slog, I intend to post daily about both old and new topics in the run up to the end of term. To start, I will write a little about object-oriented programming.

Though I'm no expert on programming languages, it seems to me that object orientation is a feature which allows a language exponentially more power (in one sense) than the alternative. The ability to define one's own functions and classes creates the potential for infinite abstraction, to the point where any higher-level problem can be solved with enough planning and code. While sometimes I find this abstraction very challenging to wrap my head around, the idea behind it is attractive. Furthermore, the simple modularity of this paradigm is aesthetically and logically pleasing. Though my aspiration as a programmer is to write code which is as modular and straightforward as OOP might seem to be inherently, I will sometimes attempt to solve problems by brute force or trial and error (I'm only human). To me, this is a shortcoming of OOP: it allows for lazy work to sometimes get the job done, where elsewhere more careful planning would be necessary (I imagine, again, I don't know much about other language types).

Thanks to this little meditation on OOP, I resolve going forward to plan out my code more carefully, from the top down.