On Sun, Nov 16, 2008 at 8:56 AM, Robert Virding <<a href="mailto:rvirding@gmail.com">rvirding@gmail.com</a>> wrote:<br>> You have mentioned a very real problem, although some of the things you<br>> point out are actually justified. For example ets/dets explicitly handle<br>
> tuples where one of the elements is the key while dict/orddict/gb_trees work<br>> with separate keys and values so a difference here is expected. It is a pity<br>> that gb_trees does not have a dict compatible api where it is possible.<br>
<br>Its also a pity gb_trees isn't simply named trees. The gb_ part is just obscure - why does it matter that the implementation of trees is of the type gb_ but the implementation of dict and set is not. 99% of users simply wont care.<br>
<br>> That argument ordering is different and that sometimes the thing worked upon<br>> comes first, or last, or sometimes even in the middle is unfortunate. The<br>> different, or rather inconsistent, ways of indicating success/failure is<br>
> also unfortunate.<br><br>A first step would be to develop some guidelines. The .NET 1.0 libraries were very poorly hacked together. For .NET 2.0, a set of guidelines were developed <a href="http://msdn.microsoft.com/en-us/library/ms229042.aspx">http://msdn.microsoft.com/en-us/library/ms229042.aspx</a><br>
<br>One of their library designers, Rico Mariani, had this to say:<br><br><blockquote class="webkit-indent-blockquote" style="margin: 0 0 0 40px; border: none; padding: 0px;">The flip side of this is that it must not only be easy to<br>
use the API, but it must be easy to use the API in the best possible way.<br>Think carefully about what patterns you offer and be sure that the most natural<br>way to use your system gives results that are correct, is secure against<br>
attacks, and has great performance. Make it hard to do things the wrong<br>way.<br><br>A few years ago I wrote this:<br>The Pit of Success: In stark contrast to a summit, a peak, or a journey<br>across a desert to find victory through many trials and surprises, we want<br>
our customers to simply fall into winning practices by using our platform<br>and frameworks. To the extent that we make it easy to get into trouble we<br>fail.<br><br>True productivity comes from being able to easily create great products—<br>
not from being able to easily create junk. Build a pit of success.<br></blockquote><br><br><br>> Reworking Erlang to fix many of these errors would probably worth the<br>> effort, though it might split the user group. One could also fix the syntax,<br>
> although making it look more like C#/Java would probably be last on my list<br>> of priorities, if it ever got there in the first place. I mean the idea is<br>> to look forwards and try and get rid of old blemishes of the past and not<br>
> import someone elses old crud.<div><br></div><div>Though there were worries that the Python 3000 effort might split the community, that doesn't seem to have happened. Tools have been produced that make porting to py3000 possible, and I understand that the language changes are relatively modest, removing the most glaring of language warts, and regularising and reorganising libraries.</div>
<div><br></div><div>Probably the most useful part of the process is a document like this one: <a href="http://www.python.org/dev/peps/pep-3099/">http://www.python.org/dev/peps/pep-3099/</a> "Things that will Not Change in Python 3000".</div>
<div><br></div><div>My 2c worth - the focus of the effort should be in making the language and libraries more accessible. In the end, languages aren't only selected for utility, but also for learnability. Python has made huge inroads, I think, because its original focus on being a teaching language.</div>
<div><br>> It would also be fun, though I think it would be more difficult than many<br>> believe.</div><div><br></div><div>I wonder. It depends on the scope of the changes. If its mostly a refactoring ....</div><div>
<br></div><div>The Python 3000 process did provoke an orgy of proposals, but if the limits were set by the erlang luminaries early in the process, then perhaps the energies of the community could be better focussed.</div>
<div><br></div><div><br></div>