I believe you, but it would be nice if you called out the exact vendors that do that, for others to be cautious. It's not like their pricing is under NDA, right?
Clojure authors are quite conservative about adding such opinionated instruments into the language, especially when they come from outside. But fortunately, being a Lisp allows Clojure to add such language modifications with libraries without forcing those modifications upon every user of the language.
1) they did add threading macros, which are very popular, and these seem to serve a very similar purpose for transducers. You could argue their inclusion would make the language a little more uniform even.
2) There is precedence for doing the same operation with different mechanisms, like map vs mapv, so the change fits in nicely in that sense
3) as the article points out (edit: just realized you are the author, heh, hello!), transducers often have better performance than alternatives. I think it makes sense to highlight them and encourage their usage as much as possible. The more high performance code in the wild, the better. Even just introducing new ergonomics that facilitate their usage will influence that.
This is sort of true, but it doesn't scale well. You quickly end up having a very verbose `ns` declaration at the top of every file as you try to extend your Clojure
To cut down on the noise, you can coalesce all your extensions into one `ns` but it's not technically feasible with `core` and needs to be done with another library:
It could certainly be redesigned to have explicit lazy collections/operations and use transducers as the composition glue. It would be a breaking change, so it's never going to happen in Clojure. But if somebody plans to design a language inspired by Clojure, they should certainly take this hint.
If we ever found ourselves in a position where Clojure’s market share was decreasing YoY, do you think it would ever make sense for Clojure’s maintainers to design a new language that implements this + any other issues that come up on Clojure’s yearly survey (and other lessons learned) that might be more easily addressed by sacrificing backwards compatibility? Or do you do think the community would want them to focus on maintaining Clojure themselves?
I realize the maintainers likely would not even be interested in such a thing, of course, just daydreaming.
Well, if you already use transducers, then you are not exactly the target audience:). It's meant more for the younger developers who see a core language feature and feel inclined towards using it despite the drawbacks.
> In other words, it's something I don't think much about anymore, and it doesn't inconvenience me in any noticeable way.
Interesting, because it still does bother me. I mean, if I use lazy sequences and functions on them. Sure, if I consciously avoid them, then it doesn't me anymore, that's the point of the article :D.
To me, this makes total sense as the project moved to Apache. Obviously, much more people will be able to consider contributing when it's in Java. Apache goal is sustainability and long-term viability, and Java would work better for that.
I also consider this a success story for Clojure. It gives Clojure another usecase: a "production-ready prototype" language where the resulting "prototype" can last for eight years and benefit thousands of developers until it gets rewritten to something else when all the hard questions are answered, and most experimentation/wandering is over.
(I think the HN title was edited since your comment; I think an earlier title highlighted the move from Clojure to Java.)
> It gives Clojure another usecase: a "production-ready prototype" language where the resulting "prototype" can last for eight years [...] until it gets rewritten to something else when all the hard questions are answered, and most experimentation/wandering is over.
That general story, first heard from Paul Graham, about projects starting with Lisp and being successful that way, before eventually being rewritten, works for me.
I've been hoping at least a couple college startups would be inspired by this to use Racket initially, but if they have, I haven't heard of it. (I speculate that the current FAANG feeder emphasis among CS students hasn't helped. Who has time to play with a Lisp, when the now-all-important whiteboard interviews won't use it.)
> Obviously, much more people will be able to consider contributing when it's in Java.
If you have a company, and you want to hire Lisp people (whether it's Clojure, CL, or Scheme/Racket), I think you can probably hire people, because Lisp people like getting paid to use Lisp.
If you're looking for unpaid/volunteer contributions to an open source project, there's all sorts of things that affect that, and it's not unusual to get little-to-no contributions.
"Storm ditches Clojure in favor of Java in its core". A moderator changed it, in accordance with the site guideline: "Please use the original title, unless it is misleading or linkbait; don't editorialize."
> I also consider this a success story for Clojure.
It is a success story for Clojure, but this move is a big negative feedback for the language. A team starting out on an open-source project will be mighty reluctant to start it with Clojure; because it might get rewritten not so much into the future. That is not good news for Clojure
If, five years (or what-have-you) down the line—when you've pretty much enumerated all use-cases for the project, solidified what it's supposed to do and how, learned from your mistakes, and so on—you can't come up with a better design, something is off. With all that knowledge, there should be plenty of space for performance optimizations and pruning of vestigial stuff for a non-trivial project.
As for switching to Java, that makes perfect sense to me if that is what the contributors prefer. If you're going to make a big rewrite, you might as well change the language to one you prefer when you have the opportunity.
As someone who spends 100% of dev time in Clojure, I'm quite happy to see this development. Dipping into Java isn't uncommon for optimizations in Clojure, so this is like someone taking the time to do a massive under-the-hood optimization from the point of view of a Clojure user. I doubt it changes the project's status much in the Clojure community. Perhaps it'll even see an uptake in use.
What it doesn't say much about is Java vs. Clojure in my opinion. Different contributors, with different amounts of pertinent knowledge, and years apart. I'm not sure how you would control for those variables in a comparison. It should be read more as, "we put in a heck of an effort to make this thing faster and more useful", and kudos for that.
Oh no, I'm saying it's another usecase, not the only one. And yet, it is a pattern I follow quite often in my mixed Clojure/Java projects: Clojure code is much easier to tinker with, take to new directions, rapidly modify and see the results. But once I settle with an approach/algorithm, I rewrite some things to Java for performance, or for easier interop with other Java/Scala teams, or because the imperative mutable code looks much better in Java.
So, you can say that Clojure among everything else is my IDE to write Java code. Is that a bad suit for a language? Depends on your perspective, but I personally am very happy that I have Clojure by my side.
Whatever the benefits of Clojure are, they were enough for Nathan Marz and first contributors to write Storm in it and succeed. Note that it's not an argument about impossibility of writing something like that in Java (see Spark, Flink, Heron, etc). But at that exact moment in time, a Clojure Storm was created and became useful to many people for years. There were many more Java programmers than Clojure programmers then and now, yet the Java coomunity didn't produce their own Storm first.
It doesn't. There are plenty of Clojure projects out there and nobody's rewriting them in other languages. There are also plenty of companies nowadays that have been using Clojure for years. The feedback from them is overwhelmingly positive.
Rewrites between languages keep happening in all kinds of permutations. I think pessimism or optimism from just headlines and announcements is more about what you read into it.
It reminds me of the “why we switched from Mongo to X” or “why we switched from Ruby to Y” trends some years ago.
I saw Clojure become popular long before it was ready for the limelight: it definitely wasn’t pragmatism driving it. It was a fetish for syntax and paradigm.
I think it’s very difficult to motivate going out of your way to hire decent devs that know clojure and java only to throw away the clojure some time down the road.
Begs the question, why not just write it in Java? Then at least its more likely to be a refactor down the road rather than a rewrite.
I think clojure ought to be a production ready language that scales well. That’s what it was designed to be. However lisp seems to dichotomise devs into those that get it and those that don’t and thus alienates many would be team members.
