Only Iain really understood the application engine, a particularly subtle and complex part of our system. We depended on him alone for any modifications in this area. To reduce the risk, the project manager paired me with Iain to work on a new feature for the engine. After all,
“What would happen if Iain fell under a bus?”
Well, if something that terrible happened, I don’t suppose I’d have cared much about the app engine. As it turned out we never got started on that feature. A customer reported a critical bug in the graphics library — a more straightforward part of the system, but one which only I knew about — and by the time I’d turned in a fix Iain was heading off for the weekend. Celtic were at home to Rangers. He had a plane to catch.
Haskell makes the A-Z
Switching from buses and planes to Haskell, Computerworld’s great A-Z of Programming Languages series recently featured Simon Peyton Jones talking with characteristic exuberance about the language.
Haskell’s roots are in academia. Unlike, say, C++ or Erlang, it wasn’t created with a particular real world application in mind. Rather, the language aimed at rigorously investigating an approach to programming, that approach being strongly-typed lazily-evaluated functional programming. Pure functional programming, if you like. As the language continues to evolve its purity has not been watered down — what’s more, as computer architectures develop, the real world seems to be turning towards Haskell.
So much for the summary. It’s the terrible side effects I’d like to pick up on.
In the interview Simon Peyton Jones talks about pure functions and side effects, a subject I was lucky enough to hear him present on at this year’s ACCU conference.
Advantage number 1. Pure functions can execute in parallel.
If the functions that you call do not have any side effect effects behind the scenes, if all they do is compute a value from the input values that you give them, then if you have two such things, you can clearly do them both at the same time. And that’s purely functional programming. Mainstream languages are, by default, dangerous for parallel evaluation. And purely functional languages are by default fine at parallel evaluation.
Advantage number 2. Pure functions are safer.
Functional, whether lazy or non-lazy, means no side effect. It doesn’t mess about behind the scenes — it doesn’t launch the missiles, it doesn’t write to the disk.
Launching missiles? As a side effect, it’s certainly more dangerous than printing “Hello, World” to a terminal. Simon Peyton Jones again, in this case discussing what’s meant by evaluation order, and why strictness matters.
In theory, lazy evaluation means that you can’t take the ML or Scheme route of just saying ‘oh well, we’ll just allow you to do input/output side effects’, as you don’t know what order they’ll happen in. You wouldn’t know if you armed the missiles before launching them, or launched them before arming them.
Haskell’s roots, as already mentioned, are in academia, but funnily enough Simon Peyton Jones has more teaching experience with a language more traditionally associated with missiles and the military.
While I was at Glasgow I was exclusively engaged in first year teaching of Ada …
Let’s suppose Haskell were used to control a hypothetical missile launcher. It’s true that the language allows programmers to formally partition the system between the safe, pure functions, and those which risk changing the world by probing the launch device; but to be truly confident, we must also test the platform, by which I mean the compiler, the machine code it generates, and indeed the underlying machine which that code executes on.
Haskell compiler writers have a big responsibility!
Here’s an even bigger irony: C, a language as side-effectful as they come, is often used to program military devices for the reason that C, as a platform, is easier to ratify. You compile sample programs, you cross-check the generated assembler.
OK, I know, I’m reading far too much into the “launch the missiles” example, but I’ll admit the phrase makes me shiver, much like the hacker term “ICBM address” for geo-tagging does — and indeed the suggestion that bus accidents should motivate team work.
Somewhere out there, computer programs really do have the power to launch missiles. I couldn’t find any report of disaster caused by such a program but I did find this story about a satellite early warning system reporting in error that five ballistic missiles had been launched at Russia. Fortunately duty officer Lt. Col. Stanislav Petrov smelled a rat.
“I had a funny feeling in my gut” that this was a false alarm. For one thing, the report indicated that only five missiles had been fired. Had the United States been launching an actual nuclear attack, he reasoned, ICBMs would be raining down on them.
Falling under a bus
There was no sign of Iain at work on the Monday morning, and he’d normally be one of the first in. I had a funny feeling in my gut when the project manager summarily told us to stop what we were doing and gather for an all-hands meeting. Something serious had happened. Maybe we’d been taken over or someone had been sacked. Actually, it was worse than that.
We all stood in the centre of the open-plan office, shuffling, shutting phones down, waiting. The project manager broke the news. This morning he’d had a call. On Saturday, Iain had been at the match with some friends. Afterwards, heading away from the ground, no doubt jostled by the crowd, he’d fallen into the road. He’d been hit by a bus. Emergency brain surgery … a helicopter flight … more surgery to follow … the situation looked bad … would keep us all informed.
After a long period of convalescence Iain returned to work. He has some chilling scars and trouble with tinnitus. Otherwise, he was lucky. Now, when we shuffle work around so as not to depend on one person, we don’t talk about falling under buses.