[erlang-questions] We need a better marketing division :-)
Ulf Wiger
ulf.wiger@REDACTED
Wed Jan 12 10:49:59 CET 2011
On 12 Jan 2011, at 08:22, Muharem Hrnjadovic wrote:
>
> Erlang definitely needs more and better marketing. The research grant
> the scala crowd won [1] is supposed to tackle the "Popular Parallel
> Programming" challenge.
> The first question in my mind after reading [1] was: "Have these good
> folks never heard of erlang?" Apparently not, or not enough.
…or Haskell, perhaps. :)
The proposal in question means to design a DSL for large-scale
"embarrassingly parallel" computing. This is not really a domain where
Erlang is the obvious choice (although it wouldn't necessarily be a very
bad one). Haskell, OTOH, has some really great facilities for creating DSLs
and also some pretty advanced research on data parallelism.
Then again, there is definitely room for more than one initiative, and
there are also exciting developments on the Erlang front in addressing
the scalability challenge. Some, I am hoping to be able to talk about in
the future; others are beginning to become public.
One thing that comes to mind is work done by the USAF Cognitive
Modelling Group in Scottsdale, AZ on using Erlang for very-large-
scale cognitive modeling. Part of the work has been published
http://iccm2010.cs.drexel.edu/proceedings/papers/Douglass.pdf
This work has turned some heads in their community, not least parts
of the work that draw on Erlang's FSM power, for simulating
adaptive and learning processes, essentially re-programming
state machines on the fly (which is fairly trivial in Erlang, but not
necessarily so in other languages).
One thing that caught my eye in the Extended Synopsis for the Scala
project was this:
"The challenge is hard to meet because concurrent and parallel
programming are fundamentally difficult. The conventional view is that
one is left with two choices. The first possibility is to have programs
manage their degree of concurrency explicitly through threads or
processes. This results in a state-space explosion which tends to
overwhelm the capability to understand software’s behavior, even
if standard locks are replaced by some higher-level synchronization
mechanism such as trans- actions or messages."
Perhaps I'm reading too much into it, but as many of you know, I have
been crusading a bit around the "state-space explosion" problem, arguing
that it's not messaging per-se, but the event-handling semantics
(lack of selective event handling) that explodes the state space. I'd say
that we have plenty of empirical evidence that Erlang is great for keeping
the state space from growing out of control.
The interesting thing is that Scala *does* support erlang-style concurrency,
to a greater extent than most languages. Why, then, would they say this?
I am reminded of the first draft of the Scala manual that I ever came across.
It illustrated how to do Erlang-style concurrency in the Introduction, but when
I turned to the Concurrency chapter, it was all about Java-style concurrency.
Not a word about Erlang-style concurrency or selective message reception.
Perhaps this boils down to choosing your paradigm and sticking to it? While
you can whip up a demo and proclaim "we can also do Erlang-style concurrency",
there is really much more to it than that. It would be hard to imagine a
synopsis for an erlang-oriented research project claiming that concurrent
programming is fundamentally difficult and message passing leads to
state-space explosion - about as hard as imagining an erlang-oriented
proposal aiming at advancing the state of the art in OO modeling (even though
you *can* do OO in Erlang too).
The intersection between language, libraries, prominent applications and
community somehow define the core set of concepts. For Erlang, lightweight
concurrency, fault-tolerance and powerful message passing are all right
smack in the core, and thus permeate everything we do, for better and for
worse.
BR,
Ulf W
Ulf Wiger, CTO, Erlang Solutions, Ltd.
http://erlang-solutions.com
More information about the erlang-questions
mailing list