

Response to John Cook's "Myth of the Lisp Genius" - lisper
http://rondam.blogspot.com/2011/04/is-it-lisp-or-is-it-me.html

======
bad_user
Not that I don't agree with some of the points raised, but the article's
purpose is to be a refutation to this claim:

    
    
         There are genius programmers who write Lisp, 
         and Lisp may suit them well. But these same folks
         would also be able to accomplish amazing things in 
         other languages.
    

Languages and tools are not created equal, but the author assumes he's one of
those geniuses, which may not be the case.

Extraordinary developers do extraordinary things, regardless of the tools
used. Here's an example, using as reference
<http://en.wikipedia.org/wiki/Git_(software)#Early_history>

_The development of Git began on April 3, 2005. The project was announced on
April 6, and became self-hosting as of April 7. The first merge of multiple
branches was done on April 18. Torvalds achieved his performance goals; on
April 29, the nascent Git was benchmarked recording patches to the Linux
kernel tree at the rate of 6.7 per second._

And here's the kicker: Linus would probably be more productive in LISP, but
would he bring more value to the world? Probably not, as churning out code is
not Linus' strength -- he outcompetes everyone by superior design, by
pragmatism and by being a good team-leader.

That's the type of developer I admire -- people that kick-ass in bringing
value and making sacrifices is part of that. Sometimes you have the luxury of
picking up a new language (Ruby) and invent a new web framework with it
(Rails), sometimes you don't. Either way, code talks bullshit walks (so to
speak).

~~~
lisper
> the author assumes he's one of those geniuses

Exactly the opposite actually. Not only do I not assume that, I specifically
deny it.

~~~
SeanDav
Actually, even though you deny that you are a genius I think you are. I don't
think your article refutes the original article by John Cook at all as you are
one of the very small percentage of people that can "make things happen" in
Lisp or any other language.

I would suggest you are too much of an engineer to use an "inferior" tool like
C++ or Java because you know there is something "better" otherwise I am sure
you would achieve equally spectacular results in other languages.

~~~
lisper
> you are one of the very small percentage of people that can "make things
> happen" in Lisp or any other language

Although I'm flattered, I have to ask: what possible basis could you have for
making that assessment? My track record certainly doesn't support you.

> I would suggest you are too much of an engineer to use an "inferior" tool
> like C++ or Java because you know there is something "better"

A true engineer solves the problem under the constraints that he is given. I
have a this tendency to try to change the constraints -- or the problem. Those
can be advantageous personality traits for some tasks, but they make me a damn
poor C++ coder.

------
pnathan
I started seriously focusing on learning Lisp perhaps a year ago. My exposure
to Perl had brought me to the point where I understood the idea of functions
as first class in their own right.

Lisp rolled forward my mind into new places of understanding how to program.
It was like having lights flicked on all over the place. I've been able to
conceptualize post-Lisp in ways I did not before.

Perhaps Haskell would have done similar things. I can't say. But Lisp
definitely did, and I believe that given the project (and a sufficient lack of
having to interface into weird libraries), I could do more in a given slot of
time in Lisp than I could with other languages.

~~~
Xurinos
Yeah, Lisp is a really good mind-bender. If you picked up some good experience
with CLOS, I recommend using the Moose packages in your perl work. Moose adds
to Lisp's default CLOS with lazy attributes, roles, and a functioning type
system.

SML, OCaml, and/or Haskell will show you a new way of looking at types (and
secondarily, expose you to unification on a level that is a little deeper than
destructuring-bind). If your background is in perl and then some Lisp
experimentation, I recommend checking these others out in order to fill in
this other nice piece in the equation. Finally, once you have convinced
yourself that type systems are the hotness, it will be good to expose yourself
to Erlang, specifically with regard to error handling and the role of
supervisors for process restarts.

------
agentultra
A brilliant anecdote, yet I am curious how you can still believe in the
dreaded "lisp curse," after experiencing so much success with it.

Is it an attribute of Lisp that there exists a mythical lone-wolf that seeks
to produce software so pure and elegant that no mere mortal can possibly
understand it? Is it an attribute of Lisp that this lone-wolf, like a by-gone
action hero, prefers to work alone?

Lisp, like any sufficiently useful language, simply gives you enough rope.
It's good, sturdy, and well-tested rope. You could probably climb a mountain
with it. Or hang yourself. Your pick. The rope has very little to do with it.

~~~
lisper
I experienced _personal_ success with it. It's not that Lisp _causes_ people
to not be able to work together. The causality runs in the other direction.
Lisp tends to attract people who are antisocial by nature, because if they use
Lisp they can be vastly more productive as individuals than if they don't. But
then you get a community full of antisocial people, and they tend to drive
away the team players. So the team players go off and use
C/Perl/Ruby/Python/whatever because those communities are full of other team
players. As a result, the whole becomes greater than the sum of the parts, and
the team players win, even though as individuals they may be generally less
productive/smart/whatever.

On those rare occasions when Lisp programmers manage to all row together in
the same direction they can produce some truly spectacular results (Viaweb,
ITA, RAX). But those seem to be the exceptions.

~~~
6ren
Have you ever found it difficult to understand someone else's lisp project,
because they have customized the language so much? (or vice versa, has a
fellow lisper found your code hard to understand)

I wonder if the flexibility and power of lisp might work against co-operation
in this way too.

I've witnessed confusion caused by operator-overloading in C++ (I heard that
that's common); lisp is more customizable.

