Some claims about Erlang (was Re: Erlang use in Italy)
Tue Apr 12 05:54:41 CEST 2005
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
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
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.
More information about the erlang-questions