Erlang is getting too big (Joe over-simplifies things)

[Mike Williams]

In article <Pine.LNX.4.44.0310140912180.14768-100000@REDACTED>,
 joe@REDACTED (Joe Armstrong) writes:
|> 
|>   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.

Vast over simplification! There are many reasons why SW projects fail. Perhaps
the most common one is that the project solves the wrong problem (i.e. the spec
was wrong). Another reason is that the SW is never "designed", it just 
"happens" resulting in a system with no well though out modularisation, no
policies for error recovery, no thought behind concurrency etc etc. I've seen
them all (and so have you Joe :-).

What I think you mean, Joe, is:

The main reason why software systems are unstable (crash often) is that errors
propagate between modules.

The main cause is languages with unsafe pointers (C, C++) and explict memory
allocation / de-allocation. There are two ways to solve this.

1) Don't use languages with unsafe pointers

2) Use an OS with sufficienty fine MMU protection that a pointer error in 
one thread can't clobber another thread.

Erlang is approach #1. What Erlang does not solve (and, for obvious reasons
no other language does either) is the propagation of errors between parts of the
system by sending erroneous data in messages or function calls. What Erlang
helps with is the "let it crash and some other process clean up the mess"
philosophy of error handling encapsulated in Erlang and OTP. 

/mike