the Hopwood design process

Thomas Lindgren thomasl_erlang@REDACTED
Tue Mar 14 13:10:50 CET 2006

--- Bjorn Gustavsson <bjorn@REDACTED> wrote:

> I think that confirms David's statement that it is
> vanishingly rare
> that features are removed. At the time you removed
> your features, the
> user base must have been much smaller than it is
> now. Nowadays we have
> trouble removing even minor (mis)features.
> During the time that I have worked with Erlang/OTP
> (from Dec 1996),
> I can only remember that we have removed two major
> features:
> - Zombie processes. They turned out to be not as
> useful as originally
>   thought.
> - Vectors. Similar to your nukeable arrays, but
> there was an exception list
>   to allow updates in a functional way. Removed
> because of disappointing
>   performance.

(The performance problems were due to GC integration
troubles, weren't they? I seem to recall a mention of
some extremely painful patch with full garbage
collection done at every update or something along
those lines?)

Anyway, let me add two things to the new features

First, pragmatically speaking, it might be useful to
release some features as "experimental", with the
explicit proviso that they can be modified or perhaps
even removed in the future, until classified as
"stable". This allows for community feedback without
locking into a given design beforehand. (Another
option is to have multiple erlang versions, though,
except for me, there doesn't seem to be a lot of
enthusiasm for this :-).

Second, and more generally, I think new features would
fare better if we had some language principles to tell
us what new features strengthen the language, and
which diffuse it. The original erlang fits together
quite well and is elegant and easy to learn and use.
Adding features piecemeal means one runs the risk of
ending up with Frankenstein's Monster, if you see what
I mean. Maybe I'm really asking for a Benevolent
Dictator For Life (aka, chief architect).


Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around 

More information about the erlang-questions mailing list