Magical, Mystical JavaScript Transducers
jrsinclair.com
jrsinclair.com
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;
}This point isn’t about transducers specifically but more about avoiding specifying the things you don’t care about. Eg, in Common Lisp (which was old enough to somewhat care about how to iterate things):
(defun avg-popularity (list)
(loop for item in list
when (plusp (popularity item))
sum pop into s
count t into c
finally (return (/ s c))))
(defun avg-popularity (list)
(loop
for item in list
for pop = (popularity item)
when (plusp pop)
sum pop into s
and
count t into c
finally (return (/ s c))))
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()
- no state
- reusable pure functions
- a tad shorter
- maybe as readable as the `for over state` idiom ? (depending on habits)(Edit: This is a big point in the article -- apologies, I hadn't finished reading it yet.)
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 make the functional approach as efficient as the imperative for loop.
Now if you do that by hand, you end up with some messy code. So the article shows how you can combine the operations with a helper library in a structured way.
That said, it kind of reminds me of The Evolution of a Haskell Programmer [0]
[0] https://www.cs.utexas.edu/~cannata/cs345/Class%20Notes/10%20...
The puzzle nature of FP can sometimes prevent the simplest solution to a problem. For example, try writing a function that accepts a list of N numbers between 1 and N and returns its histogram (list of counts of each number). There's an imperative solution in O(N) time with one for loop. But in FP, I'm not sure O(N) can be achieved, and even O(N log N) requires tree-like data structures that aren't needed in imperative.
[1] Of course we have plenty of other reasons to use it, but I digress.
++(histogram[sampleId]);
Found a decent discussion on the matter. Main issue at hand is that its not really FP in question, but datastructures, and more specifically, how far you extend immutability semantics.
In this case, if you forgo immutability requirement, you can trivially mantain semantic purity while still updating the simple array. But with immutability, you can’t construct an array, so you’re locked behind log(n) datastructures
I've always been uneasy with FP-style coding for three reasons:
- you have strictly no idea how your code will be evaluated by the CPU. Some people love that aspect. It makes me immensely queasy. I might be a control freak.
- as much as I love the idea an cleanliness of composing functions, having to abandon mutability for that is way too hefty a price to pay. There are situations where overwriting memory is the darndest best way to do things. Yes, side-effects are hard to code with, but just like gotos, there are situations where they are the best solution.
- I've always felt that FP coders are way too focused the beauty of their code rather that the industrial strength of it, which includes: readability, how easy it is to change, efficiency. Proper production code shouldn't be origami puzzles.Exactly, when refactoring code the first thing I do is remove all the boxes, create a huge monolithic procedure, then I can see all the inefficiencies, optimise and simplify it, then break it into better fitting boxes (if necessary).
I don't follow the lingo for all the patterns, but ultimately they are usually just different ways of wrapping up things in boxes. I think they are wooden bullets, the most important thing is to not make boxes too quickly, it should be the very last thing you do after figuring out what the code needs to in it's entirety holistically.
I think the bane of most software complexity is actually people being too scared of taming large contexts, so instead they wrap themselves in a hell of spaghetti boxes, just deferring issues and creating inefficiency and obscurity.
[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.
The reason to use transducers instead of a for loop here is that it allows you to expose a library function which takes a transducer as input. It's hard to refactor the for loop above to allow someone consuming this function to specify additional things they want to aggregate due to an API change in the definition of the 'slang' type, but with transducers you just take one as an argument.
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!
Please, I have a wide screen, let me use it.
Linq with IEnumerable doesn't necessarily create intermediate list (js arrays) in memory unless it has to like say .OrderBy()
So I basically assumed js was the same since it has generators but its seems map and filter etc don't support them yet?:
https://dev.to/nestedsoftware/lazy-evaluation-in-javascript-...
So then you get a solution like this that looks to me very confusing vs a fluent style.
Please tell me I am missing something
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 is pretty, or at least clean and tidy.
Ramada looks interesting ...
function isFound(item) {
return item.found;
};
This is the best example of a forced pattern.
d3.mean(victorianSlang, d => d.popularity)
This implicitly ignores invalid values (null, NaN or undefined) after coercing to a number.
I don't know how JS generators work but Python users seemed to think Python's generators cover most transducer use cases.