[erlang-questions] Erlang Extension Proposals (EEPs)

[Thomas Lindgren]

--- Tom Samplonius <tom@REDACTED> wrote:

> ----- "Thomas Lindgren" <thomasl_erlang@REDACTED>
> wrote:
>
> > Ironically, Common Lisp is FAR MORE standardized
> than
> > Erlang. The problems of porting, e.g., Common Lisp
> do
> > not appear in Erlang only because with Erlang
> there is
> > nowhere to port. If there was a second source for
> > Erlang, I would hands down expect future
> functionality
> > to diverge, and probably the existing libraries
> too
> > (as bug fixes are introduced, for example).
> 
>   I guess we have different ideas of what
> "standardization" means.  Socket programming is a
> basic feature, and it doesn't work the same,
> everywhere in the CL world.

Nor do sockets work the same in the C world, or even
the Unix world (cf. Stevens). Standardization instead
usually means having a formal standard of some sort.
This doesn't prevent problems when porting or
interworking, of course, nor does it address issues
beyond the standard. Nor compliance. But a standard
still shows explicitly what is expected in order to
comply.

As per above, I would expect Erlang implementations to
diverge too, if there were several ones. The drivers
are obvious: users have different preferences and
implementors can't delay their work to copy whatever
choices the incumbent eventually will make.

>   I think we also have different ideas on what
> "port" means too.  Erlang does not run on everything
> yet, so there is more porting of the environment to
> do. 

Porting Erlang/OTP is far more a problem of porting C
code than porting Erlang code.

> Now, given that there is only a single erlang
> implementation, application porting is mostly a
> non-issue.  And it should be.  Application "porting"
> isn't a problem worth fixing.  If you have to change
> your code to run under a different implementation,
> it means the language implementation has failed.

As I see it, the decision whether to port an
application to a new platform (OS or language
implementation or whatever) is a trade off, not an
absolute. There are also many cases when it makes good
sense to port. (Even tracking Erlang/OTP through its
releases involves a small amount of porting.)

Likewise, language implementors too have to consider
whether to design, implement and support utterly
future proof interfaces (so that user porting will
never be an issue) or not. Maybe their time budget
could be spent on better things. Maybe their users
prefer a good choice right now rather than a perfect
choice sometime in the future. (I guess this could go
on to Gabriel's "Worse is better" paper, but that's
probably beyond the scope of this list.)

Best,
Thomas



 
____________________________________________________________________________________
Don't get soaked.  Take a quick peak at the forecast
with the Yahoo! Search weather shortcut.
http://tools.search.yahoo.com/shortcuts/#loc_weather