I tried using it maybe a decade ago and back then it had a tendency to mess up window layouts and leave weird buffers around. I notice there's now a GitHub repository which has two spurts of work in its history that probably didn't exist when I last used it – have they improved its usability?
Turning didn't work for me. Impressive as hell indeed! The author is probably already busy 100xing other projects, no time to fix such a minor nuisance.
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.
reply