[erlang-questions] Erlang Extension Proposals (EEPs)

[Tom Samplonius]

----- "Thomas Lindgren" <thomasl_erlang@REDACTED> wrote:
...
> >   Given how fractionalized that LISP has become
> > because each implementation has libraries that
> > perform the same function, but just work different
> > (ex. sockets do not work the same way), leading to
> > wrapper libraries that try to provide a generic
> > interface that works anywhere.  It is a real mess,
> > marginalizing LISP to a prototyping language (ex.
> > http://reddit.com/ was re-written in Python from CMU
> > Lisp, because it was unstable, and sockets and
> > threads don't work the same way in all LISPs).
> 
> (Perhaps the authors of Reddit simply were more
> comfortable with a scripting language like Python, and
> switched when they ran into problems? It didn't sound
> like it was a huge effort to port the application to a
> whole new _language_, after all.)

  No.  They were using CMUCL in production and CLISP in development.  Sockets and threads don't work the same way between the CMUCL and CLISP implementations.  And the production CMUCL environment would crash all the time.  CL apps have to be married to a particularly implementation of CL.  But those implementations don't run on every OS (or even most OSes), meaning that you are often tied to an OS too.

  Besides, Python isn't just a scripting language.  It is partially interpreted, dynamic, so very similar to erlang in many ways.


> 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.

  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.  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.


> Anyway, the issue of whether to require 100%
> compatibility with Erlang/OTP (later in your mail) is
> moot, since, as Kenneth has told us, EEPs are intended
> precisely for Erlang/OTP.
>
> Best,
> Thomas


Tom