5 ms·

Because, in my opinion, Clojure isn't a Lisp. It is Lisp-like language, or Java with parenthesis and immutable collections, if you wish. It violates few basic p

Because, in my opinion, Clojure isn't a Lisp. It is Lisp-like language, or Java with parenthesis and immutable collections, if you wish. It violates few basic principles of Lisp - one common underlying list-structure for code and data (Clojure's code is a mix of different containers) It violates a general evaluation rule - one for every expression with a very few special forms, etc. I cannot explain it in a few sentences, I have tried few times, but I'm sure that it is better to learn the classic Lisps first, so you could be able to appreciate their elegance and simplicity (a few selected ideas put together) and then you could compare it with what you have in Clojure. It is also important to learn how Lisp programmers used to build almost everything they wish out of conses (except arrays and hash-tables, of course) how they reason about access patterns for list structures, learn simple and elegant classic functions, such as map, filter, reduce, etc in their natural environment.) It short, compared with even CL Clojure is a mess.

pnathan 14y ago
I upvoted this because I agree. I just spent about a week writing an app in Clojure, and it doesn't feel entirely like something in the Lisp Way[1]. That doesn't make it wrong, bad, immoral, etc; it is different. It has some interesting ideas which I think should be fed back into other Lispy languages via libraries (easy parallelism, immutability). [1] This is the hard to explain part.
- chc 14y ago
  The idea that Lisp 1, Typed Racket, Dylan and Common Lisp are all Lisp but Clojure is not seems really weird to me. It feels like up till the '80s, Lisp was free to make progress and differences were embraced (even if that embracing was of the form "My Lisp is superior because of its differences from yours!"), but now any progress makes you "not Lisp." From people's consistent inability to articulate a meaningful distinction, I'm almost convinced that the idea of Clojure as "not really Lisp" is mostly a distaste for having reader support for vectors instead of requiring you to write (vector thing1 thing2) like most Lisps would. Yes, Clojure isn't exactly like older Lisps. Why should it be? Those Lisps are all different from each other as well. If new Lisps can't introduce new ideas, what is the point?
  - pnathan 14y ago
    Personally, I don't think Clojure should exist as a production language, bluntly. I think it should have been a skin on ABCL. But that is water long under the bridge. But I would describe Clojure as "not Lispy" because its behavior seem to fall into the compilation idea more than the interpretive idea. I would execute `lein run` and a failure would drop me out into the Linux shell. An equivalent command in CL would throw a condition and drop me into an interactive mode to patch it up. I fully acknowledge that my tool use may not have been ideal, of course. But my Clojure was giving me a compile-run-test cycle as opposed to the the interactive editor/repl cycle of CL. Errors in the source would cause exceptions and crashing in the compile phase; errors in the runtime would cause a crash. I want to hone in on the second point you made, in terms of new ideas. New ideas are good (c.f., Kernel). New ideas should be aggressively pursued. I draw the line when someone has a slightly varied idea and wants to fork out something & get a community going just for that slight variance. That's just annoying and forks effort. If the new idea is really radical and can't be reconciled with extant tools, of course it deserves to be a new thing. Lisps are an insanely awesome tool for exploring semantics and I hope they keep getting created and churned on for decades to come. I just hope that the ideas which are reconcilable to production systems are reconciled so that we don't fragment further.
    - carry_bit 14y ago
      You can fire up Emacs and go to town with Clojure using SLIME, Clojure isn't really any different in that respect.
      - pnathan 14y ago
        Oh, that's good to know. I had tried to get SLIME playing well with Clojure but there was some issue where it didn't play nice with Common Lisp-configured SLIME and I bailed out.
  - lispm 14y ago
    The idea is that the core Lisp languages are Lisp 1, Lisp 1.5, Maclisp and Common Lisp. Then we can add to this: Franz Lisp, Standard Lisp, ISLisp and Emacs Lisp. Porting code between these is relatively easy or even trivial when only the core is used.
- ScottBurson 14y ago
  If you want immutable collections in Common Lisp, try FSet: http://www.cliki.net/FSet http://www.cliki.net/FSet
  - pnathan 14y ago
    Yeah, there are a couple immutable collections out there! I hope to get using them soonish.
