Live data from Hacker News

Understanding Transducers

elbenshira.com

11–16 of 16 posts

Re: Understanding Transducers

#11
post #7

For those that have a hard time reading the clojure code, i recomend this blogpost where they are explained with js. See: http://phuu.net/2014/08/31/csp-and-transducers.html

That article was what inspired me to write this blog post.

In short, the key insight of the blog post is this (via untested javascript):

You can define transforming functions like map and filter via reduce (e.g. foldleft or, for Ruby, inject) instead. For example,

  map([...], function (x) { return x + 1; });
Can be written as:

  // append (x + 1) to the result collection
  reduce([...], [], function (result, x) { return append(result, plusOne(x)); });
But notice that, above, we explicitly chose `plusOne` and `append`. If we allow a user to pass in any function instead, then we have a higher-order function:

  function mapping(f) {
    return function (reducing) {
      return function (result, input) {
        return reducing(result, f(input));
      }
    };
  }
Now we can do:

  var xform = mapping(plusOne)(append);
  
  reduce([...], [], xform);
`xform` is a transducer.

Re: Understanding Transducers

#12
post #2

I am not a functional programmer and I always find that when I read clojure it just looks like layers and layers of nested code. Personally, I find it visually hard to parse. Can someone enlighten me why clojure seems to be the trending language?

You should try haskell, it has more syntax but as a result it provides more context and is much more concise.

Re: Understanding Transducers

#13
post #10

This is tangential, but as a medical device engineer and one that works quite a bit with Ultrasound, the title of this article caught my interest, but it turned out to be about something completely different. http://en.wikipedia.org/wiki/Ultrasonic_sensor#Transducers

I've noticed that simple googling for Clojure keywords is one of the more amusingly fruitless activities to do. Almost every term I lookup is a high level concept in some potentially vaguely related field. For example, on the frontend, reagent + state gives me chemistry results, during music overtone + piano gives me piano acoutics, etc etc etc.

Re: Understanding Transducers

#14
post #10

This is tangential, but as a medical device engineer and one that works quite a bit with Ultrasound, the title of this article caught my interest, but it turned out to be about something completely different. http://en.wikipedia.org/wiki/Ultrasonic_sensor#Transducers

I've noticed that simple googling for Clojure keywords is one of the more amusingly fruitless activities to do. Almost every term I lookup is a high level concept in some potentially vaguely related field. For example, on the frontend, reagent + state gives me chemistry results, during music overtone + piano gives me piano acoutics, etc etc etc.

tack on 'clojure'?

Re: Understanding Transducers

#15
post #14

Earlier quoted context omitted.

I've noticed that simple googling for Clojure keywords is one of the more amusingly fruitless activities to do. Almost every term I lookup is a high level concept in some potentially vaguely related field. For example, on the frontend, reagent + state gives me chemistry results, during music overtone + piano gives me piano acoutics, etc etc etc.

tack on 'clojure'?

Thats hopefully already obvious.

Re: Understanding Transducers

#16
post #4
post #2

I am not a functional programmer and I always find that when I read clojure it just looks like layers and layers of nested code. Personally, I find it visually hard to parse. Can someone enlighten me why clojure seems to be the trending language?

As far as functional languages go, it's a nice compromise between the absolute purity of something like Haskell and the day-to-day practicalities necessitated by building practical, scalable things quickly (core.async, nice Java integration, runs on the JVM). As far as looking like a parenthesis layer cake, that's part of the Lisp "tradition", really. One can look at is as the price you pay for true homoiconicity and…

"the absolute purity of something like Haskell"

Working with Haskell for a while, "absolute" there starts to seem weird - there is room in "programming language space" for "more pure than Haskell", and some attempts at it. I've not drawn any conclusions yet as to whether anything in that space is practical, but it's certainly interesting.

Post reply on HN