In day2, the author refactored some "old-school" code[1], I'd say I prefer the old-school version (the new version is less readable to me). Old-school is not out-dated nor in-correct IMO.
The `times` solution was overhtought, and later I get rid of it. In the end, the code of cycle like this are handled with `range`, for example:
var points = range(resolution).map(
i => ({x, y: y - (i * height) / resolution})
)
The point of the rewriting `for()` cycles is not some abstract "making them new and shiny", but expose _meaning_ (in a way that would be obvious for _my reading habits_). Generally speaking, `for()` is "how we do" instead of "what we are doing". It might mean a lot of things; porting it into `map`, or `filter`, or `zip`, etc. allows to review and rethink what was the point of iteration.
As you might see in the final code[1] the initial "cycle of noise generation" you are pointint to was gone at all (because several iterations of "making it one phrase" made it obvious that it has no context of its own, and should just be embedded in a points generation).
With that being said, I explicitly stated many times throughout the diary I don't expect the approach to be for everyones liking.
In day2, the author refactored some "old-school" code[1], I'd say I prefer the old-school version (the new version is less readable to me). Old-school is not out-dated nor in-correct IMO.
[1] https://ibb.co/C0cYbdt