

Lisp Quotes - alrex021
http://www.paulgraham.com/quotes.html

======
shaunxcode
My favorite quotes right now are both actually from the arc tutorial:

"Macros live in the land of the names, not the land of the things they refer
to."

"One of the things you'll discover as you learn more about macros is how much
day-to-day coding in other languages consists of manually generating
macroexpansions. Conversely, one of the most important elements of learning to
think like a Lisp programmer is to cultivate a dissatisfaction with repetitive
code. When there are patterns in source code, the response should not be to
enshrine them in a list of "best practices," or to find an IDE that can
generate them. Patterns in your code mean you're doing something wrong. You
should write the macro that will generate them and call that instead."

~~~
eru
I like macros, too. In a similar vein: Since I got accustomed to folds, arrows
and monads I also see them in a lot of places.

------
draegtun
Nice quotes.

While its "negative/funny" I'm surprised Larry Wall's famous quote about Lisp
didn't make it on this list:

    
    
        Lisp has all the visual appeal of oatmeal with fingernail clippings mixed in.
    

Here's the ref:
[http://groups.google.com/group/comp.lang.lisp/msg/7700fb02a2...](http://groups.google.com/group/comp.lang.lisp/msg/7700fb02a2750032)
(the whole thread is a good read).

~~~
lispm
given that this comes from the designer of PERL, the quote is a bit tragic

~~~
Dav3xor
Hehe, Lisp is oatmeal, Perl is Lucky Charms...

~~~
nfnaaron
... and all that Lucky Charm sugar gives you cancer of the semicolon.

~~~
Jach
Not to mention the negative effects on health caused by sigils. (Disclaimer: I
like Perl/Lisp/Python.)

------
alrex021
My favorite quote that's actually not in the list:

 _"Syntactic sugar causes cancer of the semicolon."

—Alan Perlis_

~~~
hassy
_“Syntactic sugar found to be leading cause of semantic diabetes.”_

Steve Dekorte on Twitter recently

<http://twitter.com/stevedekorte/status/7926192582>

~~~
eru
Is it just witty? or is syntactic sugar bad?

~~~
aerique
It is probably more of a preference. Since not everyone is using Lisp as their
main programming language (don't ask me why) it seems that some people prefer
more syntactic sugar sprinkled through their language.

Personally I stopped preferring sugar in both my tea and programming languages
a long time ago.

~~~
eru
I don't sugar my tea, either.

In a sense Lisp is the ultimate in syntactic sugar. I'd like to use Scheme
more, but I am currently in love with Haskell too much and use Ocaml at work.
Matthias Felleisen does very interesting work with Scheme.

------
Sukotto
It seems like Lisp is great the way Shakespeare or Hemingway are great. People
go on and on about how great they are... but if you look at their bookshelves
"The Compleat Shakespeare" tome is gathering dust on the bottom shelf and
right at eye level are the harry potter and starwars books... the stuff people
actually read.

~~~
pg
You used Lisp to make that comment.

------
felideon
"Those who do not know Lisp are doomed to reinvent it." - Erik Naggum

(Not on the list.)

~~~
sparky
That's a much less long-winded version of Greenspun's Tenth Rule. Brevity is
the soul of wit :)

------
mahmud
Lofty.

Here are quotes by working-class Lispers:

<http://www.cliki.net/IRC%20Quotes>

------
dschobel
It surprised me that a few were (jokingly?) anti-Common Lisp. Any lispers care
to explain?

examples:

 _"Greenspun's Tenth Rule of Programming: any sufficiently complicated C or
Fortran program contains an ad hoc informally-specified bug-ridden slow
implementation of half of Common Lisp." - Philip Greenspun

"Including Common Lisp." - Robert Morris_

"Common Lisp is politics, not art." - Scott Fahlman _

~~~
lmkg
For the last one: Lisps (in general) have a history/tradition/perception of
being innovative and pushing the boundaries of language, for better or for
worse. For modern examples, Scheme was arguably more guided by aesthetic
principles than pragmatic ones, and Clojure is an exploration of immutable
structures and concurrency. Many lisps were highly experimental pet projects,
and associated with academic research rather than industrial applications.
They were also commonly descibed as "elegant," where the "art" part of the
quote comes from.

Common Lisp is notable among lisps for breaking this tradition. It was meant
to be industrial-strength, which goes for robustness and completeness at the
expense of elegance, and rather than innovation merely contains a lowest-
common-denominator mix of (then-)standard lisp capabilities. In short, Common
Lisp is the most Worse-Is-Better of any lisp dialect, putting practicality
ahead of being really slick.

The quote ascribes this to CL being designed by committee, rather than being
designed by eccentric (or straight-up batshit crazy) enthusiasts the way that
lisps have been historically. While this certainly relates to its lowest-
common-denominator look & feel, I would argue the language's design goals
already set it down that path when it was the pet project of Steele & friends,
even before it became a literal committee product. One could quip that Steele
dragged C half-way to lisp and got Java, and then dragged lisp half-way to
Java and got Common Lisp.

~~~
jimbokun
I guess, then, Rich Hickey is dragging Java the rest of the way to Lisp.

------
RyanMcGreal
> That language is an instrument of human reason, and not merely a medium for
> the expression of thought, is a truth generally admitted.

And Sapir-Whorf rears its ugly head again.

~~~
btilly
But it actually has some truth in programming.

There is little possibility of thinking with programming techniques that
require closures until you are thinking _in_ a programming language that _has_
closures. Learning the language does not cause the thoughts, but you cannot
think through the thoughts effectively until you've developed a language that
can express them.

Of course once you have learned to think those thoughts then you can figure
out how to do those things in languages that don't have closures.

This raises, obviously, the question of how the idea of closures was ever
first established. And the answer to that is kind of interesting. The history
as I understand it is that they were invented by accident as a side effect of
other decisions in ALGOL and Pascal. But weren't extensively used there. Then
Sussman noticed that they worked extremely well when combined with the idea of
functions as data that was already popular in Lisp, and co-wrote Scheme, the
first Lisp with closures. The adoption of closures in other variants of Lisp
was usually quick (eLisp stands out as a glaring exception). From there they
got carried to other languages. The adoption of closures in scripting
languages, particularly JavaScript, brought them to a much wider audience, and
now they are becoming pretty mainstream.

So nobody really thought up the first programming techniques involving
closures from scratch. Instead those techniques were invented in a bad form
using other forms of scope, then closures were noticed as a solution for the
shortcomings of those scoping problems and things cascaded from there.

~~~
RyanMcGreal
> But it actually has some truth in programming.

I've learned a few programming languages over the years and I generally accept
the Blub Paradox (right now I'm contemplating the prospect that Python is
Blub), but I still think this line of reasoning gets it backwards -
particularly given that programming languages are _invented_.

Of course serendipity comes into play, but to suggest that it might have been
impossible to imagine effective closures until a programming language
accidentally supported them (poorly) just seems absurd.

~~~
btilly
I will never forget the brain lock I encountered the first time I had to deal
with a relatively small program that made extensive use of closures. In
hindsight the program was well-designed and clearly written. Yet I simply
could not understand it for over at least half an hour. And even once I did
figure it out, it took days before I could truly digest what made that design
work.

A couple of years later on the Perl 5 core mailing list I responded to a claim
that a good Perl programmer could support any well-written Perl program with a
key line from that program. From the volume of the squawks I got, a collection
of good Perl programmers generally were not prepared to understand that code,
despite years of experience in a language that fully supported closures.

I will not claim that it is impossible to imagine effective closures. I know
there are people who are far more intelligent than me, who think very
differently than I do. If history played out again a few times, perhaps it
would play out differently.

But I say without false modesty that I'm a significantly above average
programmer, and I am convinced that I personally could not have come up with
effective closures on my own. And I've known quite a few good programmers who
I am sure could not have done it. And I've never personally known anyone who
has left me convinced that they _could_ have done it. And finally the history
of how closures were invented does not support the idea that someone imagined
what could be done with them and then invented them for that reason.

~~~
eru
Thanks. An interesting story.

About your last paragraph: What's so special about closures? They have been in
lambda-calculus for ages. And lambda-calculus just formalizes mathematicial
function application and abstraction. (OK, I guess most mathematicians are not
aware of lexical scoping. But it springs naturally from alpha equivalence, a
notion that every mathematician agrees with intuitively.)

Of course coming up with the mathematical ideas and notations in the first
place wasn't easy. But closures pre-date computers. The computer scientists
`just' had to find ways to implement them effectively.

~~~
btilly
My answer is that what's special about closures is that if you actually
structure your program around using them, then you reorganize how you design
things in a somewhat surprising way.

~~~
eru
I agree. It's similar with Monads, Arrows, Functors. They have been around far
ages in category theory, but only recently have some of us begun to structure
our programs around them.

