Lisp Quotes
paulgraham.com
paulgraham.com
"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."
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.
Seibel: I think Larry Wall described it as bowl of oatmeal with fingernail clippings in it.
Deutsch: Well, my description of Perl is something that looks like it came out of the wrong end of a dog. I think Larry Wall has a lot of nerve talking about language design -- Perl is an abomination as a language. But let's not go there. (...)
Sometimes [Perl] fits just right, but when it misses, the best code a human could write looks like it was produced by an agitated baboon banging its feet on the keyboard for 20 minutes.
"...By policy, LISP has never really catered to mere
mortals... And, of course, mere mortals have never
really forgiven LISP for not catering to them."
Perl has many nice ideas, that were copied into other languages ... think regexp literals for example, and I know people got crazy about DSLs once Ruby got popular, but DSLs have been the norm in Perl since forever ... due to its flexible syntax and to its interpreter (see Devel::Declare ... which allows you to locally take over control from the Perl's parser ... such that you can add new syntax).
The only problem with Perl is that it wasn't supposed to be such high-level and general purpose. It was just supposed to be a replacement for grep / awk / sed. Then it got popular :)
Larry Wall is a really smart guy (I met him at the last YAPC::Europe) ... a little crazy though :) ... but he does have good ideas. See for instance this article on why Perl is the way it is ... http://www.wall.org/~larry/pm.html
I don't know why, but I like crazy people :)
"Syntactic sugar causes cancer of the semicolon."
—Alan Perlis
Steve Dekorte on Twitter recently
Personally I stopped preferring sugar in both my tea and programming languages a long time ago.
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.
[1] Actually I like Scheme. Common Lisp is ugly.
(Not on the list.)
Here are quotes by working-class Lispers:
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
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.
"Including Common Lisp."
Well, my understanding is that most Common Lisp implementations are actually mostly written in Common Lisp. For that to be possible, you first need to bootstrap the implementation, and to do that you first write an "informally-specified, bug-ridden, slow implementation of half of Common Lisp" in C or something, and when you've done that, you're self-hosting, meaning you can produce newer versions of your implementation that are more formally-specified, less bug-ridden and faster. Eventually you have an accurate and fast implementation of Common Lisp, which is a pretty well-specified language.
So there.
And Sapir-Whorf rears its ugly head again.
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.
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.
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.
Most really interesting and disruptive inventions are at least partially accidental. Ideas rarely spring fully formed; instead they appear through cross-fertilization, recombination and serendipity.
Once the idea is there, we invent whatever models and languages are necessary to describe and implement it. That process can be comprehensive and all-at-once but more often is iterative and progressive. Even radical innovations that seem to spring fully formed did so after long gestation outside public view.
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.
(I can understand how code passing around anonymous functions can be confusing to people who don't use a language with first-class functions, but I would figure they're confused by the logic, not by the closures.)
print join "\t", map {$format[$_]->($row[$_])} 0..$#format;
There was nothing to stop people from doing calculus pre-Newton. But doing calculus without the language (theorems and definitions) of calculus would be hard. Once Newton had provided the language, it became something high school students could learn.
(Historical accuracy not guaranteed, but I hope it illustrates my point.)