
The myth of the Lisp genius - rsaarelm
http://www.johndcook.com/blog/2011/04/26/the-myth-of-the-lisp-genius/
======
swannodette
The myth is also bolstered by some of greatest book on the craft of
programming ever written:

    
    
      * The Structure and Interpretation of Computer Programs
      * Paradigms of Artificial Intelligence
      * Art of the Metaobject Protocol
      * The Schemer Series (Little, Seasoned, Reasoned)
      * Essentials of Programming Languages
      * Lisp in Small Pieces
    

Few programming languages have such an abundance of truly deep gems. One has
to wonder if there's a reason.

~~~
Maro
I don't think this argument stands. There are just as many great C books out
there:

    
    
      * C Programming Language - by K&R
      * The Indispensable Guide to C with Engineering Applications - by Paul Davies
      * C Interfaces and Implementations - by David Hanson
      * A Retargetable C Compiler: Design and Implementation - by David Hanson
      * Graphics Programming Black Book - by Abrash with lots of Quake goodies

~~~
sedachv
I don't understand why people keep citing K&R as a great book. It's a fairly
mediocre introduction to C programming. Harbison and Steele is much more
useful IMO.

~~~
SoftwarePatent
I found K&R a difficult slog. It could have had twice as much explanation
text.

------
oconnore
[Meta] What is it about Lisp that makes it the subject of so many blog posts
by people who almost certainly don't use it on a day to day basis? Is it some
sort of insecurity about their current environment? Is it just a go to topic
when you can't think of anything better? Why don't Haskell and Erlang attract
the same attention, though both make big claims too (e.g. the type system
makes programs correct, the actor model solves concurrency...)

Lisp has some unique features. Some people like them, and feel more productive
using them. Other people don't, and prefer other languages. Can we move on
now?

~~~
mattgreenrocks
Have you noticed how many articles are about C around here? As I said in
another thread, there's too many benefits to discussing C/Lisp/Git: strong
opinions (thus, traffic), karma, and illusory in-group status.

If we want to fix Hacker News, we need a way to stop these sorts of karmic
feedback loops from setting themselves up, because they are echo chambers.

