This month, I started taking a computer science class online, along with my friend from high school, Corey. Neither of us have any technical experience, but we're taking the computer science class at Stanford for freshmen with no prior background. It's a blast. I won't be able to understand what the Google engineers are talking about anytime soon (hmmm, or ever), but it's fun to tackle the puzzles that come up when you're trying to solve a CS problem.
Take this first assignment for example. We have a robot (named Karel-- he's Czech :) ) who lives in a quadrangle of 3 arches and 4 columns. If you look at the first frame of the video, you can see that the columns have some stones missing. What's the best way to make Karel replace the stones?
There are four basic commands you can work with:
-move forward
-turn left
-put down a stone
-pick up a stone (we don't use the last command in this particular problem)
[[From the basic commands, you can extend out to "turn around" 180 degrees by commanding two left turns. Also, assume Karel has an infinate number of stones he carries with him.]]
There are three challenges to tackling computer programming. First is simply nailing the syntax; those characters and brackets that the software demands in order to read properly. The second challenge is a more sophisticated logic problem; after you get the syntax right, there are a dozen ways you can get the robot to fix the quad like you see in the video. The trick is how you can define your commands to make your program as universal as possible.
It's easy enough to move Karel to where the gaps are and make him put down stones. We actually want to make Karel think for himself, so that we can relocate him (with the same programming) to a different quad. So for example, the stones are missing from arbitrary spots; can we make a program that works if the gaps are in different spots? There are four columns of five stones each, but can we program Karel to fix this quad OR a quad of different size and shape?
The third challenge, which is emphasized very eloquently by the prof, is writing programs that humans can understand. You should write so that computers can understand your commands, but it's more important that people can interpret your program too. Here's why.
Programs break. If a new engineer needs to go in to your program and fix it, or if he needs to alter your program to do something slightly different, your program needs to be clear enough for a stranger to make adjustments. Otherwise, he's better off scrapping your work completely.
This last requirement of practicing proper form reminds me of the summer I worked on a boat. There are such particular ways of coiling a rope or tying down the pulleys that raise a sail. I had thought that these rules were extraordinarily nit-picky, but you want standard rules so that in an emergency, any sailor can pick up a line you tied down and adjust it without having to figure out your particular knot. Same goes for a code you've written-- you want it to be as clear as possible.
Taking the class has been fun, as evidenced by the delighted and geeky messages between Corey and me. I encourage other people to have a look:
Lecture 2 | Programming Methodology (Stanford)
2 comments:
I enjoy the reading of your blog and the articles you shared with youur own comments.
Yes the importance of human friendly code cannot be undervalued esp b/c sometimes even you need to go back and figure out what you had been trying to do.
As you get more into coding you will find people think it is cool to do stuff with as few lines as possible which is important to some extent (and part of what MS is criticized for not doing) but unless you are writing large systems being easy to read is far more important in my opinion. Esp. today when most programs do not operate at the limits of the computer's capacity this is true.
Cheers!
Post a Comment