4 ms·

For my tastes, Clojure strays too far from proven ground. It's nice to experiment with stuff like persistent data structures and STM, but I don't think the nex

by pwpwp 17y ago

For my tastes, Clojure strays too far from proven ground. It's nice to experiment with stuff like persistent data structures and STM, but I don't think the next big Lisp, if there is one, will be based around that model. It's simply too far removed from the (object-oriented, semi-functional) Lisp programming model of the last decades.

J_McQuade 17y ago
"It's simply too far removed from the (object-oriented, semi-functional) Common Lisp programming model of the last decades" ~ahem~ Common Lisp and Lisp are not equal. Well, maybe in a sense, but they're definitely not eql. Anyway, I'm still unsure about Clojure myself (not really had the chance to dive in), but a lot of the 'unproven' ideas you mention (persistent data, STM, also lazy functions etc. etc.) have been doing the rounds in PL circles for quite a while now. It's interesting to see them taking root in lispsville, if nothing else. I like Lisp and I like Haskell - Clojure seems to take cues (very well proven ones, I might add) from both but, like I say, I've yet to really see how well they've been married.
- francoisdevlin 17y ago
  As an avid Clojurian, I can recommend taking the plunge. The seq abstraction goes a long way to reducing library sizes. This is going to be as big a deal as the STM. My $.02
gruseom 17y ago
the (object-oriented, semi-functional) Lisp programming model of the last decades. I disagree with your claim, both here and in the OP, that the Lisp programming model is object-oriented. CLOS is just a library, one can write arbitrarily complex Lisp programs without going near it, and many Lisp hackers don't. Thinking in Lisp is not at all the same thing as thinking in objects. (After building OO systems for years, one reason I like Common Lisp is that I want nothing more to do with OO.) The reason CL is semi-functional is not CLOS but the fact that it fully supports imperative programming, leaving it up to the programmer to decide what side effects to allow where.
radu_floricica 17y ago
It does have another big advantage: it's clean. Not having to be compatible with a prior lisp made it possible to have a lot of small things changed. Like the lambda function syntax, or the "def" special form, or the really nice reader syntax for vectors and maps. Both above the hood and below it's based on consistent abstractions. Other lisps would be too, no doubt, but they suffer from having evolved over a very long time. And it grows, including towards what you it's say it's lacking right now. Recently it got the capability to work with mutable data structures (transients), which makes it less functional, but still without giving up the advantages.

by pwpwp 17y ago

J_McQuade 17y ago

"It's simply too far removed from the (object-oriented, semi-functional) Common Lisp programming model of the last decades" ~ahem~ Common Lisp and Lisp are not equal. Well, maybe in a sense, but they're definitely not eql. Anyway, I'm still unsure about Clojure myself (not really had the chance to dive in), but a lot of the 'unproven' ideas you mention (persistent data, STM, also lazy functions etc. etc.) have been doing the rounds in PL circles for quite a while now. It's interesting to see them taking root in lispsville, if nothing else. I like Lisp and I like Haskell - Clojure seems to take cues (very well proven ones, I might add) from both but, like I say, I've yet to really see how well they've been married.

francoisdevlin 17y ago
As an avid Clojurian, I can recommend taking the plunge. The seq abstraction goes a long way to reducing library sizes. This is going to be as big a deal as the STM. My $.02

gruseom 17y ago

the (object-oriented, semi-functional) Lisp programming model of the last decades. I disagree with your claim, both here and in the OP, that the Lisp programming model is object-oriented. CLOS is just a library, one can write arbitrarily complex Lisp programs without going near it, and many Lisp hackers don't. Thinking in Lisp is not at all the same thing as thinking in objects. (After building OO systems for years, one reason I like Common Lisp is that I want nothing more to do with OO.) The reason CL is semi-functional is not CLOS but the fact that it fully supports imperative programming, leaving it up to the programmer to decide what side effects to allow where.

radu_floricica 17y ago

It does have another big advantage: it's clean. Not having to be compatible with a prior lisp made it possible to have a lot of small things changed. Like the lambda function syntax, or the "def" special form, or the really nice reader syntax for vectors and maps. Both above the hood and below it's based on consistent abstractions. Other lisps would be too, no doubt, but they suffer from having evolved over a very long time. And it grows, including towards what you it's say it's lacking right now. Recently it got the capability to work with mutable data structures (transients), which makes it less functional, but still without giving up the advantages.