A Joeish Erlang distribution (long)
Mon Jan 27 10:24:30 CET 2003
After recent discussions on this list and after the work with the
xmlrpc library I have come to a conclusion:
Erlang is ready for an alternative distribution.
In the same way Mandrake Linux successfully enhance/extend each RedHat
release this could be done for Erlang. God bless Open Source.
I'm not saying that we should branch off from the Erlang/OTP code base
but rather morph each new Erlang/OTP release into something different.
The Erlang/OTP group at Ericsson is doing an excellent job and it would
be insane run a paralell race. I'm not sure they are prepared (or even
allowed) to do the thing I describe below. You may of course tell me
I'm wrong. Non would be happier.
Erlang/OTP today have these characteristics (and more for certain):
1 Telecom programming focus
2 Functional Programming Language
3 Complex design patterns (due to 4)
4 Can handle humongously large software projects.
5 Conservative to addition/removal of language constructs/libraries (thus 6).
6 Focus on backwards compatibility.
An alternative distribution would have these characteristics:
1 Internet (server) programming focus
2 Concurrency Oriented Programming Language
3 Simplicity (due to 4)
4 Capable of handling small/middle/largish software projects
5 Aggressive towards addition/removal of language constructs/libraries
(thus 6) [*].
6 Less focus on backwards compatibility.
* = For example: mnemosyne is out, yaws replaces inets. Joe's !!
addition is in (http://www.sics.se/~joe/nerl.html) etc.
I will not delve deeper into this.
To achieve such a distribution someone has to take the burden of
dictatorship. Like Linus does for the Linux kernel. Someone has to
manage the TODO list; deciding what goes into the distribution (and
what's not), deciding which person to entrust with this and that
action point on the TODO list etc.
This person is *certainly* not me. I would suggest Joe. We could even
call the distribution 'Joe' if he is willing to take up the flag. :-)
No. I have not talked with Joe about this. He may very well skin me
for these blasphemous thoughts.
Below follows more advanced ramblings (in comparison with the lesser
Erase the Telecom label. Put the OTP libraries in the background. All
to remove unnecessary complexity when working in small/middle or largish
software projects. Really large projects may prefer the original
Erlang/OTP distribution. Instead position Erlang as a Concurrency
Oriented Programming Language (COPL) as described by Joe at the ll2
conference (http://ll2.ai.mit.edu/) with hype and all.
COPL is especially geared towards Internet (server) programming and
its simplicity and support for massive concurrency makes it easy to
write distributed and robust applications. The language happens to be
functional. This is less important.
Documentation is the key to the spread the COPL message/distribution.
Because of the "pure" Erlang (read: non-OTP) nature of the
distribution a revised version of the Erlang book would suffice. I
know: It has to be written from scratch to avoid copyright
infringement. At least is doesn't need to describe OTP so the work
involved would be _somewhat_ restricted. This means a lot of work. I
can volunteer with a chapter on how to write an xmlrpc servers/clients
[if this is what the editor wants].
Even though OTP is a part of stdlib (and heavily used by Erlang
itself) there is no need to describe it. Just refer to the Erlang/OTP
documentation. Lets keep things simple. The complexity of OTP can be
replaced by a small set of guidelines when it comes to small/middle
and largish projects; how to write a server, how to write an
application controller etc.
The distribution's Web server could very well be fully centered around
this new documentation.
I propose that the distribution is released as two packages: 'core'
and 'tools'. Everything needed to be exceptionally productive within
the focus of the new distribution is included in these two
packages. A large part of OTP is today included in stdlib (application,
supervisor, gen_server, gen_fsm, sasl, app, appup, relup and dist_ac
etc.). It would stay there in the background being described elsewhere.
Core (random order)
http client library
smtp client library
ldap client library
Tools (random order)
We leave these applications out. If you want these or explicit OTP
support go for the Erlang/OTP distribution:
If you think the pen is mightier than the sword, the next time someone
pulls out a sword I'd like to see you get up there with your Bic.
More information about the erlang-questions