Completely agree with Kenneth. Any software that grows organically is going to have inconsistencies. Software like Erlang has usually responded to real-world pressures, in real-world timeframes, and has not had the luxury of (say) a series of long design competitions and committees like Ada did (and IIRC, Ada is not that widely used for all that). Some would have a sigh of relief that Erlang didn't go through that process! I think Erlang has done pretty well, and it probably really IS premature to consider "purifying" it while it's trying to get a strong foothold in the development community. I would say that higher priorities are to improve its vertical (multicore) scalability, make more and easier to use tools for (inter alia) operational control and monitoring and release management, as well as productivity tools like better documentation and a well-indexed "apropos" type facility that allows one to search for any specific function, not just its module (I know there is a kluged up one in Emacs, but how about one that works across the board, not only in Emacs?). Other areas that might be fertile ground include distributed security - the current cookie/short name/long name model is a bit limiting, and making it easier to set up and view traces of running code. Maybe I am just dumb, but there are parts of Erlang that are so arcane that I need to have notes to explain to myself how to use them.<br>
<br>It would also be extremely useful to beef up the FAQs by combing the Erlang mailing lists and extracting some of the more interesting and complex questions and answers. Yes, we can search the lists, but it can often be very time-consuming, and sometimes one can miss the target if the right Google incantation is not invoked. If most of the answers were condensed into the FAQ it would make a big difference, especially to less experienced Erlang devotees like myself.<br>
<br>Thanks for a marvelous development platform, namely Erlang/OTP!<br><br>Regards,<br>Edwin Fine<br><br><div class="gmail_quote">On Mon, Nov 17, 2008 at 6:29 AM, Kenneth Lundin <span dir="ltr"><<a href="mailto:kenneth.lundin@gmail.com">kenneth.lundin@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">I agree that it is unfortunate that some of the library modules are<br>
not consistent with each other<br>
but I don't think this is a major problem for users of Erlang.<br>
<br>
I think it is a very bad idea to start discussing a new incompatible<br>
track of Erlang just because of this.<br>
<br>
The Erlang community is not big enough for this yet, what we need now<br>
is actions that stimulate the<br>
growth of the community.<br>
<br>
I definitely don't think the inconsistency in the tree, dict etc. APIs<br>
is one of the most important things in this.<br>
<br>
More important is to get more high quality reusable Open Source<br>
components and an easy way to find these.<br>
Also more important is to have more books and more "killer"<br>
applications built with Erlang. Applications that draw<br>
the attention to Erlang.<br>
<br>
When it comes to inconsistencies in libraries and language I think the<br>
best way is to prepare a suggestion on design rules for new API's<br>
both for collection ADT's and in general. Then this can be used as a<br>
basis for evolving stepwise into more consistent API's.<br>
<br>
There are ways to evolve without breaking compatibility new functions<br>
can easily be added and old ones can be deprecated.<br>
New modules can also easily be added etc.<br>
<br>
It is also very important to remember that backwards compatibility is<br>
one of the most appreciated characteristics of Erlang. It makes it<br>
possible for<br>
large and huge SW projects to shift to  a new major release of<br>
Erlang/OTP with minimal work. This is essential in order to<br>
get users to upgrade to the next release.<br>
<br>
/Kenneth Erlang/OTP, Ericsson<br>
<div><div></div><div class="Wj3C7c"><br>
<br>
On Sat, Nov 15, 2008 at 7:54 PM, damien morton <<a href="mailto:dmorton@bitfurnace.com">dmorton@bitfurnace.com</a>> wrote:<br>
> 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>
><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>
<br>
</div></div></blockquote></div><br>