Another one for my computer science reading list for this year. I do try to work my way through at least one classic computer science book annually and picked up Let Over Lambda a few weeks ago. Colour one of the cats not impressed, but then again she’s got more free time than I do and probably already read it.

This of course begs the question - why? To stay relevant, wouldn’t it be more important for me to spend all my spare time learning the 1132nd framework du jour? Or the latest in hot languages? Why do I spend some of my valuable spare time reading some of these old, dusty and clearly irrelevant books?

Well, I beg to disagree that they’re irrelevant. In my opinion, there are two parts to making sure you keep your skills polished as a software engineer. First, have a reasonable grasp of currently relevant tools and methodologies. This includes the all important skill of how to learn new ones. Second, understand the fundamentals. Despite of what some people seem to think, fundamentals still matter. Good software engineering practises - or should I say, software craftsmanship practises - don’t change overnight. They also don’t change much based on the platform you’re building on. True, the exact details will be slightly different. However, the hallmark of an experienced software developer is that they are able to apply prior experience, and the fundamentals are extremely helpful there.

As Scott Hanselman mentions quite often in his podcast, where we consider the metal to be changes regularly. During my involvement with computers we’ve gone from machines programmed assembly language on the processor with effectively no OS, to multitasking OSs with virtual memory, to where the metal for a large percentage of developers is whatever the web browser executes directly. On top of the multitasking OS, which sits on top of the the processor that executes the high-level language code that was translated to machine code. Which in turn may still be executed by the CPU with features implemented in microcode. Turtles all the way down, in other words.

At every layer, fundamentals do matter. They do matter if we are building efficient, maintainable and performant systems. Compared to the systems of yesteryear, we have a lot more processing power with almost infinite memory and much faster storage. Yet, we’re also asking a lot more from these systems, and as software craftspeople we have to build and maintain them in a sustainable manner. The memory leak or bubble sort stay problematic, no matter if they are happening in the web browser or deep in the OS.

Also, the fundamentals haven’t changed quite as much as we would like to think. In a sense, computers have become easier to program. There are more of them, and for most people, getting the information on how to use tools and frameworks is easier these days. On the other hand we - or our customers - expect them to do more. And ideally, faster, cheaper and better than before. Yes, I know. Pick two.

Let’s say you agree with me that fundamentals are useful. But why, for the sake of the planet, choose The Language Of Parentheses? Well, other than me having taking a certain liking to the language and being a multi decade Emacs user, a lot of early-ish research was done in languages like LISP. Plus, LISP and its extended family are still one of the most flexible programming languages around and in my opinion are one of the most expressive ones. At least if you measure expressiveness by how little code you have to write to accomplish a given task. Not to mention that LISP like languages are really good at stacking abstractions.

Fun fact, during my time at university, we had to learn Modula-2, Lisp, Prolog and 68k assembler. I found Modula-2 the easiest to learn, but then I had already learned some Turbo Pascal in school. Also, assembler wasn’t foreign territory to me. Prolog at some point provided me with a “eureka” moment, but Lisp evaded me. Yes, even when I started getting a bit more serious in my use of Emacs. It did take me a while to get comfortable with it. Note I said comfortable, not good 😃.

Another point that is important to me is that exposure to various language concepts gives you different ways to think about problems, much like being fluent in more than one natural language can change the way you think and express yourself. The language family/concept part here is important. In my experience, there is less benefit in having exposure to C, D and Java than there is having exposure to C, Smalltalk and Haskell. Basically, the first three languages all belong to the same family that trace their ancestry back to ALGOL-68. There is also a lot to be said for experimenting with languages are “pure” in their design - for example, using Smalltalk to explore the concepts object oriented programming. Yes, you can do this in Java or Python as well, but there is a noticeable difference in exploring a language that allows you to use a specific concept like OO, and one that forces you to use it. I find this distinction especially important when your daily driver programming language is a multi-paradigm language like C++ that allows you easily mix the various concepts.

What other classic CS texts have you read lately and would recommend?