[erlang-questions] Erlang 3000?

[Robert Virding]

Yes, I agree with you, but. While it is perfectly true that more open source
components and killer apps, or least working apps, would definitely help, I
think you fail to realise the negative impact things like messy libraries
and blogs about it can have.

While I know that most of the libraries actually are quite good in spite of
their APIs and that the erlang VM is very good and tested and robust it does
not look like this for many people. Unless they take the time to study and
test the system properly they may be scared off by what they perceive to be
a sloppy and hastily put together system. Especially if they have read the
same thing in some blogs.

Therefore I think it is definitely worth redoing and cleaning up many of the
libraries.

Also we have against us that we don't run on the JVM, which I hold to be a
real benefit of course. :-) Think of a world without last-call optimisation?

I am less worried about splitting the erlang community as I don't think that
it will happen. It may be a major change but it will never be something that
just pops out of the blue so I assume people will adjust and appreciate the
improvements. One thing we have to do to help the community is to make a
proper language spec and rationale so that people can really know what
erlang is and how it is supposed to work. This is a necessary prerequisite
for new implementations other than the BEAM, and if erlang is successful
these will come.

While we are talking about change, I think a few syntax changes would be
beneficial but I don't think they can ever be enough to appease the real
syntax whiners. I separate those who complain about the syntax into whiners,
those who whine about it not being like java, and those have actually tried
it and come with serious criticism. This is not why I would like to make
some changes.

Thomas Lindgren mentioned one reason why the APIs look like they do, no
vetting. Another early reason is that we were concentrating on some aspects
of the language, and implementing it, and often we just need a library so we
hacked one together. And we still have them hanging around. An unfortunate
and slightly depressing prerequisite to these reasons is that some didn't
have the inclination or time to make a good API.

And I must admit I had a rather cavalier attitude to libraries before, if
you need a library you write it yourself. Which probably didn't help much.
:-)

I agree with Joe on how to proceed, although I think you have to release the
new libraries earlier to the eager waiting public, you can't wait until you
have redone the whole lost before releasing them. However you *do* need a
small group to work on the guidelines and programming rules and do the
initial new libraries, both as tests of the rules and as examples. The group
should be small or else it is difficult to work out a clear concise set of
rules and guidelines. As always the problem is not what not add but what to
remove.

The funny thing is that I am probably the one who least cares if my stuff is
ever used. Strange world.

That's about it for this time,

Robert

2008/11/17 Kenneth Lundin <kenneth.lundin@REDACTED>

> 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/20081119/0ebfbdb6/attachment.htm>