[erlang-questions] Erlang 3000?

Sun Nov 16 04:02:57 CET 2008

2008/11/16 Robert Virding <rvirding@REDACTED>

> 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.

Down with Hungary and its bloody awful notation.

> 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.

Genericity isn't really possible with erlang. What is possible is
regularity. A 'dictionary' behaviour and a 'collection' behaviour would just
about cover the various abstract data types. Maybe also an 'ordered'
behaviour, and some distinction between set/bag would be useful. I think
some kind of iterator/stream protocol might also be needed, but I dont see
it used anywhere in erlang, and there might be a good reason for that.

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.

So lets just focus on the library. Any language changes will likely have
to accommodate the current libraries with only minor changes.

> 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.

So, if you were to rewrite the collection classes from scratch - what
principles would you follow?

>
> 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
>>
>
>
> _______________________________________________
> 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/40b8cc61/attachment.htm>