[erlang-questions] Erlang 3000?

[damien morton]

On Sun, Nov 16, 2008 at 8:56 AM, Robert Virding <rvirding@REDACTED> wrote:
> You have mentioned a very real problem, although some of the things you
> point out are actually justified. For example ets/dets explicitly handle
> tuples where one of the elements is the key while dict/orddict/gb_trees
work
> with separate keys and values so a difference here is expected. It is a
pity
> that gb_trees does not have a dict compatible api where it is possible.

Its also a pity gb_trees isn't simply named trees. The gb_ part is just
obscure - why does it matter that the implementation of trees is of the type
gb_ but the implementation of dict and set is not. 99% of users simply wont
care.

> That argument ordering is different and that sometimes the thing worked
upon
> comes first, or last, or sometimes even in the middle is unfortunate. The
> different, or rather inconsistent, ways of indicating success/failure is
> also unfortunate.

A first step would be to develop some guidelines. The .NET 1.0 libraries
were very poorly hacked together. For .NET 2.0, a set of guidelines were
developed http://msdn.microsoft.com/en-us/library/ms229042.aspx

One of their library designers, Rico Mariani, had this to say:

The flip side of this is that it must not only be easy to
use the API, but it must be easy to use the API in the best possible way.
Think carefully about what patterns you offer and be sure that the most
natural
way to use your system gives results that are correct, is secure against
attacks, and has great performance. Make it hard to do things the wrong
way.

A few years ago I wrote this:
The Pit of Success: In stark contrast to a summit, a peak, or a journey
across a desert to find victory through many trials and surprises, we want
our customers to simply fall into winning practices by using our platform
and frameworks. To the extent that we make it easy to get into trouble we
fail.

True productivity comes from being able to easily create great products—
not from being able to easily create junk. Build a pit of success.




> Reworking Erlang to fix many of these errors would probably worth the
> effort, though it might split the user group. One could also fix the
syntax,
> although making it look more like C#/Java would probably be last on my
list
> of priorities, if it ever got there in the first place. I mean the idea is
> to look forwards and try and get rid of old blemishes of the past and not
> import someone elses old crud.
Though there were worries that the Python 3000 effort might split the
community, that doesn't seem to have happened. Tools have been produced that
make porting to py3000 possible, and I understand that the language changes
are relatively modest, removing the most glaring of language warts, and
regularising and reorganising libraries.

Probably the most useful part of the process is a document like this one:
http://www.python.org/dev/peps/pep-3099/ "Things that will Not Change in
Python 3000".

My 2c worth - the focus of the effort should be in making the language and
libraries more accessible. In the end, languages aren't only selected for
utility, but also for learnability. Python has made huge inroads, I think,
because its original focus on being a teaching language.

> It would also be fun, though I think it would be more difficult than many
> believe.

I wonder. It depends on the scope of the changes. If its mostly a
refactoring ....

The Python 3000 process did provoke an orgy of proposals, but if the limits
were set by the erlang luminaries early in the process, then perhaps the
energies of the community could be better focussed.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081116/abbf79c3/attachment.htm>