Required Reading

Toward the end of last year, I sent a series of "reading assignments" out to my dev team in an effort to get them thinking along the lines of how to improve themselves as developers. Some other devs at my company (Rackspace Hosting) caught wind of it and requested that I widen my distribution of them. Since many found the material enlightening, I'm going to post the whole series here for posterity, along with my original "post date" and comments.

Since I took the trouble to do this in the first place, it should be obvious that I think each of these items has something important to say about the profession of software development. If you're looking to be challenged, read on. If you think you're fine right where you are, then maybe this isn't for you.

Final note: Remember that this was spread out across several weeks, so while each piece of reading is relatively bite-sized, if you take them all together, it's going to take some time!

Wednesday, September 05, 2012

Beating the Averages by Paul Graham

Especially interesting for his description of the "Blub Paradox".

Wednesday, September 12, 2012

What Made Lisp Different by Paul Graham

A short essay that's an interesting list of parameters you could use to evaluate the power of a programming language. Easy read. <700 words.

Friday, September 21, 2012

Succinctness is Power by Paul Graham

What is "power" in a programming language? This article isn't a direct answer to that question, but it makes some interesting observations.

Wednesday, September 26, 2012

The Rise of "Worse is Better" by Richard Gabriel

"Unix and C are the ultimate computer viruses."

nuff said

Wednesday, October 03, 2012

Taking a slight detour away from Paul Graham and Lisp-ish things this week:

Teach Yourself Programming in Ten Years by Peter Norvig

Wednesday, October 10, 2012

This week, continuing last week's theme of becoming a better programmer: why working harder doesn't pay off.

Hard Work Does not Pay Off by Olve Maudal

Wednesday, October 17, 2012

Today, why things are the way they are (wrt programming language usage). This essay is longish, but there are sections you'll breeze through if you've kept up with previous weeks' reading:

Revenge of the Nerds by Paul Graham

"Suppose, for example, you need to write a piece of software. The pointy-haired boss has no idea how this software has to work, and can't tell one programming language from another, and yet he knows what language you should write it in. Exactly. He thinks you should write it in Java. Why does he think this?"

Thursday, October 25, 2012

I know this looks long. Just stick with it. It's probably the shortest reading so far.

First, I'm a day late this week, but I haven't forgotten. It's just been busy. This is the next-to-last reading material that I plan to send out (in this series, anyhow). Look for the big finale next week.

--- THE IMPORTANT BIT ---

Now for this week's provocation of thought... If you did the reading a handful of weeks back, entitled "Succinctness is Power", you might have caught an unlinked reference to a study that compared various aspects of some programming languages. I chased that study down. It's over a decade old, but some of its conclusions are still interesting. One of them is along the lines of the aforementioned article: "Designing and writing the program in Perl, Python, Rexx, or Tcl takes only about half as much time as writing it in C, C++, or Java and the resulting program is only half as long." This lends weight to the premise of the article, which is that a language that allows for shorter programs is a more powerful language.

--- /THE IMPORTANT BIT ---

If you can accept that paragraph after reading it twice, then consider this week's reading accomplished! Otherwise, you can find the study in its entirety (as a PDF) at http://page.inf.fu-berlin.de/~prechelt/Biblio/jccpprtTR.pdf.

And here's a quick summary of the study and its (other) conclusions. It found that when the same program was implemented in several languages by many different programmers:

• No unambiguous differences in program reliability between the language groups were observed.
• The typical memory consumption of a script program is about twice that of a C or C++ program. For Java it is another factor of two higher.
• For the initialization phase of the phonecode program (reading the 1 MB dictionary file and creating the 70k-entry internal data structure), the C and C++ programs have a strong run time advantage of about factor 3 to 4 compared to Java and about 5 to 10 compared to the script languages.
• For the main phase of the phonecode program (search through the internal data structure), the advantage in run time of C or C++ versus Java is only about factor 2 and the script programs even tend to be faster than the Java programs.
• Within the script languages, Python and in particular Perl are faster than Rexx and Tcl for both phases.
• For all program aspects investigated, the performance variability due to different programmers (as described by the bad/good ratios) is on average about as large or even larger than the variability due to different languages.

That is all.

Wednesday, October 31, 2012

As promised, this week marks the end of this reading series. As such, the reading is light and generally reflective and maybe not even relevant to the rest of the series. But it's fun. You'll find it at the end of this email.

The only "serious" reading for this week is this: if you've followed the reading for these last two months, you should be asking yourself, "Am I a Blub programmer? If I am, how can I not be?". You should also be able to answer yourself: "I need to take some time to find something up the power continuum from Blub and start learning it because spending time practicing my craft is the single best way to master it." You should also have some ideas about what makes a programming language "powerful" and realize that "the industry" rarely (never?) chooses the right language for the right reason. That means it's up to you to drag yourself beyond Blub and into some higher state of awareness.

That being the case, here are a few ways that I would recommend for you to continue your journey:

• For the truly fortitudinous[1], start "Practical Common Lisp", available for free online. It will wreck everything you thought you knew about how to program: http://www.gigamonkeys.com/book/
• For the slightly less intrepid, pick up a copy of Seven Language in Seven Weeks and pick your poison. Some of the languages in this book will also bend your mind in similar ways to Common Lisp: http://goo.gl/icLSy
• Watch Coursera.org for the next offering of "Functional Programming Principles in Scala": https://www.coursera.org/course/progfun

Finally, this week's reading: Epigrams on Programming by Alan Perlis. They've been around for a long time, so some are dated and no longer relevant. Others are still extremely poignant. Read and enjoy.

[1] Yes, it's a word: http://dictionary.reference.com/browse/fortitudinous