Where I work there are always projects that are a little bit under management radar - things that need to be done but don't need to be done in a big hurry. That's the right kind of project to scratch your chin and say "You know, I've never written anything in whitespace."
I've been learning & trying to use clojure(script) for ~2 years now. A few things I miss in every other languages:
- The REPL: I usually don't need a debugger,
- Figwheel: that makes frontend dev a pleasure,
- reagent/reframe: are incredibly straightforward, there's no special syntax, no special constructs, just a few functions, a few concepts (dispatch / subscribed) and you're done,
- core.async: based on a simple channels / pipeline paradigm
But then you get into the practicalities of testing & writing code. Shady special cases[1][2], annoying testing tools[3], useless stack traces. And other issues everybody knows. Simple things that become a 30 min discussion with 3 different libraries and 2 blog articles to go through[4].
To me, there's this hardcore group of clojur'ist that seems to be hyper productive and keep introducing new concepts. And the "rest" (me at least), that are floundering. You fight with useless stacktraces? Boom, transducers. You deal with buggy test runners? Bam, a new specification library with test generations.
I've started moving my code to ES6 and Go. The community is filled with helpful people, but it seems to me that if you're not writing Clojure professionally already, the language is becoming less and less relevant.
[1] https://github.com/replikativ/superv.async/issues/2#issuecom...
[2] https://clojurians-log.clojureverse.org/clojurescript/2017-0...
[3] https://github.com/bensu/doo/issues/134
[4] https://clojurians-log.clojureverse.org/clojurescript/2017-0...
clojure.spec (launching on 1.9) will allow better error reporting on some cases, but the philosophy of the language has always being about giving you a lot of power vs. shielding you from complexity.
Also, a lot of people being introduced to Clojure from a Ruby background (and others, ofc) are having to learn simultaneously about: functional programming, Lisp, immutable data structures, the internals of JS/JVM, advanced concepts like STM, CSP, and a whole host of new libraries. That is a steep learning hill, specially if one bought the argument that programmers are snowflakes who can't take frustration. Once you're on the other side though, the complex, messy real-world projects become more amenable, because Clojure was created thinking about those. That's what Rich meant by "Simple ain't easy".
IMHO, working at a company w/ a codebase of ~150 projects written in Clojure, the productivity has paid off w/ interest though.
I think that characterising a (clearly knowledgeable, well-referenced) account of frustrations - especially ones that do not occur in other languages - with the dismissive term "snowflake" is exactly where the stereotype of the "smug Lisp weenie" comes from.
I have used and loved Clojure for years now (I wrote the patch that made Clojure vectors implement java.util.List, back in the pre-1.0 days). The fact that these problems exist doesn't itself give me existential worries about the future of the language. The fact that almost every Twitter thread in the OP, and the parent comment, contained this sort of dismissive reaction makes me very worried indeed.
If we replicate the community of Common Lisp, we will end up replicating its level of industry adoption.
You're just confirming my last point, professional Clojurist? Enjoy it. Others, be warned.
And if you end up concluding some other front-end language is better, Clojure is still a really good choice for the back end.
Fun > easy > simple?
1. Projects like Onyx and Jepsen where a small team was able to accomplish something beautiful. 2. Property based testing and the awesomeness of ReFrame state charts?
What @phillmv tried todo was very ambitious, and its awesome that he gave it a shot, but his overarching conclusion seems to put the blame on Clojure and that seems both unfair and unproductive.
Here are his specific clojure concerns and how i feel the community is addressing them in a way that makes me feel very happy:
1. StackTraces are hard to understand: Clojure Spec has been written about a ton in this regard 2. Debugger: Sayid Pro looks really promising, maybe a big company could pick it up and support it? But from my limited perspective things could be better for this story. 3. Startup Time: I don't know if anything is being done to address this, the current wisdom is that you work within the repl and structure your projects so they can be "reloaded" which has lot of nice properties.
Here are His Concerns i think are language agnostic:
1. It hard to Structure large apps : While Clojure applied has some suggestions i think every project is context specific. 2. New learning curve (lots of new ideas like reducers, map, transdecures, macros) : Their are a wealth of resources on all these topics, what in particular was he not getting answers about? 3. JVM requires deep editor integration: I feel this is true of every JVM language. 4. Dependency hell: True in every language? Clojure spec is actual designed to help with this eventually!
So his pain points are real, but thats not where he puts the emphasis. Rather he puts that on his feelings. And as John Oliver has warned us, that makes it easy to trivialize real problems, which i feel is what has been done here.
developers cannot be expected to spec out every function prototype. that's just not a good use of time.
However, aren't most languages with the best errors messages Static and Strongly Typed?
My point was more that I think Spec was created to help address the issue. Not necessarily that it was even a good solution.