Probably just plain old functions & laziness.
If you want to interleave IO into it then probably a library like conduit.
If you want to interleave IO into it then probably a library like conduit.
Given transducers, we can compose mutually independent parts at will:
- Data source (sequence, stream, channel, socket etc.)
- Data sink (sequence, stream, channel, socket etc.)
- Data transformer (function of any value -> any other value)
- Data transformation process (mapping, filtering, reducing etc.)
- Some process control (we can transduce finite data (of course) as well as streams, and also have optional early termination in either case. I'm not sure about first-class support for other methods like backpressure.)
e.g. read numbers off a Kafka topic, FizzBuzz them, and send them to another Kafka topic, OR slurp numbers from file on disk, FizzBuzz them, and push into an in-memory queue. But each time, you don't have to rewrite your core fizzbuzz function, nor your `(map fizzbuzz)` definition.
cf. https://www.evalapply.org/posts/n-ways-to-fizzbuzz-in-clojur...
I view this as a good sign. When two independent parties arrive at the same design it is usually an indication that they have discovered a universal and principled solution.
I consider the "conduit" library to be one of Haskell's "killer features", and sorely miss having something like it when working in other languages.
Maybe when Haskellers dismiss clojure transducers as being "just like conduit" it comes from a place of jealousy? I've seen several articles and discussions over the years of clojure transducers that take place outside of clojure communities and are aimed at the wider programming public, praising the benefits of it. But I've never seen conduit discussed outside of Haskell communities.