Mike Schaeffer's Blog

A little over a year ago, I wrote about some formative experiences I had with computers early in my life. That article focused on the Timex Sinclair 1000, but sitting off in the wings are two other computers - the Commodore 64 and the Apple II. A few weeks ago, there was some dialog between John Gruber, Drew Saur, and Jason Snell that's brought those two machines back to mind. It's all very worth reading if you have any interest in the early history of personal computing.

It's hard for me to admit that it's early history, but these machines are five years further in the past to us today than the ENIAC would've been to somebody opening up a brand new Apple II. Time flies.

Like you might expect, there are partisans for each machine. Drew Saur likes the Commodore and the other two prefer the Apple machines. Having spent some time using and thinking about both, I have my preferences also, but I've also come to a different conclusion. While the Apple and the Commodore competed in a similar place in the early 1980's market, it's equally true that they are products of different times, different design philsophies, and of companies with different goals. For me, it's hard to reduce it to a single "favorite" machine, and it's hard to boil it down to specifications and case design. There's more to the story.

Lately, I've been reading "Beyond Mach 3"), Col. Buddy Brown's memoir of his years piloting the U-2 and SR-71 spy planes. If you like that sort of thing, it's an interesting read on its own, but it also has parallels to the software industry, particularly in the way it describes pilot workload. The concept of pilot workload provides a nice way to think explicitly about the burdens our systems place on us as engineers and operators to keep them running properly.

Over the last few months, I've started making an attempt (with the help of my patient coworkers) to more intentionally learn the programming language Haskell. I have professional reasons why this is directly important, but it's also been a good way to challenge some long held assumptions. Being purely functional and lazily evaluated, Haskell lacks traits like implicitly sequenced evaluation, forcing its reconstruction where needed. Sequence is among the first concepts taught in programming, and it can be disconcerting to have to consider it explicitly. Despite my good intentions and years of experience with functional programming (mainly in various Lisps), the Haskell learning curve has presented challenges. It has been a rewarding journey with a number of connections to other parts of software design. I hope to share some of that here, and hopefully draw some connections that will make it easier to approach this content whether you use Haskell or not.

If you've been around programming for a while you've no doubt come across the Lisp family of languages. One of the oldest language familess still in use, much of what we take for granted in modern programming has roots in Lisp. This includes everything from dynamic memory management to first class functions and a comprehensive library of standard data structures. However, despite the considerable influence of Lisp on the field, one aspect of the language that hasn't been widely adopted is its syntax. Lisp syntax is one of its most distinctive aspects, and is both a strength and a weakness. In this post, I'll share a few thoughts on why that is.