[erlang-questions] Erlang 3000?

[Kenneth Lundin]

I agree that it is unfortunate that some of the library modules are
not consistent with each other
but I don't think this is a major problem for users of Erlang.

I think it is a very bad idea to start discussing a new incompatible
track of Erlang just because of this.

The Erlang community is not big enough for this yet, what we need now
is actions that stimulate the
growth of the community.

I definitely don't think the inconsistency in the tree, dict etc. APIs
is one of the most important things in this.

More important is to get more high quality reusable Open Source
components and an easy way to find these.
Also more important is to have more books and more "killer"
applications built with Erlang. Applications that draw
the attention to Erlang.

When it comes to inconsistencies in libraries and language I think the
best way is to prepare a suggestion on design rules for new API's
both for collection ADT's and in general. Then this can be used as a
basis for evolving stepwise into more consistent API's.

There are ways to evolve without breaking compatibility new functions
can easily be added and old ones can be deprecated.
New modules can also easily be added etc.

It is also very important to remember that backwards compatibility is
one of the most appreciated characteristics of Erlang. It makes it
possible for
large and huge SW projects to shift to  a new major release of
Erlang/OTP with minimal work. This is essential in order to
get users to upgrade to the next release.

/Kenneth Erlang/OTP, Ericsson


On Sat, Nov 15, 2008 at 7:54 PM, damien morton <dmorton@REDACTED> wrote:
> I don't suppose there's and Erlang 3000 project in the works?
>
> The Python people set out to create Python 3000, throwing backwards
> compatibility out the window in favour of fixing language and library
> design errors.
>
> I mentioned earlier the variety of ways that the Erlang libraries
> signal returning a value or not. Some examples:
>
> proplists:get_value(Key, List) -> undefined | Value
>
> dict:find(Key, Dict) -> {ok, Value} | error
>
> gb_tree:lookup(Key, Tree) -> {value, Val} | none
>
> dets:lookup(Name, Key) -> [Object] | {error, Reason}
>
> ets:lookup(Tab, Key) -> [Object]
>
> All these operations on standard ADTs are roughly equivalent, and yet
> they have different or conflicting naming conventions, different
> return value protocols, and different orderings of their arguments.
>
> While ets:lookup and dets:lookup return a tuple, one of whose members
> is the key, gb_tree:lookup return the value of a {key,value} pair.
>
> gb_tree:lookup, dict:find and proplists:get_value all perform the same
> operation, and though the return value protocol is different in each
> case, at least the arguments are the same.
>
> The key asset for any well designed language or library is
> learnability, which comes from regularity, i.e. having learned
> something in one situation, one can apply that knowledge to similar
> situation with a high probability of success.
>
> Erlang already does a lot of things differently from other languages,
> but when every single library module does things differently from the
> others, well, that's a lot of heterogeneity for a novice to deal with.
>
> I wasted an hour so so tonight trying to figure out a problem that
> stemmed from proplists having a different argument ordering to ets - I
> just instinctively assumed they had the same argument ordering, and
> why shouldn't I?
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>