[ggm]

Good refactoring respects the idioms of the language and the culture of the organisation. Change to new methodology is thoughtful and probably slow, except when a revolution happens but then, its still respectful to the new culture.

Bad refactoring is elitist, "you won't understand this" commented and the owner walks with nobody left behind who understands it.

That the examples deprecated FP and preferred an idiom natural to Java(script) only speaks to the principle. I can imagine a quant-shop in a bank re-factoring to pure Haskell, out of somthing else, and being entirely happy that its FP respecting.

So the surface "FP patterns are bad" is a bit light-on. The point was, nobody else in that specific group could really be expected to maintain them unless they were part of the culture.

"If you unroll loops a la duff's device, you should explain why you're doing it" would be another example.

[boxed]

The dig against FP is weird since the "good refactor" also uses FP, just a built in one in JS. Which I agree is better, but mostly by being built in and idiomatic, it's still exactly as functional.

[ggm]

"I don't like this style of FP coding" ok: if you run the group and own the codebase you can enforce that. So good refactoring is style guide enforcement.

I think I over-read his dislike of FP. really the complaint is "why did you introduce a new dependency" which I am totally fine with, as a complaint. Thats not cool.

Many of his examples kind-of bury the lede. If he had tried to write an abstract up front, I think "dont code FP" wouldn't have been in it. "use the methods in the language like .filter and .map" might be.

[carlmr]

On point. Even then mentioning it used filter and map. But the bad refactor also uses filter and map. It's the exact same change of programming paradigm.

Given the text, I would have expected some minor refactor with range-based for loops (are these a thing? My JS is rusty). Where you get the advantage of map (no off-by-one indexing errors) without changing the programming paradigm.

[bobthepanda]

you don't even need range loops.

you have forEach:

   list.forEach((item, index) => doSomething());

you also have for/of, though that doesn't have an index if you need that

   for (const item of list) { doSomething() };

which just obviates the need for index incrementing in the most common case, where you are incrementing by one until you hit the end of the list.

[watwut]

I think that was the point - the library added nothing, the same thing could be done with pure javascript.

[boxed]

If that was the point, then that paragraph needs to be rewritten badly.

[nuancebydefault]

In fact the paragraph needs _good_ refactoring

[ahoka]

It was quite obvious to me.

[achillesheels]

>Good refactoring respects the idioms of the language and the culture of the organisation. Change to new methodology is thoughtful and probably slow, except when a revolution happens but then, its still respectful to the new culture.

Burkean programming lol