(Also, it'd be nice if bloggers didn't measure post success by traffic, but we
all know that isn't going to change.)

~~~
prewett
How would you prefer bloggers to measure success? I assume that most writers
would measure success in readership, influence, or money. Traffic seems pretty
close to readership. Influence is harder to measure, but generally the more
readers, the more influence. And money from a website is generally
proportional to traffic.

~~~
mattgreenrocks
Well, I'd wish they'd measure it by the quality of their writing and the
discussion it generates instead of hits. But it's up to them how to measure
success.

I'm only concerned with how that perception of success affects HN. Presently,
it's too easy for bloggers to choose to discuss A Most Excellent Technology in
the hopes of making the front page. The actual writing may not make any points
beyond, "vim changed my life!" but, still, it's put on the front page by the
bikeshedding committee, thus perpetuating the feedback loop. You may argue
that certain tools have a favored status within certain groups, and that is
fine -- I'd prefer if people were picky about their tools. But the standard
must be raised on bikeshedding articles beyond mere sentiments of "I like this
technology." There needs to be an intellectual gain made from the blog post,
not simply an opinion being expressed.

Otherwise, HN risks becoming like every other social news site, where people
upvote the articles they want to see to the point of creating more noise than
signal. We are still have quite a ways to go before we're there, but the
recurrence of topics is a bit troubling.

------
bambax
> _If one person does a job in half the time of another, maybe it can be
> attributed to their choice of programming languages. If one does it in 1% of
> the time of another, it’s probably a matter of talent._

This has been discussed many times (recently, somebody attributed a
significant difference in productivity among programmers to... the ability to
touch type).

Anyway, why different tools could _in principle_ not be able to generate
wildly different productivity outcomes?

"If you only have a hammer" can be reversed: _if you don't have a hammer_ ,
then planting nails becomes incredibly difficult and takes a great amount of
time (and ingenuity). A (not too practical-oriented) friend of mine once
called me because he had spent an hour and a half trying to screw together a
simple Ikea bookshelf (where the documentation said it could be done in less
than 10 minutes). Turned out he was trying to screw the big bolts with pliers,
and that's really hard.

~~~
cubicle67
This kind of argument irks me slightly. I think it's partly the "Lisp is
awesome, only a genius can really understand. btw, did you know I use lisp?"
attitude, and partly because, well, for all you geniuses who are so awesome
and productive, there's not a hell of a lot to show for it.

You've had fifty years, ffs, and what have you got to show for it. Some furry
guy who wrote emacs 40 years ago? Why is it that the web was built with php
and perl? Why my desktop apps are still mostly written in C? You've had you're
arse handed to you on a platter by every language (just about) since fortran.
Stop waxing lyrical about how great lisp it, and get out there and prove it,
dammit.

Lisp may be a great language, but it's proponents don't seem all that great at
getting stuff done

~~~
dman
Do not undermine network effects. C/C++ have had unbeatable network effects
going on for them for a very long time now. Most systems are shipped with C
based drivers and apis (Opengl, posix etc). Writing code in Lisp (Or any other
HLL) means that you have to first write a binding for said library which is
lispy, then build a system on top of that. Also then data has to be marshalled
/ unmarshalled from the C data structures into your language specific data
constructs - this has a penalty in terms of speed. And finally you have to
wrap the unmanaged c/c++ code so that it has an idiomatic (in lisp) garbage
collection and exception handling story. In short - to write systems level
lisp code requires you to be a jedi in C, api design, lisp and sheer code
writing (because you have to essentially recreate the convenient wrappers that
intel/ nvidia etc write in C).

Put another way - in 10 years if HTTP/Javascript continue on the same path
people could arguably say the same thing - "some furry guy wrote Linux in C,
but what has C done for the world recently? All the cool apps being built
recently are in Javascript/HTML on the frontend and Python/Ruby on the
backend"

~~~
spc476
But Lisp is older than C by 15 years and _still_ lost out?

~~~
lispm
It did not really compete that much. The target audiences and target domains
are really different.

C was invented as a replacement for assembler to portably write operating
systems and applications in a slightly higher-level notation.

Lisp was invented as a tool for computing with symbols (computer algebra,
theorem prover, game playing, natural language processing, expert systems,
knowledge representation, ...).

~~~
spc476
Then what about the Symbolics and Lisp Machine guys?

~~~
lispm
when the Lisp Machines were invented in the mid 70s (as personal workstations
for research programmers mainly in AI) and commercialized in the early 80s
there was nothing to compete with. When alternatives were available, there was
no longer the need to have those (and they were not competitive), so they died
away.

------
zwieback
I learned C and Lisp at exactly the same time, during a six month internship
in 1988. I wrote a program to interpret hand sketched input on a tablet and
turn it into a CAD model.

Before I started I only knew Basic and a little Fortran but the project I
worked on required me to learn these two new languages, C for the low-level
code that interfaced to a graphics tablet and the display driver, Lisp for the
code that did some analysis on the lines and geometric shape drawn by the
user.

I remember that on days I was working on the Lisp code I was happy and things
seemed in harmony. On C days I often ended the day worried and headachy.

However, I couldn't have written the C portion in Lisp and writing the Lisp
portion in C seemed unreasonable at the time as well.

What I take from the experience is that, to some extent, Lisp seems so much
more productive is that it's typically chosen for programming tasks that don't
deal with the ugliness and "hardness" of things like drivers or other low-
level code. Not sure about GUIs but that's another area where programming
becomes tedious and unfun, at least for me.

So, I don't think that Lisp is chosen for easier tasks but definitely for
tasks where a solid grounding in CS and an ability to think abstractly is more
important and there's some level of self-selection going on in those areas.

~~~
Jach
> Not sure about GUIs but that's another area where programming becomes
> tedious and unfun, at least for me.

When I have problems with UIs it's because there's a lack of separation in
structure, design, and scripting that you get with HTML+JS or
MXML+ActionScript which both make UI dev really easy and fun. In contrast, I
think Swing, AWT, WxWidgets, Tkinter, GTK, Windows API, .NET, and even Qt make
graphics programming a pain in the neck (some more than others). But once you
get toward a more web-approach of UI, s-expressions are a perfectly fine way
of representing XML too. Tags are functions, Perl realized that as well.

My own experience with writing low level software is that without a good
support library you're going to be doing assembly that may be painful
depending on the microcontroller and what you're interfacing with. (ARM stuff
is pretty good.) If there are good bindings for higher languages like Lisp,
programming in Lisp becomes nice again. PyGame is a great example of porting a
(in my view) somewhat ugly C library that is SDL and making it nice and neat
to use in the higher level Python. I know a team in Colorado who are using
Flex to build a multi-touch application on a USB tablet.

