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."
I just read Coders at Work and here's an excerpt from the interview of L. Peter Deutsch about this quote:
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. (...)
my favorite Perl quote is from Stevey (of google fame):
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.
Another gem by Larry Wall (and I mean that sincerely)
"...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."
This quote seems particularly dated to me. Thanks to SBCL, PLT Scheme, Arc, and Clojure- Lisp these days is very much catering to "mere mortals". It's lovely to follow a news link from HN and see all those wonderful s-expressions :)
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
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.
Is intended to be an endorsement of Lisp, or are you saying something along the lines of 'The Jonas Brothers are better than Mozart because so many more people listen to them these days'?
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.
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.
It seems to me that syntactic sugar is the crutch that language designers throw to their users when they won't/can't give them macros. I think the idea behind the quote is not that it's bad in an absolute sense, just that it's a second best solution.
Understandable. I like Lisp [1], but I am also quite content with the way Haskell looks like. And Haskell has a lot of syntactic sugar. Lisp just enables you to grow your own sugar beets.
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
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.
The first one is meant to be pro-CL. It says that there are problems that are so difficult or large that they can only be solved with some of the unique features Lisp, such as macros. Of course, all programming languages in use are Turing-complete, so technically you could use any language. In practice, however, the mental capacities of the programmers form a barrier: imagine writing an OS in Brainfuck. So when people are working on such problems in C or Fortran, sooner or later they will - unknowingly - come up with the ad hoc implementation of CL in their program, to get some of that additional abstraction Lisp provides.
"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."
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.
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.
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.
> 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.
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.
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.
I would be interested if you can present a specific piece of code that would be really confusing to a programmer who does not have experience using languages with lexical closures. I didn't follow the same order of education, so I never really experienced an a-ha moment like that; they seem like a simple language construct to me (although I can definitely understand how it would be hard to recognize their utility without having experience using them.)
(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.)
Not impossible, but it would have been harder. If you did succeed in thinking about them, it seems likely that along the way you would invent a language that supported them. By that I mean you would have developed notation to write your thoughts down compactly. You wouldn't need to implement the language.
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.)
Historical note. Newton invented Calculus then carefully found other ways to regenerate the results he got that way. The language of Calculus that we have was separately invented by Leibniz. The subject of the first big priority dispute was whether Leibniz' invention of Calculus was independent, or was obtained from the traces of it left in the Principia.
That fits my experience. In the 1980s as a teenager I programmed in BASIC. I read a magazine article about generating mazes. I couldn't wrap my head around the algorithm. Later I learned Forth. After that, the algorithm made sense, because I finally had a language in my head suitable for recursion.
"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."