[erlang-questions] Fwd: Erlang 3000?

[damien morton]

---------- Forwarded message ----------
From: damien morton <dmorton@REDACTED>
Date: Tue, Nov 18, 2008 at 9:53 AM
Subject: Re: [erlang-questions] Erlang 3000?
To: Edwin Fine <erlang-questions_efine@REDACTED>


On Tue, Nov 18, 2008 at 4:00 AM, Edwin Fine
<erlang-questions_efine@REDACTED> wrote:
> Completely agree with Kenneth. Any software that grows organically is going
> to have inconsistencies. Software like Erlang has usually responded to
> real-world pressures, in real-world timeframes, and has not had the luxury
> of (say) a series of long design competitions and committees like Ada did
> (and IIRC, Ada is not that widely used for all that). Some would have a sigh
> of relief that Erlang didn't go through that process! I think Erlang has
> done pretty well, and it probably really IS premature to consider
> "purifying" it while it's trying to get a strong foothold in the development
> community. I would say that higher priorities are to improve its vertical
> (multicore) scalability, make more and easier to use tools for (inter alia)
> operational control and monitoring and release management, as well as
> productivity tools like better documentation and a well-indexed "apropos"
> type facility that allows one to search for any specific function, not just
> its module (I know there is a kluged up one in Emacs, but how about one that
> works across the board, not only in Emacs?). Other areas that might be
> fertile ground include distributed security - the current cookie/short
> name/long name model is a bit limiting, and making it easier to set up and
> view traces of running code. Maybe I am just dumb, but there are parts of
> Erlang that are so arcane that I need to have notes to explain to myself how
> to use them.

The point is that designers of new libraries will look to the core
libraries for guidance on what patterns, interfaces and protocols to
follow. If the core is schizophrenic and full of entropy, growing the
language will only multiply that entropy. If the core has low-entropy,
growing the language will increase that entropy at a much slower rate.

In my opinion, there needs to be two forces applied to the
language/libraries - the force of growth and the force of reducing
entropy. Refactoring is the entropy reduction strategy of choice, and
if we are careful, that refactoring could be automated.