[FoRK] Fighting the last war, or, presenting the Erlang Challenge

[Jeff Bone]

In case you haven't been following this soap opera, last week Paul  
Graham released a thin veneer over MzScheme and claimed it was the  
long-promised Arc, The Hundred Year Language, the Lisp to end all  
Lisps (especially for developing Web apps.)  In response to numerous  
criticisms, he offered up "The Arc Challenge" --- a sample web app in  
5 lines of Arc, with the challenge "do this in fewer lines in some  
other language."

As we previously pointed out, however, the ability to write this  
program in 5 lines of Arc is (a) kind of meaningless, and (b)  
primarily a function of the underlying MzScheme implementation and  
its libraries (in particular its continuation-based Web server) ---  
and hardly at all a function of the characteristics of the Arc  
language itself.

Here's something in a different vein, Yariv Sadan's "Erlang  
Challenge."  Basically you need to write a distributed / parallel map  
function that satisfies some reasonable real-world requirements.   
Erlang, of course, is well-suited to this;  indeed the problem may be  
seen as a prototypical Erlang problem in the same sense that PG's web  
example is intended to be a prototypical Arc problem.

   http://yarivsblog.com/articles/2008/02/08/the-erlang-challenge/

Here's Yariv's Erlang solution:

pmap(Fun, List, Nodes) ->
   SpawnFun =
     case length(Nodes) of
        0 -> fun spawn/1;
        Length ->
          NextNode = fun() -> nth(random:uniform(Length), Nodes) end,
          fun(F) -> spawn(NextNode(), F) end
     end,
   Parent = self(),
   Pids = [SpawnFun(fun() -> Parent ! {self(), (catch Fun(Elem))} end)
     || Elem <- List],
   [receive {Pid, Val} -> Val end || Pid <- Pids].

Now, call me narrow-minded but it seems to me that PG's whole effort  
here is a "fighting the last war" sort of thing;  he's attempting to  
build better tools for doing the same thing he's always done, namely  
write Web apps in Lisp.  He's re-fighting his last war.

Erlang, OTOH, despite its telecom origins and its rather-surprising  
age, seems perfectly-suited for tackling the kinds of new-and- 
different programming problems we will in general face over the next  
decade or so, for which our previous tools are not just poorly-suited  
but in many cases not at all useful.  (Those new problems:  cluster- 
per-person as the norm, multi-core, disconnection as edge-case of  
latency, massive data mining, fault-intolerant applications, etc.)


$0.02,

jb