4 ms·

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 idiomat

by boxed 2y ago

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 2y ago
"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.
watwut 2y ago
I think that was the point - the library added nothing, the same thing could be done with pure javascript.
- boxed 2y ago
  If that was the point, then that paragraph needs to be rewritten badly.
  - nuancebydefault 2y ago
    In fact the paragraph needs _good_ refactoring
  - ahoka 2y ago
    It was quite obvious to me.
carlmr 2y ago
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 2y ago
  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.

by boxed 2y ago

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 2y ago

"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.

watwut 2y ago

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

boxed 2y ago
If that was the point, then that paragraph needs to be rewritten badly.
- nuancebydefault 2y ago
  In fact the paragraph needs _good_ refactoring
- ahoka 2y ago
  It was quite obvious to me.

carlmr 2y ago

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 2y ago
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.