Some claims about Erlang (was Re: Erlang use in Italy)

[Charles Blair]

all right. i cannot let some of these pass me by without comment! :-)

On Mon, Apr 11, 2005 at 05:08:09PM +0200, Corrado Santoro wrote:
> "Programming in Erlang requires much effort, since you must deal with 
> process calculi." (a reviewer of a paper of mine)

as a manager, my criterion for the practical worth of a new (to me)
programming language is, can i learn enough of it in a weekend
(because my schedule is otherwise too busy) to do some fun and/or real
work in it? two languages have passed this test so far: ruby and
erlang. (ruby i don't use, though it stimulated an interesting
benchmarking contest with my lead programmer/analyst in which Ocaml
won hands down; erlang i do. this is because i don't need yet another
object-oriented programming language, though i'm not knocking ruby;
it's just that functional languages are more "edgy," and "edgy" is
quite frankly cool.)

> "Programming in Erlang seems easy, but the source code is quite 
> unreadable; maybe we could try to find a syntax that is less complex."

uh: erlang is the _only_ language in which i've programmed that i can
go back to some code i've written some months back _without comments_
and pretty much pick up from where i left off. this is a big win from
both a programmer's and a manager's perspective. i could argue that
the strictures that erlang imposes make this possible.

> "Erlang? 'quick-and-dirty'. I dislike this kind of approaches! I prefer 
> Java."

quick and clean is more like it. to me "dirty" is the kind of
side-effectful thing that other languages either promote or connive at.

> "What are the performances of Erlang? It's bytecoded! It never reach the 
> performances of Java" (forgetting the performance problems Java had in 
> the past, and the *huge* amount of time required *now* by Eclipse to start!)

to paraphrase mr. rogers, "can you say 'memory hog,' boys and girls?
i thought you could." java is a pig.

> "Who is teaching Erlang? All students take the degree learning C, C++ 
> and Java. This is what companies require" (a professor forgetting that 
> students should learn *how to program*, not *how to program with a 
> specific language*).

i _do not want to hire_ people simply because they have a specific
kind of _training_: i need people who can _think_ (not to mention a
good "bedside manner" when it comes to dealing with end-users: in a
smallish shop without a dedicated help desk this is essential);
effective thinking in this field typically requires a combination of
aptitude and experience; how experience is come by is largely
immaterial.

programming is a talent. yes: a good artist can be enriched by
training, but training alone cannot make a good artist. there's got to
be some knack there beforehand. a good manager is on the lookout for
talent; training one can provide on the job, if one can afford it.