[erlang-questions] Erlang 3000?

[Edwin Fine]

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.

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.

Thanks for a marvelous development platform, namely Erlang/OTP!

Regards,
Edwin Fine

On Mon, Nov 17, 2008 at 6:29 AM, Kenneth Lundin <kenneth.lundin@REDACTED>wrote:

> I agree that it is unfortunate that some of the library modules are
> not consistent with each other
> but I don't think this is a major problem for users of Erlang.
>
> I think it is a very bad idea to start discussing a new incompatible
> track of Erlang just because of this.
>
> The Erlang community is not big enough for this yet, what we need now
> is actions that stimulate the
> growth of the community.
>
> I definitely don't think the inconsistency in the tree, dict etc. APIs
> is one of the most important things in this.
>
> More important is to get more high quality reusable Open Source
> components and an easy way to find these.
> Also more important is to have more books and more "killer"
> applications built with Erlang. Applications that draw
> the attention to Erlang.
>
> When it comes to inconsistencies in libraries and language I think the
> best way is to prepare a suggestion on design rules for new API's
> both for collection ADT's and in general. Then this can be used as a
> basis for evolving stepwise into more consistent API's.
>
> There are ways to evolve without breaking compatibility new functions
> can easily be added and old ones can be deprecated.
> New modules can also easily be added etc.
>
> It is also very important to remember that backwards compatibility is
> one of the most appreciated characteristics of Erlang. It makes it
> possible for
> large and huge SW projects to shift to  a new major release of
> Erlang/OTP with minimal work. This is essential in order to
> get users to upgrade to the next release.
>
> /Kenneth Erlang/OTP, Ericsson
>
>
> On Sat, Nov 15, 2008 at 7:54 PM, damien morton <dmorton@REDACTED>
> 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
> >
> _______________________________________________
> 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/20081117/0f9262ee/attachment.htm>