[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