Category: General

I recently got the NASA When We Left Earth DVDs, and I thought “great, I’ll be able to watch them during my Seattle trip”. So, I put them into the hotel DVD player tonight .. and got a “cannot play” error. Arg, the dvd’s will be region 2 (europe) and the player is region 1 (US). So, despite this being a completely legal, paid for copy of the DVDs which I brought with me, I cannot watch them! Grr!

What does one do to stay awake in Seattle after getting up at 3am, 14 hours of travelling and an 8 hour timezone shift? In my case, grab a coffee (how native) and head to the awesome Seattle Public Library. Without much of a plan, apart from staying awake. As it turns out, I randomly stumbled upon an archive of Communications of the ACM dating back to the very first edition, in 1958.

1958 was a strange old world. Things considered newsworthy: buying a new computer (as in, ‘Foo University has purchased an IBM 456 with 2048 bytes of memory’), upgrading the memory in your existing computer (particularly when you are building said memory from scratch yourself). Other articles included puzzles similar to chess end-games – ie. implement [trivial operation] using only 6 bytes of IBM xyz machine code but without using any jump operations.

I skipped forward to November 1976, the month I was born. An article by Jim Gray on db locking in which it’s necessary to define the term ‘transaction’ explicitly. The previous month, there’s an early paper about texture mapping by Jim Blinn with lots of pretty pictures. Again, it’s enlightening to see ‘basic’ stuff being laboriously explained .. for example, why you get aliasing effects if you sample the texture naively. But wasn’t “basic stuff” back then; it was the frontier of knowledge.

Only the flight across, I was reading a biography of Oliver Heaviside. The book covers both his physics work and also the world, time and society that he lived in. In particular, it’s fascinating to read about how resistant (sic) “practical” electrical engineers were to the new-fangled mathematics-wielding theoreticians who had started to dominate the field. There were many vocal engineers who were quite sure that they didn’t need “all that maths stuff”.

For every success story celebrated and enshrined in today’s textbooks, there were many other forgotten voices arguing against that viewpoint in the publications of the day. I’m sad that almost every textbook I read at university missed out all of this rich tapestry – instead they provided a neatly cut-and-dried distillation, devoid of any human context. To me, real science was. and presumably still is, a process of muddling around in a sea of uncertainty and conflicting schools of opinion. I seemed to learn about the abstract scientific method (very useful!) but not so much about the day-to-day struggles of real scientists. Much later, I found my way to Thomas Kuhn and biographies of Faraday, Maxwell, Boltzmann, etc. And there I found a much more interesting picture, crucially explaining the ideas in their original context.

So it’s nice to be able to go back to the original sources and imagine what it might’ve been like to be a ‘computer person’ in 1958 .. to see what kind of ideas were thinkable in that time, to see who was prodding at the boundaries, and to see how much is recognizable today.

The coders who are interviewed in “Coders at Work” all have interesting opinions, but it’s the recurring themes which have really grabbed me.

The first theme is that all of these people are humans. They’re might all be famous for doing X, but hardly any of them set out consciously to do X, and none of them did what they did because they knew it’d lead them to where they are today. When you read about how they got into their area, the recurring themes are serendipity and “I did it because it was fun”. As Simon Peyton Jones says explicitly, the important thing is just getting started – because once you get started there’s a million interesting things you could play with. I don’t want to downplay the cool stuff some of these guys have done, but it’s hugely enlightening to hear them talk in their own words and hear how “normal” they all are.

The other theme I noticed is that everyone lives in their own little niche. Very few people in the book seem to have a broad overview of computing and how it’s changed over the decades. In particular, you can see how people’s thinking is constrained by either the era in which they learned about computers, or by the particular area that they’ve specialized in. It’s refreshing to hear Simon Peyton Jones say that he doesn’t really have a deep understanding of OO programming, because he’s basically not done that much of it – he doesn’t knock it, either. It’s weird to hear Peter Deustch describe his dream language without him knowing that these ideas have already been tried in Haskell. It’s interesting to hear people who are famous as being ‘lisp guys’ or ‘smalltalk guys’ knocking ‘their own’ language. And it’s amazing to see the split between low-level and high-level thinkers. I’m biased, because I’m into programming languages, but few people commented on the extent to which your Preferred Language affects your modes of thinking – although the results are plain to see.

