After 10 Papers Every Programmer Should Read At Least Twice appeared in my RSS feed, the pile of articles on my to-read list has grown steadily.
In order to get into gear I’m going to start writing about each of the articles as I finish them. Hopefully, this will be incentive enough to get through them a bit quicker. My current plan is to read one or two articles a week. I may do more, I may do less (I do have a baby on the way in two months).
If you’ve got some good articles, not necessarily on programming, that you think more people should read, leave a comment or shoot me an email.
Todays articles from my pile are:
Ok, onwards and upwards.
The first article was Reflections on Trusting Trust by Ken Thompson. The idea is simple. How can we trust computer programs to not be malicious. In the article, well, the speech, Ken goes through the steps of injecting a Trojan Horse into a C compiler. The interesting thing being, the Trojan doesn’t exist in the source code of the compiler. An initial compiler is trained to insert the trojan when it compiles a specific sequence of code.
The moral is obvious. You can’t trust code that you did not totally create yourself.
One of the ideas behind Open Source code is that all bugs are shallow. Many people looking at the code makes bugs and trojans more easy to spot. The problem being, even with the source available, how many people just install the binaries from their distribution. The trojan may not exist in the source code while existing in the compiled version.
The second article was Minimalism: Omit Needless Code by Kevlin Henney. In Omit Needless Code, Kevlin makes the comparison between programming and writing. How, when writing, you want to omit needless words and make your text as trim as possible. Programming should be done in a similar fashion. You should strive to keep your code minimal. Find the shortest, maintainable route to getting your code to work.
This doesn’t mean obfuscate the code. It means using the features provided by your language to make your code as short as possible. This brevity will better highlight the overall meaning of the program.
In all fields of communication we must recognise the importance of idiom. Compression appeals to common idiom without resorting either to private language or to lowest common denominator baby talk — don’t write code for novices unless you are writing code for novices.
Both articles are wroth a read or two. Keep your code to a minimum and don’t trust anything you didn’t write yourself. Both good ideas, both hard to execute.