In the face of no good library though, C is definitely a great choice and it's
useful for augmenting assembly. If I want to worry about memory and pointers,
C's my goto language.

~~~
zwieback
Very true. 99% of my work is C on small, embedded ARMs now and we don't have a
display so no need to worry about GUI directly. However, we do have web
servers and the GUI work has become more pleasurable with HTML+JS and/or
(gasp!) PHP.

------
agentultra
I terribly dislike the hypothetical Lisp creature described by the Bipolar
Lisp Programmer. It has little basis in reality and is probably the greatest
straw-man argument I've seen. Though calling it an argument on my part is a
kindness; it's more of a soap-box.

There are just genius programmers.

Lisp just happens to be a pretty good language.

The two are quite orthogonal to one another.

~~~
sokoloff
I wouldn't expect a genius programmer to end up with a random choice of
language, especially after a few years and exposure to a variety of languages.

If you agree (as I do) that there are differences in "power" of language, I
would expect that genius programmers would be far more likely than average to
choose a language of above-average power.

Thought experiment: How many genius programmers do you know that use VB6 by
choice?

~~~
agentultra
I'm not sure I know any genius people let alone programmers.

And I definitely do not know of anyone who programs in VB6.

However, I am some what familiar with John Carmack. I would consider him a
genius programmer. Yet he uses C++ almost exclusively. You would have to ask
him if he thinks it's the most powerful language available to him. However, I
would hazard a guess that his choice of C++ was incidental
(<http://rome.ro/smf/index.php?topic=3086.0>) -- it just happened to be the de
facto lingua franca for developing graphics intensive video games.

By _orhtogonality_ I mean to imply that attributes of one are not affected by
the other. Lisp is and will continue to be a powerful language with or without
genius programmers using it. In fact, if genius programmers are exceptional
and rare as we say then I would imagine Lisp has developed over the last fifty
years almost exclusively without the help of geniuses. Similarily, not all
geniuses will think to use Lisp; yet they will still be exceptional
programmers and produce exceptional software.

 _Update_ : Included link to thread about an alleged response from Carmack to
an email asking about C++. Apparently he uses it and has used it since Doom3.

~~~
chris_j
EDIT: I stand corrected: It looks like John Carmack has indeed been using C++
since Doom 3. I sheepishly admit to having based my believe that he still used
C on having looked at the Quake 3 source code many many years ago. What next,
Carmack decides that he prefers Direct3D?

Point taken about the orthogonality of language choice and programming
ability. There are great programmers who use Lisp, there are great programmers
(like Mr Carmack) who use C and then there are great programmers like Richard
Stallman who can write Emacs in Lisp and then write GCC in C (albeit with a
Lispy flavour).

~~~
agazso
"I actually think Direct3D is a rather better API today. [For example],
Direct3D handles multi-threading better, [while] newer versions manage state
better," Carmack told Custom PC.

<http://www.google.com/search?q=carmack+prefers+direct3d>

:)

------
Jd
There definitely is something psychological as well as practical.

First, it is an issue of social dynamics. Very intelligent people frequently
develop means by which they congregate without the less intelligent. Elite
academic institutions facilitate this. The corporate world does not. As far as
I can tell, lisp was the anti-blub when there was only blub, which allowed
people to distinguish themselves from their peers -- a bit like going to Mensa
meetings. This need seems to be less pronounced in the younger generation
since there are other distinguishing languages in fairly common use.