~~~
lisper
> Have you ever found it difficult to understand someone else's lisp project,
> because they have customized the language so much?

Yes. But that is not a problem unique to Lisp. It's possible to write
unreadable code in any language. And in general Lisp's introspection
capabilities and macroexpand make it easier to reverse-engineer things that in
other languages.

~~~
6ren
opps, I what you mean; I actually meant well-written lisp.

Have you found that hard to understand, when it was heavily customized? I
agree that tracing through complex code is taxing in any language; and it
probably becomes much more important what concepts the author has chosen (and
things like coupling/cohesion), than the language.

i.e. That the problem wasn't that the code was badly written, but it was
because they had "customized the language so much". Extensive customization i
how you're supposed to use lisp; it's an important source of its power. (The
C++ example I mentioned was well-written.)

I can imagine it going either way (e.g. that lisp's customizations often aid
clarity, by reducing code size); so I'm interested to hear someone's
experience of how it actually goes in practice.

~~~
gchpaco
I have seen that happen before, but only when the domain was inherently
complex. An example I actually committed; for a variety of reasons I needed a
continuation driven LL(1) parser for my PhD thesis, and I needed it to be in
Java. I wrote this as a Scheme program that output Java code. I tried hard to
make things understandable (since I had to debug all of it!) but the Java code
was basically incomprehensible and the Scheme program that generated it
required some relatively sophisticated understandings of parser theory to
understand the notation I was using.

A good theoretical example is: imagine trying to understand what a CPS driven
compiler is doing with no understanding of CPS. That would be pretty hard in
any language, and it's actually better in Lisp because you can express things
closer to the theory.

------
baudehlo
It's worth noting that he says (in the other article he links to): "In fact,
in a number of cases I saw people whip things up in Perl in a couple of hours
that would have taken me days or weeks to do in Lisp.".

So therefore Perl > Lisp > everything? (I'm kidding for the humour impaired)

What he gained from using Lisp was not worrying about memory management, and
built-in data structures that made life easy. These days you can get that with
a lot of different languages (and I would argue that Java is not one of those
languages), languages that also perform as well as Lisp.

So what's my conclusion? That I think there are both - genius programmers who
can code well and quickly in just about any language, and also languages that
let you build things a lot faster than traditional languages.

~~~
ora600
My guess is that you didn't seriously learn functional programming in any
language.

It is not just about memory management and data structures. It is about
functions as first class objects, no side effects, lazy evaluation, closure,
monads. The fact that you can basically write a compiler in an hour as a first
year student (that was exercise 3 in my course).

I'm not a programmer, I'm a DBA. The code I write is mostly short and ugly
scripts in Perl and Bash. I can do very little Java and almost no other
language. The one and only time I used Lisp was in my first programming course
in the university. Incidentally, it was also the one and only time I enjoyed
programming.

~~~
baudehlo
That would be a bad guess. For a start, Lisp is not a functional language. It
just has some functional features. It has side effects.

I learned FP using Haskell, which is a pure functional language.

But I still stand by what I said. I code faster in Perl than I do in Haskell
due to the availability of libraries. The "pure FP" features may make some
things theoretically cleaner, but they don't honestly make things that much
easier. Having _access_ to FP features (map, grep, reduce, closures in
particular) is significant, but access to built in data structures (hashes in
particular) make life so much easier than C or C++ or Java.

~~~
colomon
I'm sure baudehlo knows, but some other readers may not: map, grep, and
closures are all native in Perl 5, and reduce is easily available. (All are
native in Perl 6.)

~~~
baudehlo
reduce is "included" - it's just in a loadable module in the core library.

------
numeromancer
This response was much more substantial than the original article.

To say that the original article was "about" Lisp, or the Lisp Genius, would
be akin to my saying that there are fleas "about" my dog.

BTW: I wonder if Rondam(?) knows this guy: <http://www.flownet.com/gat/jpl-
lisp.html>

~~~
cpr
Same person. He changed his name a while back.

------
Tiomaidh
I like and agree with the article, but:

    
    
        an attempt was made to port part of that code (the
        planner) from Lisp to C++. After a year that effort
        had to be abandoned because the planner team just
        couldn't make it work. 
    

I'm sure they'd struggle just as much if the planner was written in assembly,
and not because assembly is a far more elegant language...

~~~
gloob
Given that assembly is simpler than C++ both syntactically and semantically, a
reasonable argument could be made that it is a more elegant language.

------
alexk7
"A team of competent programmers willing to put up bullshit will out-compete a
lone wolf striving for elegance no matter how brilliant he is."

I'm doomed.

------
ShardPhoenix
It seems that the main thing this guy is really saying is that Lisp is easier
to program in than C++. I don't think that that's controversial around here.
What is controversial is whether Lisp has a significant advantage over Python,
Ruby, etc. Heck, he didn't even actually point out any advantage of Lisp over
_Java_.

------
jacques_chester
A better response:

stop linking to John Cook.

Every John Cook blog entry I have ever read turns out, upon inspection, to be
an almost-content free restatement of an accepted consensus -- motherhood
statements at best.

Whereas Jeff Atwood at least gives credit to the books he reads and
summarises, Cook merely regurgitates unsourced factoids and leavens with a few
unimpressive anecdotes.

~~~
j_baker
And yet, I never cease to be amazed at how many people need to be reminded of
many of these accepted truisms.

~~~
jacques_chester
Which can be more effectively done by referring people to the original sources
rather than rehashing some folk lore.

