Archive for June, 2005
Well, if you haven’t noticed, we’re in the thick of exam season now. Call me sick, but this is the part of the year I enjoy the most - it seems that studying for exams causes all the material to jell. Topics connect up between courses and you realize just how much material you’ve absorbed in the last semester….
Well, there are certainly worse things you can do with your time…
Continuing on the topic of my last post, the computer graphics courses look really nice (67609 and 67315).
Apart from the cool course website for cg, they both star Dr. Dani Lischinski, who did a year’s internship at Pixar (wow-awee-wa 
kavod!!!).
Other stuff that bears mentioning:
- Apple adds Podcast support to iTunes [You thought written blogs could be boring…] + all iPods (except for the mini) are now color - how sexy is that
- Now you can own your very own paper Enigma machine.
- Theres a new James Bond gadget out to keep that big plasma display in your dorm room out of the way…
- How to rebuild an old laptop battery for much less than a new one costs…
Seeing as the school year is officially over, and in not too long we’ll all be done with our exams (tfoo tfoo tfoo knock on CRT), it’s about time to start thinking about courses for next year.
First off, if you haven’t heard about it already I highly recommend “From NAND to Tetris“. I honestly think it’s one of the better university courses out there.
I took in the first semester of this [last?] year and had a really great time.
The premise of the course, (although hard to believe) is to build a complete working computer from scratch starting from the most basic logic circuits, through to designing a CPU, writing a compiler, and culminating in authoring an OS and writing a game for the computer you’ve designed.
I wouldn’t have thought it possible to pack so much into a semester, but Prof’s Nissan and Schoken actually managed to design a course that does just that. It’s really a joy to experience.
The course requires a generous amount of self-studying and work on the exercises, but apart from them being fun, there’s a really well written book that covers all the course material - in fact, hardly anyone showed up at lectures…
The only downsides to the course where some annoying bugs in some of the software provided and some issues with the grades given out - both of these issues may be fixed this year.
In closing, I can’t overstate how highly I recommend NAND, its a unique learning experience and well worth the time investment.
Turns out Quantum Computers may show up sooner rather than later…
Is anyone even working on a programming language to write programs for these things? Seems like an interesting problem…
Off the web:
An entertaining story that’s been going around.
“All Your Base Are Belong to Us” turns five, lemmings flee…
“There’s something the technicians need to learn from the artists. If it isn’t aesthetically pleasing, it’s probably wrong.”
— Seen on Slashdot
Quick Links:
1)The simplest way to implement site search - Hoorah for XML!
2)Regarding my previous post about indelicate remarks in coding comments, turns out this generalizes to film - special effects artist need to be careful too sometimes… - link.
On to the actual post:
I want to tell you all a secret. You’ve probably had an inkling at one time or another of what I’m about to say, or if you’ve been programming for a long time you might actually know this already, but here goes.
What I want to talk about is the importance of aesthetics in CS.
The gist of the matter is as follows: it’s common knowledge that since we’re geeks, the ultimate proof of our superiority over mere mortals is our ability to hack out unreadable pieces of code and write in handwriting that only we can understand. This shows that we’re smarter than the people around us - anyone ever heard the term “doctor’s handwriting”.
The point I hope to make in this post is that the above is (although a neat notion) utter nonsense…
Aesthetics play an extremely important part in what we do as programmers on every level. Writing that hack that utilizes 15 scripts in 8 different programming languages interconnected with a healthy dose of tcsh and a mile or so of duct tape may feel at the time of writing like legitimate alpha-geek behavior. However, the next time someone else [or g-d forbid you yourself] have to come back and fix the multi-lingual spaghetti-garden pile of obfuscated blabber, the result more often than not will be a re-write instead of trying to tackle your chimera-like creation.
When you create something that looks good it shows you care and take pride in your work, people prefer to use good looking software and gadgets with esthetically pleasing interfaces.
I could write pages of obscenities about bad practices I’ve seen, but I’ll try to make this as short as possible:
1)When handing in reports, assignments, or code printouts - hand them in on clean white paper, make sure the layout is clean, if appropriate add images to emphasize your points, make it colorful and pleasant to look at (you may not have studied at bezalel, but if it looks good to you, it’s probably OK).
Handing in an assignment in greasy pencil on the back of an old printout may seem like it doesn’t matter much, but like it or not, the person who reads it will sense your lack of respect for what your handing in and grade accordingly (maybe it shouldn’t be that way, but 8 out of 10 times you will get a lower grade).
Don’t go overboard, don’t use too many fonts or too many pictures or you take the risk of your presentation looking like a ransom note.
2)Write clean good-looking code - There have been volumes written on this, the best book I’ve read on the topic is this one. Like elegant mathematical proofs, clean good looking code is a joy to read. Good code conveys the ideas of your program, and is readable by an outsider.
Writing clean code helps you get a better understanding of what your doing resulting in a lower bug count and easier maintainability. Also, theres no need to use every feature available in a programming language to show off [this goes triple for PERL and C++], modern compilers know how to optimize better than most of us, attempting to write faster code by omitting the white spaces and writing shorter variable names just makes things harder for us humans.
I’ve helped out many-a-first-year CS student to debug their program by simply helping them re-write the messy code they’d written in an attempt to get things done faster, with simpler properly indented code. In most cases, just redoing the indentation and giving variables meaningful names gave these people the ability to find their own bugs.
3)When designing a user interface do your best to make it visually appealing! If you want people to actually use your software, try to make it simple for the user rather than the programmer. A good place to look for how to get this right is anything made by Apple, they are masters at creating programs and devices that are a joy to use.
If your writing a shell script, try your hardest to make it self-contained and DO NOT use absolute paths if at all possible. If you must, place anything hard coded in a clearly marked section at the top of your script so that anyone who wants to use it can easily find the places they need to change. If your program involves multiple scripts, create a central configuration file with copious comments.
Personally I prefer writing 1 PERL script instead of a mix of SED, AWK, and *sh. PERL can be written in a readable fashion if you put your mind to it, and it was written specifically to help you with this kind of thing.
There is nothing more frustrating than trying to get a bunch of shell scripts you wrote several months before to run, only to discover that you have to start rebuilding some arcane directory structure just to get things to work.
4)Stay away from “Quick Hacks” - as any experienced programmer will tell you, those quick hacks you put into code are very unlikely to be changed. “I’ll just hack it up quickly in the interim, then it’ll stay permanently”.
You will find the time it takes to write things properly will pay itself-back 10-fold when it comes time to debug. It’s very frustrating to spend a whole night debugging something just to find the bug in that quick one liner you stuck in to save you time.
I hope this was interesting enough, so your all with me here at the end, I’d be interested in hearing any comments you guys might have on this…
As you might know by now, we’re supposed to comment our code in hopes that it might help out someone else at a later date.
Problem is, that despite what we might think at the time of writing, some comments are indeed read by others - case in point.
Personally, I once had to deal with a few pages of code written for win95 with large blocks of assembly in them (did I mention, that this was in a legacy product and no-one was even sure that the aforementioned code was being called, not to mention it’s purpose), the only comment in the code was:
...
//hui
...
In case you where wondering, thats in Russian…
And the motto of the story is - be careful what you write, you never know when someones gonna post it on the web…
The last week of school is coming to an end, and with it the official start of exam season 
) So let me take this opportunity to wish you all good grades and much sleep!
In the meantime here’s the dope on that Lenna image that you seem to see all over the place (if you read up on image processing that is).
Hope this time round the hours are shorter: link.
How far away from this are we?
Already, some lectures are available in the library on VHS, but this is a far cry from the ideal of recording all lectures and having them available from anywhere as streaming video.
All that would be required really are stationary video cameras in the lecture halls and a system to automate posting on a central server.
Some worthwhile lectures online:
1) E&M courtesy of MIT’s Open Coursewear - one of the best lecture series I’ve seen, maybe physics, but this is how lectures should be given.
2)Knuth, the video[s].