chc 14y ago
> It violates few basic principles of Lisp - one common underlying list-structure for code and data (Clojure's code is a mix of different containers) I can't see how this is true. IIRC Common Lisp has more standard data types than core Clojure does — it's just that Clojure has reader support for more of them and uses them a bit more freely. It is still homoiconic. > It violates a general evaluation rule - one for every expression with a very few special forms, etc. I assume you meant to write something like "one list for every expression". Clojure has essentially the same rule. In general, the things you are probably thinking of that omit lists where most Lisps use them (like Clojure's let and cond using juxtaposition rather than lists to group things) are macros, which could be written in any other Lisp just as well. These are done for convenience, much like Common Lisp's loop.

pnathan 14y ago

I upvoted this because I agree. I just spent about a week writing an app in Clojure, and it doesn't feel entirely like something in the Lisp Way[1]. That doesn't make it wrong, bad, immoral, etc; it is different. It has some interesting ideas which I think should be fed back into other Lispy languages via libraries (easy parallelism, immutability). [1] This is the hard to explain part.

chc 14y ago
The idea that Lisp 1, Typed Racket, Dylan and Common Lisp are all Lisp but Clojure is not seems really weird to me. It feels like up till the '80s, Lisp was free to make progress and differences were embraced (even if that embracing was of the form "My Lisp is superior because of its differences from yours!"), but now any progress makes you "not Lisp." From people's consistent inability to articulate a meaningful distinction, I'm almost convinced that the idea of Clojure as "not really Lisp" is mostly a distaste for having reader support for vectors instead of requiring you to write (vector thing1 thing2) like most Lisps would. Yes, Clojure isn't exactly like older Lisps. Why should it be? Those Lisps are all different from each other as well. If new Lisps can't introduce new ideas, what is the point?
- pnathan 14y ago
  Personally, I don't think Clojure should exist as a production language, bluntly. I think it should have been a skin on ABCL. But that is water long under the bridge. But I would describe Clojure as "not Lispy" because its behavior seem to fall into the compilation idea more than the interpretive idea. I would execute `lein run` and a failure would drop me out into the Linux shell. An equivalent command in CL would throw a condition and drop me into an interactive mode to patch it up. I fully acknowledge that my tool use may not have been ideal, of course. But my Clojure was giving me a compile-run-test cycle as opposed to the the interactive editor/repl cycle of CL. Errors in the source would cause exceptions and crashing in the compile phase; errors in the runtime would cause a crash. I want to hone in on the second point you made, in terms of new ideas. New ideas are good (c.f., Kernel). New ideas should be aggressively pursued. I draw the line when someone has a slightly varied idea and wants to fork out something & get a community going just for that slight variance. That's just annoying and forks effort. If the new idea is really radical and can't be reconciled with extant tools, of course it deserves to be a new thing. Lisps are an insanely awesome tool for exploring semantics and I hope they keep getting created and churned on for decades to come. I just hope that the ideas which are reconcilable to production systems are reconciled so that we don't fragment further.
  - carry_bit 14y ago
    You can fire up Emacs and go to town with Clojure using SLIME, Clojure isn't really any different in that respect.
    - pnathan 14y ago
      Oh, that's good to know. I had tried to get SLIME playing well with Clojure but there was some issue where it didn't play nice with Common Lisp-configured SLIME and I bailed out.
- lispm 14y ago
  The idea is that the core Lisp languages are Lisp 1, Lisp 1.5, Maclisp and Common Lisp. Then we can add to this: Franz Lisp, Standard Lisp, ISLisp and Emacs Lisp. Porting code between these is relatively easy or even trivial when only the core is used.
ScottBurson 14y ago
If you want immutable collections in Common Lisp, try FSet: http://www.cliki.net/FSet http://www.cliki.net/FSet
- pnathan 14y ago
  Yeah, there are a couple immutable collections out there! I hope to get using them soonish.

chc 14y ago

> It violates few basic principles of Lisp - one common underlying list-structure for code and data (Clojure's code is a mix of different containers) I can't see how this is true. IIRC Common Lisp has more standard data types than core Clojure does — it's just that Clojure has reader support for more of them and uses them a bit more freely. It is still homoiconic. > It violates a general evaluation rule - one for every expression with a very few special forms, etc. I assume you meant to write something like "one list for every expression". Clojure has essentially the same rule. In general, the things you are probably thinking of that omit lists where most Lisps use them (like Clojure's let and cond using juxtaposition rather than lists to group things) are macros, which could be written in any other Lisp just as well. These are done for convenience, much like Common Lisp's loop.