Second, there is current research in neurobiology that indicates that the
evolution of the brain (perhaps responding to its environment) has a naturally
recursive structure and there is a growing field in the study of religion and
philosophy that indicates that the growth of many systems has a fractal
structure. In fact, Mandelbrot commented on this himself in response to
Lovejoy's Great Chain of Being, although he never applied it to the
correlative systems of the East, nor the syncretist projects of the
Renaissance. These are frequently associated with genius for good reason. I
suspect Lisp is popular because of how it "clicks" with something mentally.

Third, it is not quite clear how any of this relates back to programming as a
craft. Philosophers can create their own discrete systems. Mathematicians,
even if they don't deal well with other people, are, at least ostensibly,
dealing with reality. Lispers, on the other hand, frequently must deal with
real products for real people. Realistically this means that products must
have significant scope, which almost invariably means more than one person
working on them (actually products are rarely brilliant, though inventions may
be). Which is to say, the "inventive" aspect, which may be contained and
individual, is likely distinct from the practical aspect, which is collective.
Obviously certain features (e.g. static typing, immediate comprehensibility
when viewing method/class names, etc.) would seem to be preferable for large
collaborative projects.

In conclusion, although it is said "real artists ship," it is often the case
(e.g. Van Gogh, Schopenhauer) that real artists languish unacknowledged, their
brilliance unappreciated in their own time. Art, when pursued for its own
sake, rarely can deal with practical considerations -- which may good for the
increase of knowledge generally or the field of computer science, but bad for
business (insofar as business is making money right now).

------
mark_l_watson
I think a lot of the Lisp hype stems from the development environment. I was
too tired on a cross country flight last night to do customer work, but I did
work on two of my own projects: one using Java, IntelliJ, and the excellent
Play! framework (dynamically compiles code while editing - fairly agile
environment) and later another project in Common Lisp. Using Emacs + Slime +
Common Lisp, at least for what I was working on (NLP stuff), just felt great.
Two nice environments, but the Lisp environment was just more comfortable.

------
algoshift
I'll take this up a few notches and proclaim that almost all commonly used
languages offer "high impedance" when it comes to the jump from thought to the
expression of that thought for a machine to execute. This does not mean that
they are not useful. It does mean that they are very primitive in many ways.

My life as a programmer and hardware designer started when I hand-built (wire
wrapped) my first 8080-based computer way-back-when. Coding was done typing in
hex codes into a hexadecimal keypad. Pretty amazing what you could write that
way. Wanting more, I wrote a simple version of Forth. Wow! The productivity
gain was impressive. Meanwhile, in College, we had to take FORTRAN. I hated it
for some reason. Then my Physics professor offered an alternative: If you
signed-up for his APL class you could get equivalent credit. Out went FORTRAN,
in with APL. I would not learn C until three years later.

The fact that my real programming life started with exposure to the extremes
represented by hand-coded hex, Forth and APL probably made me think very
differently once I got to C and other languages. APL allows you to think and
translate those thoughts and ideas to computer instructions with very little
to distract you. The process of programming in C-like languages can be very
mechanism oriented rather than problem oriented. By this I mean that you spend
a log of time working on how to get the mechanics of the thing to work rather
than focusing on the problem domain.

I learned and programmed in Lisp extensively later in life. It was the AutoCAD
version of Lisp. I wrote all sort of tools and utilities for AutoCAD and can
say that I enjoyed using the language. In terms of productivity and the
ability to quickly express ideas, I think it did pretty well. Is it the realm
of geniuses? Nothing is.

------
nickik
How about shouting up about the lisp this or that and just think of it as a
normal programming language with some features that most programmers dont
understand because the never learned them in school job.

These lisp geniuses are just programmer that grew up in a time where lisp was
often used. So the are "just" programming geniuses.

Lisp does not make medicore programmers 10x better. Its just a very good
programming language.

P.S. Back then it did make you much more productive because all other
languages where way behind not like knowdays.

~~~
rbanffy
> Lisp does not make medicore programmers 10x better.

No language will. OTOH, no mediocre programmer will grok Lisp.

~~~
Typhon
Depends on what you mean by "grokking Lisp". If it means a full exploitation
of all the language's possibility, I agree, but it seems a bit obvious that a
mediocre programmer would be unable to do that. If it merely means being able
to program in the language, that's not true.

