Transducers – Rich Hickey

Transducers, what are they?

They are in essence filter and map, step away from thinking about them as working on lists, and recast them as process transformations.

They are applicable if you model your data as a succession of steps, where each step ingests an input. Building a collection is just one instance of a process of that shape, the generalization is
‘seeded left reduce’

Why do we use the term transduce? It means ‘leading across’ which is what we do, we take input and lead it across transformations. It is not a programming thing, it occurs in real life too:

Put the baggage on the plane:

  • Break apart pallets
  • Inspect them
  • Label heavy things

What matters here is what you do, not how the luggage gets to you. You don’t have separate rules for luggage on a trolley or luggage on a conveyor belt.

So, we already have the instructions for this (map, mapcat, filter) but, we only make rules for very specific situations (lists, stream, observables) We are like luggage handlers that first put luggage from the belt on a pallet, because that is what we happen to have instructions for.


Transducers fix this!

Transducers modify a process by transforming its reducing function.


Processes that use transducers are transducible processes: they use a transduces to transform their reducing function and then do their job with the transformed reducing function.

Transducers are fully decoupled, they know nothing of the process they modify.


Early termination. Sometimes you want to stop an entire process. In Closure there is a reduce for that and transducers also support reduce. If the reducer gets a reduced value from the next call, it must never call the function again with that argument.

Ultimately, the goal is to reuse code better and to have 1 ‘thing’ to apply to all sorts of datatypes: