JSFUnit Beta 2 Released

Stan's announcement says it all. Please beat it up.

Sequence and Order in Erlang

I’ll be at ThoughtWorks Chicago headquarters for this weeks’ Away Day gathering. One of my slides is about the order of evaluation and message sequencing in Erlang. I like to think of it as an "Erlang Puzzler". For anyone who won’t be there, take a look at this 'contrived' module. It is composed of three functions: sequence/0, maketuple/0 and echo/0.

-module(contrived).
-export([sequence/0]).

sequence() ->
 Pid = spawn(fun echo/0),
 register(echoprocess, Pid),
 whereis(echoprocess) ! maketuple(self(), now()),
 whereis(echoprocess) ! maketuple(self(), now()).

echo() ->
    receive
       {From, {A,B,C}} ->
         From ! {A,B,C},
         echo()
    end.

maketuple(Self, Now) -> {Self, Now}.

What does this do? The sole public sequence function spawns the self documented echo function as an Erlang process. It then registers this process as “echoprocess” and sends it two messages. Both messages are return values of maketuple, which simply yields its two arguments as a tuple.

There are a few subtleties here.

Strict Evaluation

Pay attention to the two calls to maketuple. The arguments applied to maketuple are calls to built-in functions self/0 and now/0. Are these arguments evaluated before or after maketuple is evaluated? In a functional programming language like Haskell the calls to self and now would be delayed until the value of the arguments were needed within maketuple. This means self or now could start after the call to maketuple, finish before it, or possibly never be evaluated. This is called lazy evaluation. Function arguments in Erlang however are strictly evaluated, meaning self and now are evaluated before maketuple.

Referential Transparency

What is the order of evaluation for self and now? It is natural for an experienced imperative programmer to assume self precedes now. Some would say this is in observation of the principle of least astonishment.

The order of evaluation for self and now is undefined. In a deterministic world without side effects, the order of evaluation is inconsequential - just like the commutative property of addition in grade school.

Order of Evaluation for Send Operands

The operands of the send operator (!) are calls to the built-in function whereis/1 is and maketuple. Which is called first, whereis or maketuple? Left to right? Right to left? Again, the order is undefined.

Delivery Order of Asynchronous Messages

The sequence function sends two messages. In which order are the received? An undefined order would really complete the process/actor/mailbox metaphor. When you send two letters in the mail, is the recipient guaranteed to read each letter in the order they were sent? Of course not. An undefined order of delivery would also sit well with many other asynchronous communication mediums.

It turns out the order of message delivery is in fact guaranteed to be the order in which they were sent. Despite the various possible execution paths of the sequence function, things are pretty static on the other side in the echoprocess. This is not to say that the second message will be delivered immediately after the first message - there could in theory be messages from other processes in the mix.

Session proposal accepted for the Erlang eXchange

I'll be in London this June at the Erlang eXchange. My session will cover the jInterface API and a fair and unbiased comparison of Erlang and Java, regarding concurrent systems development of course. Hope to see many of you there if you're in the area, June 26th to 27th. You also want to keep an eye out for another session from one of my colleagues, Karthik Ramachandra. He has been invited to do a session on an Erlang rewrite of JMeter.

Article published on TSS

TheServerSide has published an article of mine on JSF Anti-Patterns. Discussion is here.

Upcoming Talks

In addition to my other session for TSSJS I'll be doing a case study on JSF anti-patterns. Here's my submitted abstract:

Anti-Patterns and Pitfalls in JSF

This session will cover a dozen war stories demonstrating what NOT to do with JavaServer Faces. Patterns presented will touch on third party library integration, vendor lock-in, performance, tight coupling, cache management, thread safety, security, interoperability and test-driven development. Solutions to each anti-pattern will be discussed.

I'll also be in Amsterdam for ApacheCon 2008. Me and a few other ThoughtWorkers have started an community blog for open source topics so I thought I'd publish the details over there. This link may break soon if Paul moves the site.

Java & Erlang proposal accepted for TSSJS conference

Looks like I'll be in Vegas this March. TheServerSide conference committee has invited me to give a fireside chat at the 7th annual TSS Java Symposium. Here's my submitted abstract:

Concurrent Programming with Java and Erlang

The industry is going parallel. This session will demonstrate how trivial it is to build highly scalable fault tolerant systems in Java with JInterface, an open source bridge for Java and Erlang. Learn the differences between Java threads and Erlang processes. See how to write software that can take advantage of multi-core processing without locks, keys, synchronization or shared memory.

How to pronounce Erlang and Scala

Erlang is typically pronounced "air-lang". The "a" is long. It rhymes with "bang". This is a surprise to many Americans like myself, who often pronounce Erlang as "ur-long". We also seem to pronounce Scala as though the first "a" is long. Nilanjan Raychaudhuri is a colleague of mine who once pointed out that this is not the case.

Sometimes I catch myself using "air-long" and "ur-long" in the same conversation, and that probably won't change any time soon. I don't feel any of these pronunciations are right or wrong in any absolute sense, although I still laugh each time an old friend of mine pronounces the "i" in Linux as long (as it is in Linus). So far, I have heard three different pronunciations of Poppendieck.