So now all I'd like in Erlang is...
Mon Feb 23 12:30:50 CET 2004
> > >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"
> > 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.)
More information about the erlang-questions