Clojure's been my go-to language since around 2009, and I use it full-time today. A few points from the article:
The horrible if-let code the author shows is exactly the kind of thing people use macros for. I'm surprised nothing exists in clojure.core for this, but every project I've ever worked on has something like if-lets, which short-circuits on the first falsy assignment. Everyone thinks they don't need macros and then finds stuff they hate in the language which is easily fixed by macros. This is probably true of the non-mainstream paradigms in all languages. It takes some willpower and humility to learn all Haskell's lens arrow operators instead of just laughing at them.
clojure.spec is nice, and I use it in my current project, but it has performance issues (it is after all basically alpha code) and I'll be honest that I don't _really_ understand what the workflow is supposed to be. If you deal with a lot of side-effectful code you might be using conforms and asserts to keep things sane, but I'm not really benefiting from the generative testing bits. Thinking in terms of generators for code that _is_ pure just feels like another job that I've for some reason forced on myself. Anyway, at the very least, it does make the world of procedural code operating on maps a little safer and saner and you should probably try it.
My complaints about Clojure are nothing to do with the language, which I think is absolutely fine. My main complaint is that Clojure people are smart, and fundamentally believe in small libraries over frameworks, and this means that the Clojure landscape is scattered with abandoned overly-specific libraries, and abandoned and unloved big frameworks. If I could, I would pay someone full time to maintain Incanter, but it's now basically dead, and that means Clojure has no useful numerical computing environment. I am lucky that I can get by with what already exists in Incanter and what's in clj-ml for my analytics work, but nobody is going to quit Python or R for Clojure at this point unless they're smart enough and willing to write all this for themselves.
I happen to do some web stuff and I think ClojureScript is about as good a language as you're ever going to get on the browser. But the other consequence of a community where most people are smarter than you is that the best front-end frameworks are utterly inscrutable. Om has wonderful functionality that I think I would like in my app, but I am too dumb to understand all the moving parts. Reagent is very elegant but is tougher to scale to complex web apps.
I still believe that Clojure is a beautiful and productive language. Year after year I see other languages pile on new syntax while Clojure just remains brackets and functions. For the parts of my code that are pure and functional it's wonderful, for the parts that are ugly and pragmatic I have the full range of the JVM landscape available to me. I get to stay in Emacs, and Cider me custom elisp does everything I need for an IDE. But if anyone asked me to recommend a language to spend their lives in I would probably just say Python and if you do web stuff JavaScript. Bigger community, better maintained open source projects, and just a clearer roadmap to mastery.
They are much more low-level than Incanter, but also orders of magnitude faster, and intended as a foundation for the Incanter-like libraries to be built on top.
Re incanter I fully agree - it also works for all my use cases (well, if something is missing and you know what you want, you can usually write it on your own using stuff incanter does have, did this eg for Logistic Regression) but I think it has so much potential.
For some time I expected a Java lib to appear but whatever came was always forcibly distributed (Spark, Mahout) and/or you had to first instantiate an AnnotatedDistributionParameterFactory which instantly makes me want to puke. So there we go, incanter is not maintained but probably the best you can get on the JVM :-/
The only reason to tolerate a language as terrible as R is that it has such astonishingly broad library support - there is basically no algorithm you can find on Wikipedia that doesn't have some sort of R implementation. Incanter will never have this, and tbh it's very difficult to create outputs as pretty as themed ggplots. For very simple statistical analysis Incanter's okay (and I've seen smart people build lots more on top of it), but even really basic model-fitting stuff isn't built in, and if you're not smart or just don't have the time, it'd be mad to commit to that environment.
It's a shame because structurally it's quite nice, and I did buy into the idea that Lisps were well suited to this sort of work, especially being very REPL focused.
I never really took a look at Weka since I am using the results commercially (or rather my clients do) and I think I "distribute" that software.
Now maybe I could make the case that I am not distributing the software but I write it in their name and on their bill. In other words, I can use it as long as my job is to write software (for them) instead of creating a product that I will sell.
Still, I prefer to stay away from it as long as possible but I agree it will be hard for some tasks such as decision trees which are unfortunately a very nice fire and forget algorithm.
There are people claiming that you can do most of classification and regression using logistic and linear regression, so I try to stick to that as long as possible and incanter allows for that.
Its a 'web framework', but really its just a module system. It tries to be a get started fast and still be able to do really complex stuff kind of framework.
I am running into the same issue in Production and I hope to use Arachne to make this easier in the future.
Yeah, I find re-frame a little clunky if I'm honest, e.g. extending/intercepting fx is hard, the balance of local ratoms vs global subs/handlers is difficult, there's no real enforcement of layering so you have to work hard to get your subs/events at the right level etc. I dunno, I understand the aims and I use it on a couple of things, I just think it loses the elegance of Reagent without really giving you the scalability of Om. I'd have to spend more time on a few greenfield projects to get a decent picture though.
The horrible if-let code the author shows is exactly the kind of thing people use macros for. I'm surprised nothing exists in clojure.core for this, but every project I've ever worked on has something like if-lets, which short-circuits on the first falsy assignment. Everyone thinks they don't need macros and then finds stuff they hate in the language which is easily fixed by macros. This is probably true of the non-mainstream paradigms in all languages. It takes some willpower and humility to learn all Haskell's lens arrow operators instead of just laughing at them.
clojure.spec is nice, and I use it in my current project, but it has performance issues (it is after all basically alpha code) and I'll be honest that I don't _really_ understand what the workflow is supposed to be. If you deal with a lot of side-effectful code you might be using conforms and asserts to keep things sane, but I'm not really benefiting from the generative testing bits. Thinking in terms of generators for code that _is_ pure just feels like another job that I've for some reason forced on myself. Anyway, at the very least, it does make the world of procedural code operating on maps a little safer and saner and you should probably try it.
My complaints about Clojure are nothing to do with the language, which I think is absolutely fine. My main complaint is that Clojure people are smart, and fundamentally believe in small libraries over frameworks, and this means that the Clojure landscape is scattered with abandoned overly-specific libraries, and abandoned and unloved big frameworks. If I could, I would pay someone full time to maintain Incanter, but it's now basically dead, and that means Clojure has no useful numerical computing environment. I am lucky that I can get by with what already exists in Incanter and what's in clj-ml for my analytics work, but nobody is going to quit Python or R for Clojure at this point unless they're smart enough and willing to write all this for themselves.
I happen to do some web stuff and I think ClojureScript is about as good a language as you're ever going to get on the browser. But the other consequence of a community where most people are smarter than you is that the best front-end frameworks are utterly inscrutable. Om has wonderful functionality that I think I would like in my app, but I am too dumb to understand all the moving parts. Reagent is very elegant but is tougher to scale to complex web apps.
I still believe that Clojure is a beautiful and productive language. Year after year I see other languages pile on new syntax while Clojure just remains brackets and functions. For the parts of my code that are pure and functional it's wonderful, for the parts that are ugly and pragmatic I have the full range of the JVM landscape available to me. I get to stay in Emacs, and Cider me custom elisp does everything I need for an IDE. But if anyone asked me to recommend a language to spend their lives in I would probably just say Python and if you do web stuff JavaScript. Bigger community, better maintained open source projects, and just a clearer roadmap to mastery.