[erlang-questions] erlang sucks

Richard A. O'Keefe ok@REDACTED
Tue Mar 11 22:13:34 CET 2008


On 11 Mar 2008, at 9:11 pm, Ulf Wiger wrote:
> Just like someone saying "kill two birds with one stone" most likely  
> doesn't mean it literally, I would wager that mr ROK did not  
> literally refer to Damien as a whining child - not least because he  
> is not literally offering a lollipop.


For what it's worth, it was an indirect reference to
Alan Perlis's epigram number 93:

	When someone says "I want a programming language in which I need
	only say what I wish done," give him a lollipop.

(See SIGPLAN Notices Vol. 17, No. 9, September 1982, pages 7-13.)
Epigram 73 is also relevant:

	It is not a language's weaknesses but its strengths that control
	the gradient of its change: Alas, a language never escapes its
	embryonic sac.

Epigram 93 got cross-linked with the fact that I *have* children who  
*do*
whine sometimes (well, one of them has experienced pretty much  
constant pain
for over a year and the hospital are having no luck diagnosing it; she  
can
bear it but it's no fun) and I *have* found it rational to offer a  
lollipop
from time to time (distraction is an approved method of coping with  
pain).
Some times there are other things you have to do, and there isn't any  
point
in arguing any more.

Take strings.  3 decades of computing have convinced me that in any  
and every
language STRINGS ARE WRONG.  Perl is the perfect example of how easy a
language can make it to write the wrong program (a program that does the
wrong thing, and does it badly).  I keep a book on my shelves to show  
to Perl
fans:  it's a book explaining in all earnest how to do some useful  
things in
Perl, and every single program in it has at least one fundamental flaw  
that
means it will mostly work most of the time, but break when you need it  
most.
One of the reasons I found C to be a vastly better language for text  
processing
than PL/I (yes, I'm old enough to have been a PL/I programmer) was  
that C did
NOT have a built in string data type.  One of the reasons that my C  
code can
still make student C++ code look like a sick snail is that C does not  
have a
built in string data type, and C++ these days does.  As for Java,  
let's not go
there.

I suspect that there are two things that influence my views which many  
others
do not share.  First, a taste for minimalism.  In many respects Erlang  
is a
minimalist language, in contrast to C++, which is a maximalist  
language (except
where it might be useful; the arguments against nested functions that  
made
sense for classic C are absurd in the context of C++).  Second,  
experience with
several declarative languages and familiarity with the "trees are  
trivial" way
of thinking that goes with that.  I have been shocked at how hard our
Java-trained students find trees to be; it's a safe bet that someone  
with a
C++ or Java or Perl or Python or Ruby background not only isn't going  
to think
of an alternative to strings for representing text, they aren't going  
to find it
imaginable that there might _be_ an alternative or that it might be  
desirable.

One particular experience sticks with me.  Before learning Prolog, I  
learned
Interlisp.  I was impressed by the Interlisp pattern-match compiler.   
Boy,
that was cool.  I thought.  When I met Prolog, I said to myself: "I  
would like
to have something like the Interlisp pattern-match compiler for  
Prolog.  What
I'll do is work through the Lisp pattern constructs and see how they  
can be
translated to Prolog, and then I'll write a compiler, using  
term_expansion/2."
But by the time I had finished seeing how to convert an Interlisp  
pattern to
Prolog, I didn't want Interlisp patterns any more.  That was for two  
reasons.
The first was that I could now write whatever Interlisp pattern I wanted
*directly* in Prolog, and it looked rather better.  The second was  
that I
realised that I should usually be using trees, not lists, so that I  
didn't
*have* to do complicated pattern matching.

So when people go on and on about wanting strings in Erlang, I find  
myself
wanting to shout THINK! MEASURE! IMAGINE!  Or "if you want Perl, you  
know
where to find it".  But there comes a point where you realise that  
that is
no longer rational.

The fact that we now have to deal with Unicode, which is much more
complicated than most programmers realise, means that a string data type
would *now* do more than soothe people crying for the old familiar ways
of doing things.  It really could make it easier for people to write
correct Erlang programs, by packaging up all the things that Unicode  
makes
tricky.  It *is* in the spirit of Erlang/OTP to provide support for
something tricky useful in communication, and binaries (which are  
logically
redundant, given tuples and integers) show that it's in the spirit of  
Erlang
to provide such support even at the expense of minimalism.





More information about the erlang-questions mailing list