Finally, this book made me realise that I’ve been in this game for quite a long time now (I’m only 32!). Enough time for entire chapters of knowledge to have come and gone. Programming in assembler, gone! Well not totally; still useful for compiler backends, security exploits and such like. Manual memory allocation, gone! Well not totally, there’s still kernel development and embedded stuff. Segmented memory models, gone but back for a wee while with PAE. Implementing primitive datastructures, largely done for you! C++, gone (for me at least)! I spend so much time getting really good at it too, hmmph. I respect it for what it is, but there are much nicer ways to spend your life.

But that’s all fine. Technology reflects the era that it was born in. C made sense when memory was expensive and CPUs slow. Now virtual memory and VM’s make sense. When resources were sparse, conceptual clarify was sacrificed to gain performance. Now we usually don’t need to make that sacrifice. The abstractions which made sense for a 1990’s desktop GUI app aren’t the ones you need for a 2009 network-based distributed system.

Is history important? Only partly, I think. The high level lessons are certainly important, but the details aren’t. Do you need to be able to code up a red/black tree today? No. But I think a developer should have a deep appreciation for the distinction between interface and implementation – and you should understand how the implementation choices can affect you (as a user). Do you need to understand low level hardware/assembler? No, but the concepts and solutions which crop up at that level crop up elsewhere too, so it’s certainly not wasted knowledge. Do you need to learn smalltalk? Only really to learn the ‘lessons of smalltalk’ – to see what you can do with a reflective, late-bound, heavily interactive system.

All in all, I’m whimsical about the amount of technology water that’s passed under my particular bridge. Easy come, easy go, I am not the sum of my knowledge. I’m happy to keep absorbing new fun stuff as times change and mostly I’m quite happy to see the back of the declining technologies anyway! It’s comforting in a way to see that there’s no real wizards out there, there’s just people hacking away on stuff that they think is cool and being ready to recognize the insights and the epiphanies when they come by. Evolution (and some marketing $$$s) usually takes care of picking out those solutions which are suited to the present environment. And there’s always the interesting “superior but ignored” technologies hovering around in the wings.

Computing has only really been around for one lifetime. Most of the first-generation guys are still alive. It’s interesting to hear some of them reflecting on a life spend involved in this area. I guess I’m taking a moment to reflect on where I am.

“Coders at Work”: loving it

Scion provides a way for emacs to chat to ghc, giving you nice squiggly red lines under your errors in realtime.

I thought I’d found a string encoding problem in scion, but after taking a long route (tcpdump etc) it turns out that it’s just a poor default. Out of the box, scion will assume that scion server (and in turn, ghc) speaks latin1. However, you can just add this to your .emacs to make it speak utf8 instead:

(setq scion-net-coding-system 'utf-8-unix)

Now your lambdas can be λ’s and you still get pretty error messages in scion!

Not sure if I got very much out of the Haskell Symposium today. After three days of ICFP I think I’m just a bit overloaded. On the plus side, every single talk contained at least one interesting nugget, but overall there wasn’t anything which really excited me. It was nice to see more about how GHC works. And I was certainly interested to hear about Jean-Philippe Bernardy’s lazy parsers from Yi – I had worried that it would be quite easy to trip up and accidentally cause everything to be evaluated, and indeed it sounds like that’s probably true. Conal Elliott’s talk about FRP reminded me about my previous (non-FRP!) job writing various physics simulators .. having done it in an imperative and stateful fashion, I completely understand the appeal of a composable declarative approach!

One other thing I noticed today; I keep forgetting that each ~30 minute talk is actually a distillation of maybe a year’s worth of work. Therefore, everyone who talks appears to me to have a superhuman ability to recognize problems, generalize them and instantly apply complex idioms to form a solution! Given the breadth of material covered at the conference, it’s somewhat of a whirlwind. But, whilst I only understand some modest fraction of what I’ve seen, I am starting to get a better idea of what kind of stuff people are working on, and what kind of approaches people take. It also makes me more aware of what kind of things I find interesting (and conversely, not interesting!) and where I might better target my efforts in the future.