6 ms·
Lisp Quotes
- alrex021 17y agoMy favorite quote that's actually not in the list: "Syntactic sugar causes cancer of the semicolon." —Alan Perlis
- hassy 17y ago“Syntactic sugar found to be leading cause of semantic diabetes.” Steve Dekorte on Twitter recently http://twitter.com/stevedekorte/status/7926192582 http://twitter.com/stevedekorte/status/7926192582
- eru 17y agoIs it just witty? or is syntactic sugar bad?
- jwhitlark 17y agoIt 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.
- eru 17y agoUnderstandable. 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. [1] Actually I like Scheme. Common Lisp is ugly.
- aerique 17y agoIt 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 17y agoI 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.
- RyanMcGreal 17y ago> 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 17y agoBut 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 17y ago> 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.
- draegtun 17y agoNice 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/7700fb02a2750032 http://groups.google.com/group/comp.lang.lisp/msg/7700fb02a2... (the whole thread is a good read).
- lispm 17y agogiven that this comes from the designer of PERL, the quote is a bit tragic
- Dav3xor 17y agoHehe, Lisp is oatmeal, Perl is Lucky Charms...
- bad_user 17y agoI know you are joking, at least I hope so :) 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 http://www.wall.org/~larry/pm.html I don't know why, but I like crazy people :)
- felideon 17y ago"Those who do not know Lisp are doomed to reinvent it." - Erik Naggum (Not on the list.)
- sparky 17y agoThat's a much less long-winded version of Greenspun's Tenth Rule. Brevity is the soul of wit :)
- shaunxcode 17y agoMy 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 17y agoI 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.
- mahmud 17y agoLofty. Here are quotes by working-class Lispers: http://www.cliki.net/IRC%20Quotes http://www.cliki.net/IRC%20Quotes
- dschobel 17y agoIt 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
- thomas11 17y agoThe 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.
- lmkg 17y agoFor 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.
- Sukotto 17y agoIt 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.
- swannodette 17y agoI guess there's just no accounting for bad taste. But we knew that already ;)
- pg 17y agoYou used Lisp to make that comment.
- deleted 17y ago[deleted]
- julio_the_squid 17y agoIs 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'?