A Joeish Erlang distribution (long)

[Kenneth Lundin]

Hi all,

Here are some comments from the Erlang/OTP Product Manager at Ericsson.

1) We have plans to divide the Erlang/OTP distribution into s number of
separate packages. Preliminary we are thinking of 3 packages:
- Core package (erts,kernel,stdlib,sasl,mnesia,os_mon,inets,compiler,..)
- Tools&Utilities (parse_tools, tools, debugger, observer, et, tv, ...
- Telecom/protocols (snmp, asn1, orber, megaco, ...

The exact contents is not settled yet.
When this happens is not decided either but an optimistic guess is
before the end of 2003.

I am not very positive to the idea with an alternative distribution
where applications from us are exchanged with other similar applications
(e.g inets replaced by yaws).
I think it can be confusing for the users that the contents varies
for different distributions and that the quality and compatibility 
strategy varies, between different applications within the same package.

I think it is better that the concept where an Erlang/OTP installation 
can be put together from several separate packages is defined and then 
there can be additional packages for example one with internet_server
related applications that can be maintained and distributed separately
from the packages from us (OTP group at Ericsson).

Joakim G. wrote:
> Hi all,
> 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)
I don't think there is to much focus on design patterns and most of
them are useful in any SW project.
> 4 Can handle humongously large software projects.
I don't think there are any specific SW within Erlang/OTP or the 
documentation which only is relevant for "humongously large" projects.
> 5 Conservative to addition/removal of language constructs/libraries 
> (thus 6).
Very important to have a stable foundation. It is hard to remove things 
because of backwards compatibility issues. Before we add things we like 
to be reasonably sure thast we want to support it for a long time. We 
must also be able to guarantee the quality.
Sometimes we add things which we point out as unsupported just to let 
the users try it.

> 6 Focus on backwards compatibility.
Yes, that is important and one of our strengths. (although it sometimes 
stops us from doing nice improvements).
The backward compatibility strategy saves us a lot of work since it is
quite easy to convince a large/huge user project to change to the latest
version. By this we don't need to support an overwhelming amount of
old versions.
I think this is good for the Open Source users too.

> 
> An alternative distribution would have these characteristics:
> 
> 1 Internet (server) programming focus
> 2 Concurrency Oriented Programming Language
I agree that this is a better positioning than as a functional programming.

> 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.
> 
> Cheers
> /Jocke
> 
> Below follows more advanced ramblings (in comparison with the lesser
> ramblings above):
> 
> Positioning
> -----------
> 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
> -------------
> 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].

We have work in progress here too. The goal is of course that our 
documentation fully can replace the need of the the book.
> 
> 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.
> 
> Packaging
> ---------
> 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.
> 
> The packages:
> 
> Core (random order)
>   sae
>   xmerl
>   asn1
>   yaws
>   xmlrpc
>   soap
>   compiler
>   erl_interface
>   stdlib
>   mnesia
>   mnesia_session
>   crypto
>   ic
>   kernel
>   http client library
>   smtp client library
>   ldap client library
>   parsetools
>   ssl
>   runtime_tools
>   jinterface
>   odbc
>   ucs
> 
> Tools (random order)
>   et
>   appmon
>   debugger
>   pman
>   toolbar
>   tv
>   tools
>   observer
> 
> We leave these applications out. If you want these or explicit OTP
> support go for the Erlang/OTP distribution:
> 
> eva
> sasl
> snmp
> megaco
> os_mon
> orber
> cosEvent
> cosFileTransfer
> cosNotification
> cosProperty
> cosTime
> cosTransactions
> gs
> etk
> inets
> mnemosyne
> webtool

Regards Kenneth Lundin (Product Manager of Erlang/OTP)
--