------
quinndupont
This article scares me. My mediocre programming skills will never be able to
handle Lisp. Damn.

~~~
cturner
Never give up on goals you still care about. Get a beer and some notepaper.
Write down some notes about how you can be a better programmer. Think about
topics slightly out of the domain - how you represent ideas, how you explain
ideas to people, how you try to understand ideas that are explained to you,
how you read code. Think about how you can improve. Think about some
deliberate practice exercises. Take what's useful from doubters and ignore the
rest. You'll get there.

~~~
reginaldo
Also you can watch the lectures by Abelson and Sussman themselves[1], also on
MIT OpenCourseWare.

[1] [http://groups.csail.mit.edu/mac/classes/6.001/abelson-
sussma...](http://groups.csail.mit.edu/mac/classes/6.001/abelson-sussman-
lectures/)

[2] [http://ocw.mit.edu/courses/electrical-engineering-and-
comput...](http://ocw.mit.edu/courses/electrical-engineering-and-computer-
science/6-001-structure-and-interpretation-of-computer-programs-spring-2005/)

------
cpr
Others (e.g., PG) have written more elegantly about this topic, but I really
do think the key is the complete malleability that Lisp gives you: you're free
to recast the problem in your own terms, using whatever DSL makes the most
sense, and program in those higher-level forms.

Other languages force you into specific toolsets (objects, functions, etc.)
and thwart pure expression of the problem.

~~~
apl

      > Other languages force you into specific toolsets
      > (objects, functions, etc.) and thwart pure expression of
      > the problem.
    

Pure expression and complete malleability are decidedly non-intrinsic goods.
Sure, you're free to reshape your language according to the requirements of
the task at hand, but that process takes tremendous amounts of experience and
care and foresight. If you lack these qualities, Lisp isn't going to get you
anywhere. Even worse: it may end up being counterproductive.

Graham made such successful use of Lisp because he was a highly competent
engineer, and thoroughly familiar with CLisp. Firing up SBCL doesn't grant you
these abilities qua choice of language. So I'm glad that some people still
offer counterpoints to the Lisp cargo cult around here.

~~~
cpr
I think you've just restated his "Blub" position exactly.

~~~
apl
Possible, but irrelevant given that I'm not arguing against Graham's stance.
I'm sure he's right about "blub" and so on: Lisp is a tremendously useful tool
in the right hands. What I find increasingly annoying are the countless
acolytes that ignore the actual point and simply repeat "MACROS! MALLEABILITY!
DSL!" like a vacuous mantra.

------
abecedarius
"I think of Donald Knuth writing TeX in Pascal, and a very conservative least-
common-denominator subset of Pascal at that. He may have been able to develop
TeX faster using a more powerful language, but perhaps not much faster."

Knuth himself said he didn't think he could have written TeX without his
literate programming tools, right? Which fits the pattern of Lispers extolling
metaprogramming, though without their built-in support.

(Despite which, I don't in fact think Lisp makes you a genius, or even
significantly better than with other popular languages -- though it was a
different story back in the 80s when I learned it.)

------
pohl
_Lisp imposes almost no structure,_

I'm a lisp novice, but doesn't it impose functional composition? And isn't
that some mighty structure?

~~~
pdelgallego
CLisp, for example, is not a functional language in the sense of ML language
or Haskell.

CLisp is a multi-paradigm language. You can use it in a OOP or a functional
style. You can even use its OO features in a functional way and viceversa. E.g
Objects are poor's people closures. [1]

[1] <http://c2.com/cgi/wiki?ClosuresAndObjectsAreEquivalent>

~~~
xyzzyz
Hate to be pedantic, but there is no such language as CLisp. There is Common
Lisp language, commonly abbreviated to CL, and CLisp is the name of one of its
implementations -- the other popular ones are SBCL, Clozure CL, Allegro CL, to
name a few. One should not identify Common Lisp the language with CLisp the
implementation, especially since it is not the fastest or the most pleasant
one.

------
Tichy
Even if you are not a superprogrammer, if you work your way through SCIP
you'll have greatly improved your skills. Maybe you can still become a
superprogrammer.

