Hate to break it to you but I see "reduce" as a bad smell. Not like it doesn't have good uses but I've often seen people use it in ways that were wrong in subtle ways. Maps and filters are usually clear to me, reduces not always.
In quite a few languages also I've seen that "map", "filter", "reduce" and constructions like that are often slower than ordinary loops.
rham · 12h ago
I mean I think that's fine, especially if that extra performance makes an impact on your ability to achieve your business goals/priorities. The takeaway I'm aiming for here isn't necessarily that declarative code is always better than imperative or vice versa, but that simple code should be deeply intentional, not just explicitly rudimentary- and that Engineers shooting for the top of the salary range should not only understand the trade-offs but should be sharing that understanding with their peers rather than relying on tribalistic hot takes for the sake of driving engagement.
To that end, I'm working on a follow-up where I dive into the difference between complex vs complicated code, and how/when to spread complexity strategically to achieve more sophisticated forms of simplicity at scale. If you're interested, let me know and I'll give you early access.
Thanks for taking the time to read my content and leave feedback!
In quite a few languages also I've seen that "map", "filter", "reduce" and constructions like that are often slower than ordinary loops.
To that end, I'm working on a follow-up where I dive into the difference between complex vs complicated code, and how/when to spread complexity strategically to achieve more sophisticated forms of simplicity at scale. If you're interested, let me know and I'll give you early access.
Thanks for taking the time to read my content and leave feedback!