Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Transducers.js: A JavaScript Library for Transformation of Data

jlongster.com

Post reply on HN
Print view View original

11–20 of 22 posts

Re: Transducers.js: A JavaScript Library for Transformation of Data

#11

Post by gavinpc »

mcav wrote: post #3

I think the name "transducers" is a little unfortunate only in that it sounds very foreign to most coders, leading the concept to potentially be ignored. Don't let the name "transducers" or the relation to Clojure scare you off; you don't have to know either thing to understand how transducers can be useful.

I find the name "reduce" unfortunate, especially since the classic example,

    (defn sum [xs] (reduce + xs 0))
(or whatever) only reinforces the naive assumption that it makes the thing smaller. It was only after playing with dozens of problems on 4clojure (a great site), that I grokked how reduce can make the input much bigger, or anything you want.

So in that respect, I think "transduce" better fits the concept of transformation, which is what this is all about.

Re: Transducers.js: A JavaScript Library for Transformation of Data

#12

Post by jasonkostempski »

mcav wrote: post #3

I think the name "transducers" is a little unfortunate only in that it sounds very foreign to most coders, leading the concept to potentially be ignored. Don't let the name "transducers" or the relation to Clojure scare you off; you don't have to know either thing to understand how transducers can be useful.

I got excited to read this because of the name since earlier today I decided to dig into the general field of signal processing[1] and the first thing they talk about is transducers. With 2 minutes of transducer knowledge under my belt I think I'm fully qualified to say it seems a fitting name for this library.

[1]http://en.wikipedia.org/wiki/Signal_processing

Re: Transducers.js: A JavaScript Library for Transformation of Data

#13

Post by coding4all »

jzelinskie wrote: post #10

For some reason (maybe environmental factors), I understood this article much better than Rich Hickeys initial post. However, I suppose I should now go back and re-read it. Thanks for the great library and explanation.

There are some more explanations that might help you understand. =>

https://gist.github.com/ptaoussanis/e537bd8ffdc943bbbce7

https://gist.github.com/runexec/06b56a9dbd15e43145b9

Re: Transducers.js: A JavaScript Library for Transformation of Data

#14

Post by jlongster »

lame_duck wrote: post #5

Just by glancing quickly over it it's difficult to draw big conclusions but, while the concept certainly feels promising I'm not sure about API - transduce require 4 parameters and it feels like you really need to know what happens inside to make use of it (that append function feels especially off). But maybe it's just me not being able to switch to functional way and it's simply a matter of spending some time with…

It is very functional, so it will feel a little different if you aren't used to it.

You will rarely actually use `transduce` though, just like you probably rarely use `reduce`. You use the other two functions, `into` and `sequence` a lot more, and you don't really have to understand what's going on underneath (even if it is is pretty simple):

    sequence(compose(map(x => x + 1),
                     filter(x => x
It is a little different than standard imperative code, but I think you will find that it's more expressive.

Re: Transducers.js: A JavaScript Library for Transformation of Data

#15

Post by girvo »

akurilin wrote: post #8
alloyed wrote: post #7

Earlier quoted context omitted.

I'd hope that the same community that takes "concatenation" and "list comprehension" and "mutability" to be household words would be able to get over some jargon weirdness so long as it's explained adequately.

I'd also add homoiconicity and referential transparency to those :P

Don't forget idempotent!

Re: Transducers.js: A JavaScript Library for Transformation of Data

#16

Post by pests »

lame_duck wrote: post #5

Just by glancing quickly over it it's difficult to draw big conclusions but, while the concept certainly feels promising I'm not sure about API - transduce require 4 parameters and it feels like you really need to know what happens inside to make use of it (that append function feels especially off). But maybe it's just me not being able to switch to functional way and it's simply a matter of spending some time with…

Somebody more knowledgeable correct me if I'm wrong, but the append function being taken out of the reduce logic is intentional. It specifies how the results are put back together (in this case with arrays / Vector, append is used) in a data-structure agnostic way.

Re: Transducers.js: A JavaScript Library for Transformation of Data

#18

Post by blackkettle »

mcav wrote: post #3

I think the name "transducers" is a little unfortunate only in that it sounds very foreign to most coders, leading the concept to potentially be ignored. Don't let the name "transducers" or the relation to Clojure scare you off; you don't have to know either thing to understand how transducers can be useful.

actually i think it is unfortunate for a completely different reason: transducers, particularly finite-state transducers, already have a long and rich history in both applied and theoretical computer science; and are currently one of the fundamental building blocks of most NLP and ASR systems in industry and academia.

see http://www.openfst.org and many others.

tacking on some random new etymology, 'transducer is just a combination of transform and reduce', is going to lead to all sorts of unnecessary confusion, made worse by the inherent similarities...

Re: Transducers.js: A JavaScript Library for Transformation of Data

#20

Post by worldsayshi »

The idea of declaratively describing transformations of data seems very exciting to me. I haven't experienced anything that lives up to the excitement though.

I feel a bit underwhelmed by these examples. Seems a bit to imperative, an enhancement of underscore. I want the declarations of how data representations relate to each other to be separate from the "how" in how to transform from one format to another. Probably something inspired by lenses (1). "Lenses are the XPath of _everything_." (2).

(1) - https://www.fpcomplete.com/school/to-infinity-and-beyond/pic...

(2) - https://twitter.com/steveklabnik/status/463748643141349376

edit: Relevant HN comment about using Lenses for reaching into data objects: https://news.ycombinator.com/item?id=7704504

Post reply on HN