Language change proposal

Chris Pressey cpressey@REDACTED
Fri Oct 31 21:23:12 CET 2003

On Mon, 27 Oct 2003 12:53:36 +0100
"Robert Virding" <robert.virding@REDACTED> wrote:

> ----- Original Message ----- 
> From: "Chris Pressey" <cpressey@REDACTED>
> > [...]
> > So there you have a plausible case for using macros.
> Being the original "Guardian of Truth and Beauty" I think you have
> missed the point, at least how I see it. If you want Erlang to be a
> good return-on-investment over a long term then you have to be very
> strict about what you allow in the language. Otherwise it will become
> full of little "features" that, separately, are all innocent but put
> together result in a complete mess, which is difficult to understand
> and maintain.

No doubt in most sane peoples' minds that this is how companies
(/language projects/companies that oversee language projects) *should*
operate - take the long view.  The question is - do they?  Indeed, given
how management tends to operate, can they?  And, of course the burning
question is - will Ericsson?

I don't just like Erlang because it's a beautiful language.  I like it
because it's a battle-tested production language that happens to be
about two to three times more beautiful than the "national leading
brand", even counting the warts.

Given a choice between a wart-free Erlang and a bug-free Erlang, I'll
take the bug-free one.  Of course, that's a bit of false dilemma, but
it speaks to where we concentrate our efforts - the more people
concerned with how to make/keep Erlang small/beautiful/expressive/
orthogonal/cutting-edge, the fewer people submitting bug reports/fixes
which will improve Erlang in the day-to-day humdrum of development.

Yes, getting rid of the warts would be great - but will it ever become
the corporate priority?  I'm hoping yes, but guessing no.  I'm concerned
specifically that Joe's suggestion will be seen as complicating matters
unnecessarily for paying customers.  Which may or may not be the case,
depending on the magnitude of the changes from one version to the next. 

But it does seem reasonable to not want to force your customers to fix
things that, from their point of view (expediency), ain't broke.  At
least, not without offering them an alternative, like a bugfix branch of
the last "unversioned" Erlang/OTP.

Joe's suggestion is also interesting in that it's something you can, for
the most part, already do dynamically:

  erts_version() ->
    {ok, L} = file:list_dir(code:root_dir()),
      ("erts-" ++ V, A) ->
        case list_to_float(V) of
          R when R > A -> R;
          _ -> A
      (_, A) -> A
    end, 0.0, L).

  start() ->
    case of erts_version() of
      V when V < 5.3 ->
        erlang:fault({requires_erts, 5.3});
      V ->

But I dasn't expound on this hack, lest my trolling further waste the
reader's precious time - time that could be used for putting the
finishing touches on your Hallowe'en costume, or submitting patches to
make erlang:open_port/2 work correctly under Windows!  :)


More information about the erlang-questions mailing list