I doubt it would be possible to become a superprogrammer by coding Java
because you would be too busy trying to comply with all the specifications.

------
tom_b
I suspect there may be something to the idea of Lisp supporting multiple
paradigms of development. If (and this is a big if) you had enough exposure to
the virtues of imperative, functional, and declarative programming styles and
(second big if) enough "taste" to apply them in tandem with each other, that
Lisp may have been one of the few places to leverage that as a skill.

But maybe a better question would be how often you would be better mixing
those types of development in a single program.

------
lisper
[http://rondam.blogspot.com/2011/04/is-it-lisp-or-is-it-
me.ht...](http://rondam.blogspot.com/2011/04/is-it-lisp-or-is-it-me.html)

------
michaelochurch
Lisp is good, and every good programmer needs to be familiar with it-- if
nothing else, in order to know what she's missing in other languages-- but I
find that a lot of Lisp people start using Lisp (in a humorous reversal) as
their own Blub. To them, it's Lisp-versus-Shit. I find this mentality
incredibly short-sighted.

Strong, static typing is really great. It may not be appropriate to every
problem, but it saves a lot of time in the long run. Just as every programmer
ought to spend a year in Lisp, every programmer should spend a year in a
Hindley-Milner static-typing language.

My feeling about dynamic typing is that it test-drives really well, but it's
not great for a 6,000-mile road trip. Lisp definitely beats Haskell and Ocaml
in the former regard, and for small projects, I don't think there's any
language that can be faster. On the other hand, for a large project with 5
developers, experience has led me to conclude that I'd much rather be using a
statically-typed language.

~~~
brlewis
If you're right about Lisp's suitability for small projects and Haskell and
Ocaml's suitability for long projects, then that answer's oconnore's question
about why the strongly-typed academic (as of 2011; not inherently academic)
languages don't attract the same mythology: Seeing something get done in half
an hour that you expect to take all day leaves a much stronger impression than
seeing something get done in a month that you expect to take six months.

~~~
michaelochurch
Correct.

Another problem languages like Ocaml and Haskell have is this: most
programmers have a very predictable trajectory through increasingly more
powerful languages: C++, then Java (garbage collection), then Python or Ruby
(more abstraction and power), then Lisp, which has the aura of being the
pinnacle of languages, one that removes all the accidental complexity and
leaves programmers able to tackle the intrinsic complexity of the problem.
Strong, static typing seems like a step backward-- some seatbelt that was
thrown away at the Java-to-Python transition. It's not, and Hindley-Milner
type inference ensures that the static typing doesn't even eat up much
developer time, but the benefits of static typing don't appear until you work
on a larger project where debugging and testing become major concerns. The
difference between a 40% and an 80% debug/test overhead is enormous, but
aren't going to show up on a 500-line project.

Strong static typing is an awesome tool that the language forces you to use.
Lispers don't like being "forced" to do anything. However, on a project of
sufficient size, the relatively minor drawbacks of static typing are more than
paid off by the reduced test/debug overhead.

~~~
kenjackson
_most programmers have a very predictable trajectory through increasingly more
powerful languages: C++, then Java (garbage collection), then Python or Ruby
(more abstraction and power), then Lisp_

I've seen virtually no one take this trajectory. Half of the Lisp programmers
I know had Lisp as one of their first languages (MIT or Berkeley alum). Most
C++ devs that went on to Java or C# did NOT go to Ruby or Python. Most C# devs
would consider that a step backwards unless you were using a specific
framework for a specific task, e.g., Rails.

The only thing I do tend to agree with is that Ruby/Python devs seem to have
Lisp envy. But very few others classes of developers do.

~~~
SoftwarePatent
"Half of the Lisp programmers I know had Lisp as one of their first languages
(MIT or Berkeley alum)."

We also learn Scheme as our first language at Indiana University computer
science@

------
jpr
I would like to say one thing to anyone who considers using Lisp:

 __It's perfectly okay to use Lisp just like you would use any other language.
__

It's better designed and more consistent than most others, and has good
implementations. It makes sense to use Lisp as just a regular language without
any wizardry.

