So now all I'd like in Erlang is...

[Joe Armstrong]

> > >5) A *tiny* implementation (written 99% in Erlang and 1% in ANSI standard
> > C)
> > 
> > How tiny do you want to go?
> > 
> 
> I don't see the point with having a tiny implementation.

  I like tiny implementations  - having a tiny implementation increases
the    chances   that    individuals    can   completely    understand
*everything*. It make things easy to port and embed

> Most important for our customers are stability and speed. If that makes
> the implementation more complex (and it does), that's OK.

  I agree here is a speed x complexity trade off:

  How do we choose been

	simple  and slow
	complex and fast

  I choose the simplest solution which is fast enough.

  Currently  we do  research projects  to improve  performance  at the
expense of simplicity - but  not research into improving simplicity at
the expense of performance.

  Why no research  into "slow and simple?" -  IMHO such research would
lead to Erlang's that are  easily portable into hand-held computers and
embedded devices etc.

  It must be small and beautiful  because I might have to change it in
the future. Beauty  is not in the eye  of the beholder - it  is in the
eye of the maintainer :-)

  At home  my 400 MHz celerion is  way fast enough for  all the Erlang
code I have ever written - I  have now bought a 2.4 GHz machine - This
means I should be able to  "pessimise" the Erlang system by a factor 6
and still get the same performance.

  Suppose  this 6  times increase  in performance  mean that  we could
write software that was 6 times shorter ... now that would be nice.

> 
> However, we don't want NEEDLESS complexity. Some things are still too
> complicated, and we are working on reducing needless complexity and removing
> options that are not used. Unfortunately, having to be backwards compatible
> prevents us from making all changes we want.
> 

  Why  the  backwards  compatibility?  -  *everybody*  (except  project
managers) hates it.

  The only argument I've heard that  bites is "we don't want to re-test
everything" - this argument is correct.

  It  seems like  you have  to combat  "fear of  change"  with "better
testing" - if you could  really test *everything* quickly - then surly
the fear of changes would go away.

  Why do do what everybody else does - put new features that everybody
wants into the "non backwards compatible version" and charge a hell of
a lot to introduce these features into the "old version"

  Cheers

  /Joe


> > If nothing else, I'd like to see most of the BEAM opcode combination
> > stuff in beam_load.c be rolled into the compiler.  This would be a
> > big win in terms of reducing complexity.
> 
> I doubt that.
> 
> The Beam loader is certainly complex, but it is complexity isolated in
> a single place.
> 
> Having the loader there keeps the compiler simpler, and allows us to keep
> the beam file format compatible. Essentially, the format is the same from
> R5B up to R10B and beyond. (In practice, a few minor details prevent you from
> loading and running most R5B modules in R9B and higher, but you can always run
> code compiled several releases back.)
> 
> /Bjorn
>