[erlang-questions] Erlang 3000?

[Zvi]

Damien,

look at these threads:

http://www.nabble.com/List-to-proplist--to20063268.html#a20265061

http://www.nabble.com/Hungarian-notation-for-Erlang---ETL-td14701912.html#a19822958

What you suggesting can be divided into 2 tasks:
1. New language spec
2. New standard library

As there is a lot of legacy products in today's Erlang/OTP, I guess OTP
team's first priority is backward compatibility. I heard, that some attempts
to fork the language failed.
It looks like each module in stdlib was developed by people from different
galaxies :-)
One of the problem, that Erlang is dynamicaly-typed language, and module
writer use whatever atoms s/he want (i.e ok, done, ping, pong, pang, error,
etc.), when in statically-typed language you return boolean, with only two
known values.

Anyway, you can see here the difference between languages, which require
some discipline and those which don't. It very hard, to write libraries like
this in Java or C++ (but very easy in Perl or other scripting languages).
 
I think, the best path to approach this problem, is to start writing new
stdlib, the basis of which will be gen_collection behaviour (something like
STL in C++ for Erlang). For simplicity it will be just common API wrappers
for various collections ADTs in Erlang stdlib. Even if there are will be
some performance loss, it will make code much more readable and
maintainable.

The next step is to add to gen_collection data-parallel APIs (in the style
of plists module).
By data parallel constructs I not only mean, usual map / fold / filter, but
also various methods, like lookup for multiple keys or adding multiple
key/value pairs by single function call, or operating coillections as a
whole.

For this you do not need OTP team involvent, just start open source project
on github.

Zvi
 



Damien Morton-2 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
> 
> 

-- 
View this message in context: http://www.nabble.com/Erlang-3000--tp20518620p20520907.html
Sent from the Erlang Questions mailing list archive at Nabble.com.