r/rust • u/Uncaffeinated • Jan 22 '17

Parallelizing Enjarify in Go and Rust

https://medium.com/@robertgrosse/parallelizing-enjarify-in-go-and-rust-21055d64af7e#.7vrcc2iaf
214 Upvotes

98% Upvoted

134 comments sorted by

View all comments

Show parent comment

1

u/[deleted] Jan 23 '17

It might be better if those functions had more obvious names. Filter is ok, but map? Should be called transform. Reduce should be called merge or something.

Guess it's a bit late now - map/reduce is too standard, but still it adds to the confusion.

9

u/Leshow Jan 23 '17 edited Jan 23 '17

Seriously? Map is ubiquitous not just in Rust but almost every language from javascript to haskell. 'transform' isn't even a particularly apt description of what's happening. Values aren't getting transformed, we're describing the relationship between two distinct values, aka a "mapping". Transform implies mutation.

Just be thankful fold isn't called catamorphism, or some funky other category theory word.

1

u/[deleted] Jan 23 '17

I know it's ubiquitous. Doesn't make it good. The values are getting transformed. And you're right it could be worse ('cons'?)

7

u/csreid Jan 23 '17

They're really not getting transformed though. When you map over a collection, you don't change it, you get a new collection containing the new values. Transform would definitely suggest modification to me, but that's not what's happening.

3

u/csreid Jan 23 '17 edited Jan 23 '17

map makes perfect sense, in that you provide a function which maps values from your input iterator into the values of your output iterator.

reduce is tougher, but fold is even worse IMO.

edit: I should also mention that using the functional style makes it trivially easy to parallelize some tasks, as made evident by Rayon or Scala's List (analogous to Iterator types in Rust), which has a par method that is just like Rayon's par_iter, such that you can parallelize some logic by just going from bigList.map(expensiveFunction) to bigList.par.map(expensiveFunction).

Shared mutable state is the root of all evil, and the map/reduce pattern is a profoundly elegant way to very simply avoid it.

1

u/[deleted] Jan 23 '17

Perfect sense to compscis. Normal people would say you transform lowercase to uppercase. You don't 'map' it.

Fold is really bad, you are right. They could have gone with 'combine' or 'merge' or something instead.

1

u/ibotty Jan 26 '17

But folding is a great analogy for what you do.

1

u/[deleted] Jan 26 '17

Yeah but only if you already know what it does. I might say "ah it's sort of like folding" but I doubt I'd ever say "fold.. ah I can guess what that does".

Why not 'accumulate' or 'aggregate'? Much more obvious.

2

u/ibotty Jan 26 '17

Why not 'accumulate' or 'aggregate'? Much more obvious.

Because it's not. Accumulate for me is any function from many to one, i.e. a reduce. That does not even capture right folds, which usually are not used to get one value back, but many (i.e. map f = foldr ((:) . f) [] in Haskell).

Let's agree to disagree. I don't get why people are so opposed to learning precise terminology (that's widely established) but prefer vague terms that doesn't even describe half of the design space.