TITLE: Some Thoughts on "Perlis Languages"
AUTHOR: Eugene Wallingford
DATE: August 18, 2011 3:52 PM
Fogus recently wrote a blog entry,
that has traveled quickly through parts of software world.
He bases his title on one of Alan Perlis's
"A language that doesn't affect the way you think about
programming is not worth knowing." Long-time Knowing and
Doing readers may remember this quote from my entry,
Keeping Up Versus Settling Down.
If you are a programmer, you should read Fogus's article,
which lists a few languages he thinks might change how
you think about programming.
There can be no single list of Perlis languages that works
for everyone. Perlis says that a language is worth knowing
if it affects how you think about programming. That
depends on you: your background, your current stage of
development as a programmer, and the kind of problems you
work on every day. As an example, in the Java world, the
rise of Scala and Clojure offered great opportunities for
programmers to expand their thinking about programming. To
Haskell and Scheme programmers, the opportunity was much
smaller, perhaps non-existent.
The key to this epigram is that each programmer should be
thinking about her knowledge and on the look out for
languages that can expand her mind. For most of us, there
is plenty of room for growth. We tend to work in one or
two styles on a daily basis. Languages that go deep in
a different style or make a new idea their basic building
block can change us.
That said, some languages will show up lots of peoples'
Perlis lists, if only because they are so different from
the languages most people know and use on a daily basis.
Lisp is one of the languages that used to be a near universal
in this regard. It has a strangely small and consistent
syntax, with symbols as first-order objects, multiple ways
to work with functions, and macros for extending the language
in a seamless way. With the appearance of Clojure, more and
more people are being exposed to the wonders of Lisp, so
perhaps won't be on everyone's Perlis list in 10 years.
Fogus mentions Clojure only in passing; he has written
one of the better early Clojure books,
and he doesn't want to make a self-serving suggestion.
I won't offer my own Perlis list here. This blog often
talks about languages that interest me, so readers have
plenty of chances to hear my thoughts. I will add my
thoughts about two of the languages Fogus mentions in his
Joy. *Love* it! It's one of my favorite little
languages, and one that remains very different from what
most programmers know. Scripting languages have put a lot
of OOP and functional programming concepts before mainstream
programmers across the board, but the idea of concatenative
programming is still "out there" for most.
Fogus suggests the Forth programming language in this space.
I cannot argue too strongly against this and have explained
my own fascination with it in
a previous entry.
Forth is very cool. Still, I prefer Joy as a first step
into the world of concatenative programming. It is clean,
simple, and easy to learn. It is also easy to write a Joy
interpreter in your favorite language, which I think is one
of the best ways to grok a language in a deep way. As I
mentioned in the Forth entry linked above, I spent a few
months playing with Joy and writing an interpreter for it
while on sabbatical a decade ago.
If you play with Joy and like it, you may find yourself
wanting more than Joy offers. Then pick up Forth. It will
not disappoint you.
APL. Fogus says, "I will be honest. I have never used
APL and as a result find it impenetrable." Many things are
incomprehensible before we try them. (A student or two will
be telling me that Scheme is incomprehensible in the next few
weeks...) I was fortunate to write a few programs in APL back
in my undergrad programming languages course. I'm sure if I
wrote a lot of APL it would become more understandable, but
every time I return to the language, it is incomprehensible
again to me for a while.
David Ungar told one of my favorite APL stories at OOPSLA
2003, which I mentioned in
my report on his keynote address.
The punchline of that story fits very well with the theme of
so-called Perlis languages: "They could have done the same
thing [I] did in APL -- but they didn't think of it!"
There are modern descendants of APL, but I still think there
is something special about the language's unique character
set. I miss the one-liners consisting or five or twenty
Greek symbols, punctuation, and numbers, which accomplished
unfathomable tasks such as implementing a set of accounting
I do second Fogus's reason for recommending APL despite never
having programmed in it: creator Kenneth Iverson's classic
text, A Programming Language. It is an unusually
lucid account of the design of a programming language -- a
new language, not an adaptation of a language we already
know. Read it. I had the wonderful opportunity to meet
Iverson when he spoke at Michigan State in the 1980s, as
my entry on Iverson's passing.
... So, I encourage you to follow the spirit of Fogus's
article, if not its letter. Find the languages that can
change how you think, and learn them. I begin helping a
new set of students on this path next week, when we begin
our study of Scheme, functional programming, and the key
ideas of programming languages and styles.