> 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))
> 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.
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.
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.
I do know C++. I've used it do OpenGL and basic augmented reality stuff, I've used it in conjunction with Objective-C. And it was one of my first languages.
I haven't worked with it in a very long time (4+ years) and I never did very large projects (more than 10,000 LOC) with it. For that I am glad.
"It's intended to improve readability when used properly."
Which was the point of my poorly worded comment on the post. I presented a survey of Clojure's "mini-languages" features without usage context. I wasn't trying to give a run-down of best-practices, so if the post came off as my trying to do so then I failed.
Most of those things listed are neither, rather they are pragmatic and intended to improve readability.
Stuff you might not use: 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:
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.
Again a readability win, not loss.