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.<br>
<br>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.<br>
<br>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.<br>
<br>It would also be fun, though I think it would be more difficult than many believe.<br><br>Robert<br><br><div class="gmail_quote">2008/11/15 damien morton <span dir="ltr"><<a href="mailto:dmorton@bitfurnace.com">dmorton@bitfurnace.com</a>></span><br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I don't suppose there's and Erlang 3000 project in the works?<br>
<br>
The Python people set out to create Python 3000, throwing backwards<br>
compatibility out the window in favour of fixing language and library<br>
design errors.<br>
<br>
I mentioned earlier the variety of ways that the Erlang libraries<br>
signal returning a value or not. Some examples:<br>
<br>
proplists:get_value(Key, List) -> undefined | Value<br>
<br>
dict:find(Key, Dict) -> {ok, Value} | error<br>
<br>
gb_tree:lookup(Key, Tree) -> {value, Val} | none<br>
<br>
dets:lookup(Name, Key) -> [Object] | {error, Reason}<br>
<br>
ets:lookup(Tab, Key) -> [Object]<br>
<br>
All these operations on standard ADTs are roughly equivalent, and yet<br>
they have different or conflicting naming conventions, different<br>
return value protocols, and different orderings of their arguments.<br>
<br>
While ets:lookup and dets:lookup return a tuple, one of whose members<br>
is the key, gb_tree:lookup return the value of a {key,value} pair.<br>
<br>
gb_tree:lookup, dict:find and proplists:get_value all perform the same<br>
operation, and though the return value protocol is different in each<br>
case, at least the arguments are the same.<br>
<br>
The key asset for any well designed language or library is<br>
learnability, which comes from regularity, i.e. having learned<br>
something in one situation, one can apply that knowledge to similar<br>
situation with a high probability of success.<br>
<br>
Erlang already does a lot of things differently from other languages,<br>
but when every single library module does things differently from the<br>
others, well, that's a lot of heterogeneity for a novice to deal with.<br>
<br>
I wasted an hour so so tonight trying to figure out a problem that<br>
stemmed from proplists having a different argument ordering to ets - I<br>
just instinctively assumed they had the same argument ordering, and<br>
why shouldn't I?<br>
_______________________________________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://www.erlang.org/mailman/listinfo/erlang-questions" target="_blank">http://www.erlang.org/mailman/listinfo/erlang-questions</a><br>
</blockquote></div><br>