Live data from Hacker News

Magical, Mystical JavaScript Transducers

jrsinclair.com

31–40 of 51 posts

Re: Magical, Mystical JavaScript Transducers

#31

Earlier quoted context omitted.

The article obfuscates the point. Reducers/transducers are from the FP world. In FP avoiding mutable state is one the main point. dot = field => obj => obj[field] // unsafe Array.average = self -> reduce(add, self) / self.length // unsafe slang.filter(s -> s.popularity > 0) .map(dot('popularity')) .average() Bonus points: - no state - reusable pure functions - a tad shorter - maybe as readable as the `for over state`…

Downside: Still going over the array multiple times.

fair point, in js it will, in other languages that idiom gets deforested into a single pass though

Re: Magical, Mystical JavaScript Transducers

#34
post #21

Earlier quoted context omitted.

Yours is the obvious solution but the problem is a simple example to help people understand the more complex idea of transducers. It's for situations where the code inside the for loop is so complex that it would be nice to organize it with functional programming principals. The problem with functional programming is that the obvious approach is not efficient since it passes the array several times. So the goal is to…

FP works very well in short simple examples. If the for loop would be any more complex the FP solution would probable be incomprehensible. Optimizers however love small immutable and steteless functions so FP would likely be faster then the imperative version. For example by making it run parallel, caching, inlining, etc

>FP would likely be faster then the imperative version

[citation needed]

I highly doubt that even the most sophisticated JS engines would produce faster machine code from the functional spaghetti than a simple for loop.

Re: Magical, Mystical JavaScript Transducers

#35
post #3

Impressive amount of code and words. I think I'd think twice before approving this in a code review, though. Why is this not the obvious solution to the stated problem? function avgPopularity(slang) { let sum = 0; let count = 0; for (item of slang) { if (item.popularity > 0) { sum += item.popularity; count += 1; } } return sum / count; }

because there is dirty mutation and it relies entirely on side effects to work. (this is sarcastic, that is exactly how one should go about this one example case.)

It however is a completely different thing when longer chains of filter / map need to come along and the true power of transducers is needed.

In clojure I've had to use transducers at least three times in the course of the last four years!

Re: Magical, Mystical JavaScript Transducers

#36
post #30

It's so depressing that JavaScript is growing in use, especially when I see articles like TFA. I hate that momentum has allowed a clusterf*ck of a language to become the standard for front end and now one of the top 3 for back-end. Here's Clojure's explanation of transducers: https://clojure.org/reference/transducers The whole concept is explained more clearly and with far fewer words and code; and the final result i…

I really disliked how talkative this author is. So many unnecessary sentences. But I don't think that has anything to do with the language.

Re: Magical, Mystical JavaScript Transducers

#38

Every time I see this blog I'm extremely interested in the content, but the stylized presentation is so jarring and tough to read. I doubt this is an original qualm and I'm fully able to switch to reading mode in Firefox to mitigate this problem, but frankly it's off-putting.

On the other hand I have zero issues with the design, like it aesthetically and find it a refreshing change to see a blog clearly designed to be functional and refreshingly different.

I wouldn't describe it as "functional" given the unnecessary font and background.
Post reply on HN