3 ms·

What problem does this solve? It seems to trade more-verbose code for being more performant in large datasets. That seems reasonable. But otherwise, in day-to-d

by Touche 12y ago

What problem does this solve? It seems to trade more-verbose code for being more performant in large datasets. That seems reasonable. But otherwise, in day-to-day code why would I use this?

juliangamble 12y ago
This is an example usage based on Dr Seuss: "Green Eggs and Transducers" via @gigasquid http://gigasquidsoftware.com/blog/2014/09/06/green-eggs-and-transducers/ http://gigasquidsoftware.com/blog/2014/09/06/green-eggs-and-... (note this is in Clojure not JavaScript - but the ideas and usages are the same).
coldtea 12y ago
Because lots of day-to-day uses large datasets? Especially since 10,000 item array is considered "large" from that perspective.
Thomasdah 12y ago
The goal is to be less-verbose. You are able to use tansducer-based functions (map, filter, ...) on any datastructure that is iterable. For me, performance is a bonus. I do not know how this compares to a monad/monoid. If anyone can explain, please go ahead. Thx!
- tel 12y ago
  Monad/Monoid are a different category of things from transducers—think of them more like an interface than a thing. For instance, a basic model of Transducer is as follows type Trans a b = forall r . (r -> b -> r) -> (r -> a -> r) and it turns out that this is isomorphic to (e.g. an optimization of) the list Kleisli arrow type KleiList a b = a -> [b] and lists are monads. For a slightly different reason, this argumentation leads me to believe that Transducers ought to be monads via the Reader/List transformer stack. I haven't verified it, however. Transducers could be monoids, too. You'd need to have two operations like so zero :: Transducer a b add :: Transducer a b -> Transducer a b -> Transducer a b and perhaps there would be necessary restrictions on the choices of `a` and `b`. It's immediately obvious we could make this work if `a` and `b` were equal zero :: Transducer a a add :: Transducer a a -> Transducer a a -> Transducer a a as this is now just the "identity" transducer and transducer composition which satisfy all the laws of monoid.
- Touche 12y ago
  You are able to use transducers on any datastructure that implements the protocol. Which means usually implementing it yourself. for/of solves this in JavaScript. I don't see the usability improvement this presents. I'm not being a naysayer. I hope I'm wrong here, I'm just asking.

by Touche 12y ago

What problem does this solve? It seems to trade more-verbose code for being more performant in large datasets. That seems reasonable. But otherwise, in day-to-day code why would I use this?

juliangamble 12y ago

This is an example usage based on Dr Seuss: "Green Eggs and Transducers" via @gigasquid http://gigasquidsoftware.com/blog/2014/09/06/green-eggs-and-transducers/ http://gigasquidsoftware.com/blog/2014/09/06/green-eggs-and-... (note this is in Clojure not JavaScript - but the ideas and usages are the same).

coldtea 12y ago

Because lots of day-to-day uses large datasets? Especially since 10,000 item array is considered "large" from that perspective.

Thomasdah 12y ago

The goal is to be less-verbose. You are able to use tansducer-based functions (map, filter, ...) on any datastructure that is iterable. For me, performance is a bonus. I do not know how this compares to a monad/monoid. If anyone can explain, please go ahead. Thx!

tel 12y ago
Monad/Monoid are a different category of things from transducers—think of them more like an interface than a thing. For instance, a basic model of Transducer is as follows type Trans a b = forall r . (r -> b -> r) -> (r -> a -> r) and it turns out that this is isomorphic to (e.g. an optimization of) the list Kleisli arrow type KleiList a b = a -> [b] and lists are monads. For a slightly different reason, this argumentation leads me to believe that Transducers ought to be monads via the Reader/List transformer stack. I haven't verified it, however. Transducers could be monoids, too. You'd need to have two operations like so zero :: Transducer a b add :: Transducer a b -> Transducer a b -> Transducer a b and perhaps there would be necessary restrictions on the choices of `a` and `b`. It's immediately obvious we could make this work if `a` and `b` were equal zero :: Transducer a a add :: Transducer a a -> Transducer a a -> Transducer a a as this is now just the "identity" transducer and transducer composition which satisfy all the laws of monoid.
Touche 12y ago
You are able to use transducers on any datastructure that implements the protocol. Which means usually implementing it yourself. for/of solves this in JavaScript. I don't see the usability improvement this presents. I'm not being a naysayer. I hope I'm wrong here, I'm just asking.