[erlang-questions] Erlang 3000?

[Robert Virding]

Fortunately hungarian notation is just a convention, otherwise if it was in
someway included in Erlang2 (or 3000) there would very soon be a new project
Erlang 3, started by me. It sucks greatly.

I must honestly say that I am not that convinced in having too many generic
libraries. I think that generally you know, and need to know, the
representations you use. They are not equivalent even if you hide them
behind a interface which tries to make them so. This is not to say that you
can't make the interfaces similar if it is possible.

I see now in your nabble link you suggest something along these lines.

There are many levels in an language definition/standard library and a big
problem is working out where the limits are. What goes in the language and
what is part of a library.

The main problem is not the actual coding, well perhaps if you intend to
rewrite the erlang VM, but working out the design and the design principles.
Once these are done the coding is not that bad.

Robert

2008/11/16 Zvi <exta7@REDACTED>

>
> 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.
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20081116/7e4945ab/attachment.htm>