[erlang-questions] : Was Re: Bug ?! now Erlang comment (LONG LONG)

[Bob Ippolito]

On 10/27/06, Ulf Wiger <ulf@REDACTED> wrote:
> Den 2006-10-27 20:08:11 skrev Jeff Crane <jefcrane@REDACTED>:
>
> > If the only barrier to a language adhering to it's own
> > standards is commercial pressure, I would think that
> > fork is appropriate. Otherwise, the standards should
> > be modified to be more practical (less restrictive),
> > since that ends up being the overriding factor in
> > deciding changes to the language.
>
> I'm sorry, but I don't quite understand what you're
> trying to say. What standards?
>
> Since Erlang is Open Source, there is of course nothing
> stopping you from forking. There have, in fact, been
> competing versions of Erlang in the past (e.g. HiPE,
> ETOS), but I've gotten the impression that several
> users stick with the Ericsson distribution since they
> really want something that is as reliable as possible.
>
> A conservative stance on backwards compatibility tends
> to come with the territory if you want to boast having
> your products running in several "five nines"
> installations. But as Erlang grows into different markets,
> perhaps there will eventually be sufficient interest in
> a sligthly different, perhaps "sexier" Erlang, that a
> fork may stand a chance of attracting enough users.
>
> Maybe after 14 years, I've gotten so used to Erlang's
> quirks that I'm blind to the need for a more aggressive
> stance on language evolution. But I still think it
> would be much more fruitful to spend some energy on
> developing good analysis and refactoring tools to
> help migrate the millions of lines of existing Erlang
> code to new, incompatible versions of the language.

As a relatively new user to Erlang there's only three things that I've
noticed that would've helped me out in any significant way:

1. Better record syntax. Current syntax is very repetitive. It's also
not obvious how to do "schema evolution" of records without changing
their name (at least temporarily). I think I'd be very happy with
"structs" as proposed by Joe Armstrong in 2001 [1] -- the performance
characteristics of records are much less important to me than having a
data structure with named fields for maintainability.

2. Bit matching syntax. All of my gripes seem to have been addressed
at EUC 05 in the "Bit-level Binaries and Generalized Comprehensions in
Erlang" paper [2], but are not yet in an OTP release.

3. Easier ways to do parse transforms. There are places in code where
I want to do very predictable things based on a static lookup table
that I'd like to have in compiled code. I started doing this by
-define()'ing a big static tuple, but I've noticed that the VM does a
very bad job if you stick a giant constant tuple in a function whose
sole purpose is to pull a record out of it. For some reason the tuple
gets allocated and deallocated a lot, rather than being constant in
the module (HiPE optimized this case correctly, but I don't always
compile with HiPE).

... of course better error reporting would always help, e.g. for a
missing comma or a semicolon where it does not belong would help.
Sometimes the error ends up with a nonsense line number (e.g. end of
module). However, one quickly gets used to writing code with a very
low occurrence of these sorts of errors, and also it becomes much
easier to track such errors down. This was really only part of the
learning curve, rather than a consistent problem.

[1] http://www.erlang.org/ml-archive/erlang-questions/200301/msg00103.html
[2] http://www.erlang.se/euc/05/1640PerKostis.pdf

Note that NONE of these are backwards incompatible changes. I'm quite
happy with Erlang as it is, but there are obvious ways to improve it.
It also seems that other people have already thought of *and*
implemented these things, it just takes time to migrate to the OTP
distribution.

As a point of reference Python, Erlang, JavaScript, and C are
currently my main languages (in roughly that order of preference and
use).

-bob