Let's take a look at the arguments presented here. > Code that mutates (changes) a variable is harder to reason about, and so easier to get wrong. This is tru

Let's take a look at the arguments presented here. > Code that mutates (changes) a variable is harder to reason about, and so easier to get wrong. This is true when the mutation is "off the page" - in some other scope - but there is no mutation going on in this example that is hard to understand. > An explicit 'for' loop is another common source of bugs. The C-style 'for', where one manipulates a control variable which nominally denotes those elements of a set which one is concerned with, is very prone to error because of this indirection, but both versions of this code do this! > The original snippet is longer because it’s doing boring, low-level work. More, boring, code is another source of bugs. Maybe, but it is not demonstrated here. 'Boring' is an odd adjective here: how often have you seen the source code for a complete application, let alone anything larger, that you just can't put down? real-world code is about as exciting as a balance sheet, and for good reason. > Long code with low-level operations like for loops and pushing values onto arrays is not expressive. Expressiveness might be a feature of a language, but it is not something programs inherit merely by being written in a particular language. Programs are not poetry, and what we want from them is clarity. Expressiveness may help with that, but this example does not demonstrate it (maybe the author should have given us an example in APL?) > The shorter, functional version has no variables, no mutation, and no explicit looping. It’s much shorter and easy to understand, once you’ve seen this style. More of the same, with a touch of the Emperor's New Clothes thrown in to suggest that if we do not get it, we are just not sophisticated enough to understand. Don't get me wrong: mutation is the cause of a lot of problems, and I would prefer for procedural languages to have variables const/immutable by default, but this sort of article just does not make the case. There must be several thousand articles like this written every year, all pretty much the same, with the author never asking whether their example actually makes the case they are claiming (I would guess because they are so convinced that they are right, they don't ask the question, and the existence of so many prior articles of the same sort (which they are effectively plagiarising) makes it seem obvious.) To be fair, a decade ago I was in complete agreement with the precursors to this article.