A Joeish Erlang distribution (long)

[Joakim G.]

This is good news indeed! *A warm feeling is spreading through my veins*

Kenneth Lundin wrote:
> 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, ...

Very good. Hopefully you got som input/inspiration from this thread as
well.

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

Sigh. One year is a long time but I understand.

> 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).

In that case I suppose an RPM:ish application in the core package would
be nice.

To me it seems wise to keep the Telecom label away from the core package.
The focus could be on something like (I take the risk saying this again):

1 Internet (server) programming focus
2 Concurrency Oriented Programming Language
3 Simplicity (OTP not. Thus 4)
4 Capable of handling small/middle/largish software projects

<CUT>

>> 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.

What I meant was that new small and/middle sized software projects is
IMO advised to avoid gen_servers, supervisors, application controllers,
appup, relup, boot scripts, gen_fsm, release_handler and the stuff
described in the "OTP Design Principles".

It scares Erlang newcomers sh?tless.

Rogers comment is probably typical:
"I would definitly loose the OTP references though. It scared me ! When
  you talk about how it runs the routers in the various telecom companies,
  it causes all kinds of misconceptions."

I know. An Erlang core package itself uses OTP a lot. That doesn't need
to show in the Core User Guide though.

For small/middle sized software projects its better to write native
and transparant pure Erlang code. The core package documentation could
include a number of simple pure best practice Erlang skeleton code for:

tcp_server
gen_server (loop, recieved based, nice init phase etc.)
application controller (top level process handling child process
                         re/starts etc.).

A steep learning curve. Not.

>> 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.

Then we disagree.

>> 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.

I see your point and want argue.

<CUT>

>> 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.

Splendid! Do you have a time plan for this (which you can share?)

<CUT>

Happier
/Jocke
-- 
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.