Erlang is getting too big (Long and a lot of shouting :-)

[Joe Armstrong]

  Is Erlang big?

  Should it grow?

  Before we all get to overexcited about this I'd like to get my own 5
cents in ...

  When  discussing  language  design/properties  all  things  are  not
equally important - we are talking as if they were.

  For many years I have thought about what makes a language successful.
  
  Here are two good answers:

	1) - Somebody makes money by using language X
	2) - X is superbly good at solving some particular problem
	     that no other language can solve adequately 

  The guy who say 1) also said (paraphrased) " I became interested in
Erlang  because I discovered  that people  were prepared  to invest
their own $ in it".

  For point 2)  - sure you can write anything  in any language (Turing
equivalence) - but this does not mean it is equally difficult. I guess
if Erlang is  10 to 100 times better than language  X for a particular
application then it  has some chance of succeeding  in that particular
niche.

  So to succeed 1) and 2) have to satisfied

	<< note I haven't mentioned deep guards :-) or parameterised modules >>

  Simplicity (though I love it) is not on my list - whatever else Java/C++/Perl
have it's certainly not simplicity ...

  Cobra and the XML morass are certainly not simple ... and programming things
like the windows API are so complicated that entire tool-making industries have
emerged to try and hide bits of the complexity.

  Entire armies of consultant *love* complexity - 

  Complexity = Job opportunities

  Back to the argument.

  IMNSHO Erlang is good at concurrency.

  It should be is was DESIGNED TO BE GOOD AT CONCURRENCY (The guy four
doors down  the corridor  wonders why I  am pounding the  keyboard so
hard :-)

  I think (I  KNOW) that language changes that  are aimed at improving
the concurrency are  essential. The world will not  stand still - what
we have done with processes in  Erlang will one day be done in Java/C#
(whatever).

  So what should we do?

  I have said this before:

	- Improve the *isolation* between processes

  This I consider the single most important change to the language.

  I consider ISOLATION (you're banging the keyboard again) to be the
single most important property that a language has.

  What is ISOLATION?

  Two processes are  isolated if one process cannot  bugger up another
process.

  This is "pretty  easy to achieve" on different  machines.  Suppose I
run  one process  in Sweden  and the  second process  runs  on Richard
O'Keefe's machine  in new Zealand -  suppose I write in  Erlang and he
writes in smalltalk - then I hope errors in my program would not crash
his program.

  The *difficult*  bit is  doing it  on the same  machine in  the same
language.

  What is it  that buggers up software projects -  bugs in one program
propagate to other programs.

  -- Yikes  Gadzookes bother  and  blast -  my incomparably  beautiful
fault-free  well tested program  crashed because  I linked  it together
with a program that contained an error.

  The only  way that I  know of to  stop errors propagating is  to use
processes  (ie virtual  machines) -  PROCESSES  ARE USED  TO STOP  THE
PROPAGATION OF ERRORS.

  Erlang was designed for large software projects.

  The principle reason why large software projects fail is because the
software never works.

  The main reason why software doesn't work is that errors propagate between
modules - bad code buggers up good code.

  Unless you can  stop the propagation of errors you  will never be able
to write any decent software.

  For this reason I do not care about syntactic sugar.

  Where should we be going?
  =========================

  * improve concurrency

  I'd like to see more processes with better isolation -

  * GC of everything

  atom tables, code

  * First Order Code

  First order code with GC would be *wonderful* - even better than
structs (which is just sugar)

  * Agent extensions

  SECURITY (sorry I'm shouting again)

  * Interoperability

  This is the "wrapper" stuff I keep yacking on about - integration
of UBF contracts with the language.

  We should not  add things which makes programming  a little bit more
convenient (which is after all what a lot of the language changes do) -
we should add thing so we can easily write applications that nobody else can
write.
   
  Erlang is good at one thing - making large reliable systems.

  That is what it was designed to  do - so YES to all changes aimed at
making it easier to build reliable system software - NO to everything else.

  /Joe

PS - any pleeeeese add the version number of the language to files.

-module(foo).
-version(5.0). <--------------- the language version

Then If we do change the language the compiler can figure out what
went wrong!!!!!