Comment by colejohnson66

For me, code with reduce is less readable than a loop. With loop everything is obvious, but with reduce you need to know what arguments in a callback mean (I don't remember), and then think how the data are transformed. It's an awful choice in my opinion. Good old loop is so much better.

When used correctly it shouldn't produce any side-effects outside the mapping of each element.

But that's just a social convention. There's nothing stopping you from doing other things during your map or reduce.

In practice, the only difference between Map, Reduce and a For loop is that the first two return things. So depending on whether you want to end up with an array containing one item for each pass through the loop, "something else", or nothing, you'll use Map, Reduce or forEach.

You can still increment your global counters, launch the missiles or cause any side effects you like. "using it correctly" and not doing that is just a convention that you happen to prefer.

Yeah, I'd much rather have something like

  congruence_classes m l = map (\x -> ((x ==) . (`mod` m)) l) [0..m-1]

than

  def congruence_classes(m, l):
      sets = []
      for i in range(m):
          sets += [[]]
      for v in l:
          sets[v % m] += [v]
      return sets

For-in is very neat and nice but it still takes two loops and mutation to get there. Simple things are sometimes better as one-line maps. Provability is higher on functional maps too.

Same one-liner in (slightly uglier) Python:

  def congruent_sets(m, l):
    return list(map(lambda x: list(filter(lambda v: v % m == x, l)), range(m)))

> For instance, map - I know that it will return a new collection of exactly the same number of items the iterable being iterated has.

Unless you're using Perl - "Each element of LIST may produce zero, one, or more elements in the generated list".

While these are all valid and well thought out arguments, in this particular example, a whole class of problems and bugs were introduced specifically by avoiding simple loops.

Not to mention the performance implications. Parallelisation, composability and system thinking are sometimes overkill and lead to overengineering.

> So it makes sense to choose the weakest version.

Only if it's actually more readable. The principle of least privilege does not give you any benefit when talking about loop implementations.

> More specifically, maps can be trivially parallelized;

This argument is repeated time and time again but I've never actually seen it work. Maps that can be trivially parallelized aren't worthy to parallelize most of the time. In the rare case it's both trivial and worthy, it's because the map function (and therefore the loop body) are side-effect free, and for those rare cases you don't care too much about the slightly extra effort of extracting the loop body into a function.

> when you look at the system as a whole lots of for loops make reasoning about the global behaviour of your code a lot harder for the simple reason that for-loops are too "strong"

Code is too strong in general. Reasoning about the global behavior of code is difficult if the code itself is complex. Nested maps and reduces will be equally difficult to comprehend. The fact that a map() function tells you that you're converting elements of lists does not save you from understanding what is that conversion doing and why.

Sometimes loops will be better for readability, sometimes it will be map/reduce. Saying that for loops always make it harder to reason about the code does not make too much sense in my opinion.

Loops are easier to read. With functions like reduce you have to solve a puzzle every time to understand what the code is doing (this is also true for functional style of programming in general).

> More specifically, maps can be trivially parallelized; same for folds, but to a lesser degree, if the reducing operation is associative; and for-loops are hard.

In a typical Javascript code reduce operation will not be parallelized. It actually can be slower than a loop because of overhead for creating and calling a function on every iteration.

> when you look at the system as a whole lots of for loops

A code with lot of loops is still more readable than a code with lots of nested reduces.

I find that many times in more complex loops you need the index as well. Sometimes for as mundane reason as logging.

> I wonder how fast it'd be to convert to string and count digits.

When you convert the number to a string you're really transforming it to a decimal format. Which is the domain where you should be solving the problem. Otherwise you're doing some sort transformation in the binary domain and then hopping to pull the answer out of a hat when you do the final convertion to decimal.

Many architectures? What would they be?

Regardless whether they contain a logarithm instruction or not, how may architectures are there these days. Outside of truly embedded computing I can only come up with 2: Intel and ARM. Counting POWER and RISCV is probably a bit of a stretch already.

Both ?: and if-else have cases where they can be compiled into cmov type instructions and where they cannot. Given int max(int a, int b) { if (a > b) return a; else return b; }, a decent compiler for X86 will avoid conditional branches even though ?: wasn't used. Given int f(int x) { return x ? g() : h(); }, avoiding conditional branches is more costly than just using them, even though ?: was used.

> This isn't true, this form of conditionals can be compiled into cmov type of instructions, which is faster than regular jump if condition.

IIRC cmov is actually quite slow. It's just faster than an unpredictable branch. Most branches have predictability so you generally don't want a cmov.

Speaking of which, a couple questions regarding this for anyone who might know:

1. Can you disable cmov on x64 on any compiler? How?

2. Why is cmov so slow? Does it kill register renaming or something like that?

If the if/else is simple the compiler should be able to optimize that anyway.

I still wouldn't consider it a bug since we are throwing lots of lsbs anyways. It matters even less when we are talking about Peta/Exa bytes.