And now for something completely different.
For years, just like pretty much anyone else who writes software, I've been using imperative languages. All the days from ZX BASIC, BBC BASIC, Z80 assembler, 6502 asm, C, C++, Perl, php and Java. (And even some COBOL, but I don't like admitting to that). Most recently, most of what I do is in Perl, or shell script, or Java.
That's a long time habit of doing things like "i++".
At times, out of disaster comes opportunity, Recently, our largest customer went into administration (for US readers, I'm not sure how this maps to Chapter 11 or Chapter 7, but basically it means the company is insolvent, and its management has been taken on by a third party who will try to sell what's left). This has left me with quite a lot of time to spare because a project I would have been working on right now is currently on hold until the situation with our customer is resolved (and the outcome looks like it should be favourable).
I've heard bits and pieces about functional programming, and Haskell, and Erlang - but never really had looked into it. My memory was jogged on Erlang when I was reading an article about telephone exchanges, somewhat coincident with the above catastrophe with our customer. Erlang was initially developed for telecommunications, where five 9s are simply not good enough, and I'm always interested in something that can help me make more reliable systems. I'd rather be developing than cleaning up after a system crash. So the time was ripe to start on Erlang.
What makes me interested in this language is that it is a tool that's designed for making reliable, concurrent systems. It has good features for that such as extremely light weight processes, the VM supports upgrading software *WITHOUT* having to shut down the program - you can upgrade/fix a service that's running and NOT shut it down to load the changes. It is also a functional language. And functional languages to me are (at least until last week) an alien concept.
The journey has only just begun. I started with "Learn You Some Erlang for Great Good" (it's titled in Engrish, but written in English) - http://learnyousomeerlang.com/ . I now also have the O'Reilly Erlang book, which I'm just about half way through reading and working through the examples.
The striking thing is you have to think a bit differently for a functional language like Erlang. You don't so much as describe how a task should be completed, but declare What The Truth Is - in a way that is very similar to how you write functions in mathematics (indeed, one of the first examples in Learn You Some... is a function that returns the factorial of a number, and the Erlang has a direct correspondence with the way a mathematician would write a factorial function). The way lists can be manipulated (list comprehensions) is straight out of mathematics set theory. Although the language looks strange and impenetrable and ugly at first, soon you see a mathematical beauty emerging. The other striking thing is that variables aren't. (I'd have called them "invariants" - calling them variables isn't all that accurate since they can't be varied once assigned). But you don't need variable variables in a functional language.
The other striking thing is how you must think differently with Erlang if you're making a concurrent system. The O'Reilly book points out that they've encountered time and time again, when people from an imperative background start using Erlang, they do it wrong - they write the system like they would in, say, Java, so with a minimal level of concurrency. But processes in Erlang are really, really cheap so you've got to get rid of all those ideas on how to write a large system. For example, the book cites how one group had set out to make an IM proxy in Erlang. They had one process handling the sockets from clients, another process doing some work on the data, and a final process emitting the data to the downstream servers. They ran into trouble with more than half a dozen concurrent messages. But how they should have designed it is to create a new process for every single packet - processes are *that* lightweight that you can make tens of thousands of them quickly and without huge memory overhead - and their proxy could handle orders of magnitude more simultaneous messages. Interprocess communication is also very lightweight, and lacks the shared memory drawbacks of traditional threads. Essentially, in Java or C++ or C# you think like the Protoss - a few heavy weight warriors. If you write Erlang, you have to think like the Zerg. A veritable swarm of lightweight processes, and zergling rush your problems :-)
This neatly segues onto something I did many moons ago in university. We learned a design methodology, written by a man called Michael Jackson (not the dead singer, the still alive computer scientist). JSD (Jackson Structured Development) and JSP (Jackson Structured Programming) were methodologies developed in the 60s and 70s, and today are largely forgotten, in fact in the 90s when we were learning this stuff there was much grousing about it being "obsolete"... but one thing that keeps coming back was when analyzing your problem, you analyzed it as if you had the perfect concurrent system and so you modelled every small problem as a completely new process. In those days you'd eventually flatten it down to effectively a single thread. I remember remarking to a classmate at the time that there seemed to be an elegance of starting your model as if you had the ideal concurrent system because it made it clear - and that perhaps one day we would have a system in which you could take the design and implement it as a concurrent system, just as you had drawn it. Perhaps it's time that JSD was revisited, because in Erlang you DO make every single little process that happens in your inherently concurrent world an actual Erlang process, just like Jackson suggested you model it! JSP, which we used in COBOL at the time, and COBOL itself was the source of much grousing - (JSP is specifically good at program design when you have an input, you transform it, and make an output. The stuff of many COBOL programs. If you model your inputs and outputs correctly, the resulting program structure makes programming a simple mechanical task and you get no logical errors in your code) - it strikes me that JSP fits amazingly perfectly with XSLT. Indeed, JSP models everything as a tree. Now what's XML? Basically, your program structure is exactly how XSLT is structured - a tree. So is your input and output.
So perhaps Michael Jackson really is a genius, too.
