4 ms·

It starts with > one of the strengths of Clojure is that it is comprised of many little mini-languages and ends with (in the comments) > I hope you do not ju

It starts with > one of the strengths of Clojure is that it is comprised of many little mini-languages and ends with (in the comments) > I hope you do not judge the whole of Clojure by this blog post So which is it? Is this syntactic soup an achievement to be proud of or a misfeature to ignore and avoid?

jdp 17y ago
I don't see how those two statements are conflicting. He begins by saying that it is one of the (implied) multiple strengths of Clojure. He then admits that perhaps it is not for everyone, that Clojure has other features that may be more appealing to others.
gruseom 17y ago
The language has many strengths. This is one; it is not the whole.
- nearestneighbor 17y ago
  "I hope you don't judge me by this strength of mine, I'm actually an OK guy" - how does that parse :-P
swannodette 17y ago
> So which is it? Is this syntactic soup an achievement to be proud of or a misfeature to ignore and avoid? Most of those things listed are neither, rather they are pragmatic and intended to improve readability. * List comprehensions need no justification. * Literal regex support also needs no justification. * Syntax quote needs no justification. * Literal numerics need no justification. Stuff you might not use: * pre/post conditions * gen-class I hardly consider ns a mini-language any more than I consider any language's import syntax a mini-language but that's me. So we're left with #() and ->, ->>. #() is often abused. It's really meant for things like this: (map #(* % 3) (range 100)) ; vs. (map (fn [x] (* x 3)) (range 100)) It's intended to improve readability when used properly. This the purpose of -> and ->> as well. People often complain that Lisp code needs to be read inside out. (+ (* (/ x 2) 3) 5)) ; vs. (-> x (/ 2) (* 3) (+ 5)) Again a readability win, not loss.
- nearestneighbor 17y ago
  > Most of those things listed are neither, rather they are pragmatic and intended to improve readability. The road to damnation is paved with good intentions. In C++, (which I use a lot for many practical reasons), separately every single feature solves or improves something, but together the improvements could have been made more consistently at a lesser cost in language elegance.
  - swannodette 17y ago
    separately every single feature solves or improves something, but together the improvements could have been made more consistently at a lesser cost in language elegance. The problem with C++ is that those "improvements" are grafted onto the language. You can't do a damn thing about it. In Clojure half these "mini-languages" are just macros. You don't have to use any of it. If you see a better way to do things build your own macros from the primitive forms. Good luck fixing C++ :D
    - deleted 17y ago
      [deleted]
    - nearestneighbor 17y ago
      > The problem with C++ is that those "improvements" are grafted onto the language. You can't do a damn thing about it. You don't have to use the features you don't like. Its main design principle is "you don't pay for what you don't use". The problem with C++ is that too many people who don't know it, talk about it :-P
  - brehaut 17y ago
    Your point highlights what i think is one of the biggest features of clojure: it has been assembled according to a philosophy / design criteria such that each feature exists as part of the whole. The features that have been omitted from clojure are as important as the features that have made it in. It has been pointed out that much of what is in clojure is not new, its the careful and pragmatic orchestration of good ideas taken from across the field of computer science that makes it interesting. The major point of conflict is whether you agree with the philosophy.
fogus 17y ago
The terms syntactic-soup and misfeature are yours. I would not describe the features listed that way, nor did my original post. Likewise, with "achievement" -- I provided a survey of, in my view, useful features independent of context and best-practices. There is no particular reason for me to be proud, but I would think that Rich Hickey would deserve to be so since he's the one who has actually "achieved" something great by creating Clojure. You may not see it that way (clearly not), but it's probably best to keep the level of discussion on merits of this feature or that rather than false pretenses.

jdp 17y ago

I don't see how those two statements are conflicting. He begins by saying that it is one of the (implied) multiple strengths of Clojure. He then admits that perhaps it is not for everyone, that Clojure has other features that may be more appealing to others.

gruseom 17y ago

The language has many strengths. This is one; it is not the whole.

nearestneighbor 17y ago
"I hope you don't judge me by this strength of mine, I'm actually an OK guy" - how does that parse :-P

swannodette 17y ago

> So which is it? Is this syntactic soup an achievement to be proud of or a misfeature to ignore and avoid? Most of those things listed are neither, rather they are pragmatic and intended to improve readability. * List comprehensions need no justification. * Literal regex support also needs no justification. * Syntax quote needs no justification. * Literal numerics need no justification. Stuff you might not use: * pre/post conditions * gen-class I hardly consider ns a mini-language any more than I consider any language's import syntax a mini-language but that's me. So we're left with #() and ->, ->>. #() is often abused. It's really meant for things like this: (map #(* % 3) (range 100)) ; vs. (map (fn [x] (* x 3)) (range 100)) It's intended to improve readability when used properly. This the purpose of -> and ->> as well. People often complain that Lisp code needs to be read inside out. (+ (* (/ x 2) 3) 5)) ; vs. (-> x (/ 2) (* 3) (+ 5)) Again a readability win, not loss.

nearestneighbor 17y ago
> Most of those things listed are neither, rather they are pragmatic and intended to improve readability. The road to damnation is paved with good intentions. In C++, (which I use a lot for many practical reasons), separately every single feature solves or improves something, but together the improvements could have been made more consistently at a lesser cost in language elegance.
- swannodette 17y ago
  separately every single feature solves or improves something, but together the improvements could have been made more consistently at a lesser cost in language elegance. The problem with C++ is that those "improvements" are grafted onto the language. You can't do a damn thing about it. In Clojure half these "mini-languages" are just macros. You don't have to use any of it. If you see a better way to do things build your own macros from the primitive forms. Good luck fixing C++ :D
  - deleted 17y ago
    [deleted]
  - nearestneighbor 17y ago
    > The problem with C++ is that those "improvements" are grafted onto the language. You can't do a damn thing about it. You don't have to use the features you don't like. Its main design principle is "you don't pay for what you don't use". The problem with C++ is that too many people who don't know it, talk about it :-P
- brehaut 17y ago
  Your point highlights what i think is one of the biggest features of clojure: it has been assembled according to a philosophy / design criteria such that each feature exists as part of the whole. The features that have been omitted from clojure are as important as the features that have made it in. It has been pointed out that much of what is in clojure is not new, its the careful and pragmatic orchestration of good ideas taken from across the field of computer science that makes it interesting. The major point of conflict is whether you agree with the philosophy.

fogus 17y ago

The terms syntactic-soup and misfeature are yours. I would not describe the features listed that way, nor did my original post. Likewise, with "achievement" -- I provided a survey of, in my view, useful features independent of context and best-practices. There is no particular reason for me to be proud, but I would think that Rich Hickey would deserve to be so since he's the one who has actually "achieved" something great by creating Clojure. You may not see it that way (clearly not), but it's probably best to keep the level of discussion on merits of this feature or that rather than false pretenses.