Wednesday, 24 October 2012

Fun with Big Bang

In last week's lecture we continued our development of the barracuda clock, adding more functions to the big bang model. It's fascinating seeing all the concepts we've learned over the weeks slowly coming together as we try to develop very basic working programs.

As I worked through the Picturing Program exercises, I was intrigued by other ways in which you can use the Big Bang model. For example, suppose you want to create a square that starts at width length 10 and gets larger by the second.

; square-of-width : number (width) -> image

(check-expect (square-of-width 7)
                       (square 7 "solid" "red"))

(define square-of-width (square n "solid" "red"))

(big bang 15
       (check-with number?)
       (on-draw square-of-width 100 100)
       (on-tick add1 1))

This program creates a red square with side width 15 on a 100 by 100 window, and the square gets larger by the second!

I realize Dr. Racket is much more versatile than I originally thought. When you're willing to explore, the possibilities are endless. I'll be taking more time this week to play around with big bang.

Tuesday, 16 October 2012

Wikipedia Assignment

I started the second part of the assignment today with the expectation that I'll do it quickly (like in 30 minutes), get it out of the way, and just forget about it as I have several midterms and papers to worry about. I don't feel ashamed to admit this at all, this is brutal honesty here.

I ended up losing track of the time and put in way more effort than I intended to, because I enjoyed the process of learning about Wikipedia's foundation and the very practices that keep it the #6 website in the world (by traffic). I am totally serious, I thought it was way more interesting than the sea of theoretical knowledge I'm trying to absorb from my two majors. The idea of adding value to such a prestigious community also carried incredible appeal and powered me through a typically boring Tuesday afternoon.

I can't wait to work on the Wikipedia article itself.

Monday, 15 October 2012

Thinking about Algorithms

Hearing Professor Heap talk about and attempt to devise algorithms at the last lecture got me thinking. Algorithms are obviously useful as an "instruction manual" that guides one through the unfamiliar process of carrying out a task or activity. For example, I'm sure someone who is new to baking cookies will appreciate an algorithm that covers everything from gathering ingredients to taking the cookies out of the oven. Similarly, someone who is new to greasing bicycle chains will find a relevant algorithm covering all the steps to be profoundly helpful.

But in real life, anything can happen. There is a famous statement called Murphy's Law which states: "Anything that can go wrong will go wrong". To me, I don't see this as a pessimistic view toward life, but rather a gentle reminder that possibilities are endless for almost every single course of action, and the margins for error is often greater than we expect. Hence, just how specific do algorithms have to be in order to be effective?

For example, the 7th step of an algorithm can instruct you to cut cucumbers in an evenly manner. But just how does one go about doing this? Reading a certain instruction hardly equips one with the necessary skill to carry out the instruction. The way I see it, there's often a gap between the algorithm and the action itself. Carrying out the algorithm effectively will often require some assumed level of competence and/or experience on the user's part.

Why is this important? Because it forces the designers to examine just how specific algorithms have to be. We already assume the target audience knows relatively little about the topic, but how little? In real world application, every user varies in knowledge, experience and savvy. Do we want to keep it relatively fresh and succinct in fear of insulting the user's intelligence? Or make it detailed enough to address so many possibilities so that even the most novice of novices can follow through adequately? Clearly, designing an algorithm requires extensive thought and seeing beyond your own perspective.