As a lifelong fan of marginal programming languages, I've spent my fair share of time wondering why they don't get more use. I would really have liked to use more Clojure over the last fifteen years. But the reality is that there are good structural reasons we make the choices we do. One thought experiment I've used to explore why involves the notion of a hypothetical 'zero cost' programming language. What happens to a software project if all the costs of expressing the code go to zero?
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.