I write lots of Clojure and ClojureScript everyday, and the article really resonated with me. Especially the parts about not using anything too complex or fancy, and sticking to simple tools. My code also has very few macros, and relies on lots of (complex) maps, using clojure.spec to keep them in check.
I think you get even more benefits from Clojure if you write apps that run both server-side and client-side (in the browser, using ClojureScript).
Much thanks to the author for nicely showing a good use case for the Either monad. In general, I think there are lots of great concepts in category theory, but well hidden behind horrendous naming (bind/return, anyone?) and lack of good practical examples (well let's fmap inc over a vector here).
And since it seems everybody pitches in something about some language being inferior or superior to Clojure, I'll contribute something, too: I would not have been able to write PartsBox.io (https://partsbox.io/) without Clojure and especially ClojureScript. It boils down to practical reasons: code size, abstractions that I can build on, avoiding accidental complexity.
I don't like participating in discussions that compare programming languages these days. I feel these are often very shallow. As an example, I used to program a lot in Common Lisp, and I think it can't meaningfully be compared to Clojure/ClojureScript. You don't see that until you've written several large multithreaded applications with zero deadlocks (thanks to STM), after you've used core.async to simplify complex and bug-prone code, after you've used transducer pipelines to parallelize a large stream computation completely avoiding the horrors of Hadoop, or after you've sent your data structures over a websocket to code that is actually the same code that runs on the server (cljc, files that compile to both Clojure and ClojureScript). Seriously — how can I discuss the finer points of syntax (oh, the parentheses!) when I am able to ship React-based apps that do isomorphic rendering (the server pre-renders a page, and JavaScript plugs into it later), all in Clojure+ClojureScript, without even touching node.js? You start to appreciate those things only when you write large applications and your time is limited. Going back to my Common Lisp background, I also wrote web apps in CL, and there is no way I would even think about going back.
There are things I do not like about Clojure, but so far I haven't found anything even remotely comparable in terms of real-world productivity. So I'm sticking with what works really well, at least until something better comes along.
> There are things I do not like about Clojure, but so far I > haven't found anything even remotely comparable in terms > of real-world productivity. So I'm sticking with what > works really well, at least until something better comes > along.
This is exactly my take on it. I find myself thinking about Clojure adoption more and more these days, and where is the disconnect in all this.
I wonder if the idea of clojure both scares away "normal" programmers who are really just focused on using languages in their professional lives and want a simple, focused productive experience, and instead bring in more academic/experimental/recreational programmers who then actually dislike the fact it's made choices to promote use in the real-world.
I think you get even more benefits from Clojure if you write apps that run both server-side and client-side (in the browser, using ClojureScript).
Much thanks to the author for nicely showing a good use case for the Either monad. In general, I think there are lots of great concepts in category theory, but well hidden behind horrendous naming (bind/return, anyone?) and lack of good practical examples (well let's fmap inc over a vector here).
And since it seems everybody pitches in something about some language being inferior or superior to Clojure, I'll contribute something, too: I would not have been able to write PartsBox.io (https://partsbox.io/) without Clojure and especially ClojureScript. It boils down to practical reasons: code size, abstractions that I can build on, avoiding accidental complexity.
I don't like participating in discussions that compare programming languages these days. I feel these are often very shallow. As an example, I used to program a lot in Common Lisp, and I think it can't meaningfully be compared to Clojure/ClojureScript. You don't see that until you've written several large multithreaded applications with zero deadlocks (thanks to STM), after you've used core.async to simplify complex and bug-prone code, after you've used transducer pipelines to parallelize a large stream computation completely avoiding the horrors of Hadoop, or after you've sent your data structures over a websocket to code that is actually the same code that runs on the server (cljc, files that compile to both Clojure and ClojureScript). Seriously — how can I discuss the finer points of syntax (oh, the parentheses!) when I am able to ship React-based apps that do isomorphic rendering (the server pre-renders a page, and JavaScript plugs into it later), all in Clojure+ClojureScript, without even touching node.js? You start to appreciate those things only when you write large applications and your time is limited. Going back to my Common Lisp background, I also wrote web apps in CL, and there is no way I would even think about going back.
There are things I do not like about Clojure, but so far I haven't found anything even remotely comparable in terms of real-world productivity. So I'm sticking with what works really well, at least until something better comes along.