It’s too bad that transducers were created long after clojure’s inception. Can you always replace a lazy seq with a transducer? Could the language theoretically be redesigned to replace all default usages of lazy seqs with transducers, even if it were a major breaking change? And have lazy operations be very explicit?
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.
Transducers were at least 20 years old when Clojure was first created. I have the book "Common Lisp: the language" from 1989 that describes transducers as found in Clojure.
Clojure is the only language where it is baked in that prominently though.
Comments
It’s too bad that transducers were created long after clojure’s inception. Can you always replace a lazy seq with a transducer? Could the language theoretically be redesigned to replace all default usages of lazy seqs with transducers, even if it were a major breaking change? And have lazy operations be very explicit?
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.
Transducers were at least 20 years old when Clojure was first created. I have the book "Common Lisp: the language" from 1989 that describes transducers as found in Clojure.
Clojure is the only language where it is baked in that prominently though.