4 ms·

Can not resist... This article is fairly misguided. I find it painful that everybody who writes about a Lisp offshoot (Scheme, Clojure, ...) ends up misreprese

Can not resist... This article is fairly misguided. I find it painful that everybody who writes about a Lisp offshoot (Scheme, Clojure, ...) ends up misrepresenting Common Lisp. To sum up "Why Lisp?" from a CL perspective: CL has pretty much every feature of every programming language around, only that its better designed, implemented and generally more powerful. It's just a poweruser language. Its not just macros, sexps and lambdas. Its also number types, arrays, OOP, symbols, strings, structs, dynamic/lexical variables, lambda lists, multiple return values, on-line disassemble, exceptions, restarts, MOP, metacircular definition, great implementations, great libraries...... the list goes on and on... I surely forgot a ton of great stuff. TL;DR: CL got everything. And this "everything" is designed so well that its extensible and no CL programmer ever needs to doubt that any new feature can be implemented easily in CL. To correct a few of the wrong statements of OP: > “Wait—I love state and data mutation. Why would you take them away?” Because they’re false friends. CL is NOT particularily functional. Just because we know how to write good side-effect free code, doesn't mean its a functional language. (We jave SETF after all, failed to mention that aove). > a syntax transformation in Racket can be far more sophisticated than the usual Common Lisp macro. Outright wrong. The only reason Scheme has weird macro systems is because its a Lisp 1. CL is designed well (thus being a Lisp 2), and thats why its simple but ultimately more powerful macro system can work. > A macro in Common Lisp is a function that runs at compile-time, accepting symbols as input and injecting them into a template to produce new code. This is so wrong I had to write this comment. A macro in Common Lisp is a COMPILER, it accepts arguments and returns an SEXP. It is infinitely powerful, it can do EVERYTHING.

deleted 12y ago
[deleted]
- pivo 12y ago
  > More generally Common Lisp lacks a coherent web based module repository infrastructure like those of other dynamic languages such as CPAN or RubyGem. What about ASDF and/or Quicklisp (http://www.quicklisp.org http://www.quicklisp.org). They work well for me.
  - deleted 12y ago
    [deleted]
    - eudox 12y ago
      ASDF is the build system, Quicklisp the package manager. QL depends on ASDF.
hvs 12y ago
I would take issue with the OOP in CL being better implemented than other languages. Don't get me wrong, the Metaobject Protocol is a feat of modern engineering, but the actual result is an OOP that feels tacked on after the fact. CLOS is very powerful, but when it comes to OOP, other languages are syntactically cleaner in their implementations. Also, it's a bigger debate, but the lack of hygenic macros in CL is often seen as a negative. Again, this is a larger debate, but certainly a case can be made that CL doesn't have everything designed so well. I love CL, but it's helpful to remember its limitations.
- mrottenkolber 12y ago
  > syntactically cleaner in their implementations. Listen to yourself please. > lack of hygenic macros in CL Which lack? CL macros are usually very hygienic, being a Lisp-2 and all, having GENSYM. > I love CL, but it's helpful to remember its limitations. What limitations? Not having syntactical things you seem to like and supporting non-hygienic macros are not limitations. Quite on the opposite, I believe these are features.
deleted 12y ago
[deleted]
deleted 12y ago
[deleted]
wtetzner 12y ago
> CL has pretty much every feature of every programming language around, only that its better designed, implemented and generally more powerful. The thing is, sometimes what makes a language powerful is the restrictions it imposes. For example, if you know a function is referentially transparent, then you know that calling it multiple times won't cause side effects to happen multiple times. Having restrictions means that you can rely on those restrictions applying to other code, which might allow you to do things that would otherwise be unsafe.
samth 12y ago
The number of bindings you can add to a symbol in CL is irrelevant to the macro system. In CL, you run into somewhat fewer instances of specific kinds of bugs that Racket's macro system prevents entirely. The Racket macro system is more powerful, having more information and more control over the system, than the CL system. This additional expressiveness is what enables systems as sophisticated as the Racket contract, class, unit, and type systems to be built entirely with macros.
pmelendez 12y ago
>> “Wait—I love state and data mutation. Why would you take >them away?” Because they’re false friends. >CL is NOT particularily functional. Just because we know how >to write good side-effect free code, doesn't mean its a >functional language. He didn't claim that CL or even Lips were pure functional though: "Yes, I know that other languages offer functional-programming features, and that Lisps aren’t considered pure functional languages."

deleted 12y ago

[deleted]

pivo 12y ago
> More generally Common Lisp lacks a coherent web based module repository infrastructure like those of other dynamic languages such as CPAN or RubyGem. What about ASDF and/or Quicklisp (http://www.quicklisp.org http://www.quicklisp.org). They work well for me.
- deleted 12y ago
  [deleted]
  - eudox 12y ago
    ASDF is the build system, Quicklisp the package manager. QL depends on ASDF.

hvs 12y ago

I would take issue with the OOP in CL being better implemented than other languages. Don't get me wrong, the Metaobject Protocol is a feat of modern engineering, but the actual result is an OOP that feels tacked on after the fact. CLOS is very powerful, but when it comes to OOP, other languages are syntactically cleaner in their implementations. Also, it's a bigger debate, but the lack of hygenic macros in CL is often seen as a negative. Again, this is a larger debate, but certainly a case can be made that CL doesn't have everything designed so well. I love CL, but it's helpful to remember its limitations.

mrottenkolber 12y ago
> syntactically cleaner in their implementations. Listen to yourself please. > lack of hygenic macros in CL Which lack? CL macros are usually very hygienic, being a Lisp-2 and all, having GENSYM. > I love CL, but it's helpful to remember its limitations. What limitations? Not having syntactical things you seem to like and supporting non-hygienic macros are not limitations. Quite on the opposite, I believe these are features.

deleted 12y ago

[deleted]

deleted 12y ago

[deleted]

wtetzner 12y ago

> CL has pretty much every feature of every programming language around, only that its better designed, implemented and generally more powerful. The thing is, sometimes what makes a language powerful is the restrictions it imposes. For example, if you know a function is referentially transparent, then you know that calling it multiple times won't cause side effects to happen multiple times. Having restrictions means that you can rely on those restrictions applying to other code, which might allow you to do things that would otherwise be unsafe.

samth 12y ago

The number of bindings you can add to a symbol in CL is irrelevant to the macro system. In CL, you run into somewhat fewer instances of specific kinds of bugs that Racket's macro system prevents entirely. The Racket macro system is more powerful, having more information and more control over the system, than the CL system. This additional expressiveness is what enables systems as sophisticated as the Racket contract, class, unit, and type systems to be built entirely with macros.

pmelendez 12y ago

>> “Wait—I love state and data mutation. Why would you take >them away?” Because they’re false friends. >CL is NOT particularily functional. Just because we know how >to write good side-effect free code, doesn't mean its a >functional language. He didn't claim that CL or even Lips were pure functional though: "Yes, I know that other languages offer functional-programming features, and that Lisps aren’t considered pure functional languages."