filter and reduce are much better readable as the gatherUntil function.
Because in this particular case gatherUntil is just as utilitarian as filter and reduce - which still focuses more on the "how" rather than the "why" - declarative or not. Ideally the functions "descriptive and meaningful names" should be more DSL-like, focusing more on the "why" than the "how".
when was the last time you had performance issue and thought: 'maybe its because of THIS type of loop' in JS?
Whenever I start to play around with performance comparisons (example based on this) the good 'ol for…loop seems to perform consistently well across multiple JavaScript engines - while the "other" ways tend to be all over the place.
But you write more code and more code means more bugs.
No Code, no bugs. Other than that studies typically focus on total application length when they state "larger code bases contain more bugs" - but complex applications would be expected to be a.) larger and b.) be more prone to bugs. That doesn't necessarily imply down at the lower level that 1 line is always better than 5 unless this is systemic across the entire code base leading to a significantly larger application. Code Golf emphasizes brevity but tends to lead to code that isn't easy to understand. If there is something to "Code inspection is up to 20 times more efficient than testing" then making code understandable to the broadest possible audience of reviewers is important (within reason - because … trade-offs). Even in A Large-Scale Study of Programming Languages and Code Quality in Github:
However, we caution the reader that even these modest effects might quite possibly be due to other, intangible process factors, for example, the preference of certain personality types for functional, static languages that disallow type confusion.
i.e. as always … it's complicated.
Another argument against "more lines" is that more lines take more time to parse. But not all lines of code are created equal - what matters is the actual workload on the interpreter/compiler during runtime after the parse.
There is not much space to have a bug here.
You did notice that people here expressed surprise about forEach, filter, and reduce skipping holes? Given that processing tends to need to skip undefined values there often isn't a problem - until undefined values and/or the difference between an undefined value and a hole becomes significant. So even on a single line there is space for bugs if code authors/reviewers have an incorrect conceptual model.
Only because something is faster makes it not better for programming, then you wouldn't write JS in first place.
Back in 2009 the video game industry started to abandon OO programming for Data-Oriented Design because OOP imposed too much overhead on commodity hardware. Back then this was largely applied to games written in C/C++ but the trend has lead Unity to adopt DOTS (Data-Oriented Tech Stack) for .NET/C#. Data-Oriented Design aims to optimize for the platform rather than developer experience (ECS - again it's a trade-off).
Similarly I'm imagining JS as running on the shittiest phone out there (on the back end you have other options right?) - the whole Responsible JavaScript thing.
Alex Russell
@slightlylate
You didn't ask for 5000 words on the state of devices, networks, and browsers circa '21 (including 7 blog-length footnotes) -- or the implications of JS-first stacks on the web ecosystem -- but here it is:
I prefer a more "functional" style of doing things.
Sure, but at its core JavaScript is imperative and not as effective at appropriating functional practices as Rust. Most fundamentally it doesn't have "immutability by default" through core-supported, optimized persistent data structures - so mutability is par of the course and it falls to the author to use it responsibly and effectively. I view JavaScript as function-oriented.
And would recursion not be so slow in JS I would do that.
"Slowness" of recursion in JS would be due the "overhead" of the repeated function invocations. You don't seem to be too concerned about the repeated invocations of the functions that are passed to reduce, map, filter etc. (something that could be addressed by putting the logic into a loop body; on the other hand inlining can be tricky). Bounded recursion is doable but simply not optimized for as the for…loop is the most basic (and performant) mode of iteration in JS.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
Because in this particular case
gatherUntilis just as utilitarian asfilterandreduce- which still focuses more on the "how" rather than the "why" - declarative or not. Ideally the functions "descriptive and meaningful names" should be more DSL-like, focusing more on the "why" than the "how".Whenever I start to play around with performance comparisons (example based on this) the good 'ol
for…loopseems to perform consistently well across multiple JavaScript engines - while the "other" ways tend to be all over the place.No Code, no bugs. Other than that studies typically focus on total application length when they state "larger code bases contain more bugs" - but complex applications would be expected to be a.) larger and b.) be more prone to bugs. That doesn't necessarily imply down at the lower level that 1 line is always better than 5 unless this is systemic across the entire code base leading to a significantly larger application. Code Golf emphasizes brevity but tends to lead to code that isn't easy to understand. If there is something to "Code inspection is up to 20 times more efficient than testing" then making code understandable to the broadest possible audience of reviewers is important (within reason - because … trade-offs). Even in A Large-Scale Study of Programming Languages and Code Quality in Github:
i.e. as always … it's complicated.
Another argument against "more lines" is that more lines take more time to parse. But not all lines of code are created equal - what matters is the actual workload on the interpreter/compiler during runtime after the parse.
You did notice that people here expressed surprise about
forEach,filter, andreduceskipping holes? Given that processing tends to need to skipundefinedvalues there often isn't a problem - untilundefinedvalues and/or the difference between anundefinedvalue and a hole becomes significant. So even on a single line there is space for bugs if code authors/reviewers have an incorrect conceptual model.Back in 2009 the video game industry started to abandon OO programming for Data-Oriented Design because OOP imposed too much overhead on commodity hardware. Back then this was largely applied to games written in C/C++ but the trend has lead Unity to adopt DOTS (Data-Oriented Tech Stack) for .NET/C#. Data-Oriented Design aims to optimize for the platform rather than developer experience (ECS - again it's a trade-off).
Similarly I'm imagining JS as running on the shittiest phone out there (on the back end you have other options right?) - the whole Responsible JavaScript thing.
The web is still the most hostile development platform in the world even more so for hyper-constrained devices (Techniques to make a web app load fast,, Setting up a static render in 30 minutes). That level of effort is a far cry from "press of a button, comfy chair development".
Sure, but at its core JavaScript is imperative and not as effective at appropriating functional practices as Rust. Most fundamentally it doesn't have "immutability by default" through core-supported, optimized persistent data structures - so mutability is par of the course and it falls to the author to use it responsibly and effectively. I view JavaScript as function-oriented.
"Slowness" of recursion in JS would be due the "overhead" of the repeated function invocations. You don't seem to be too concerned about the repeated invocations of the functions that are passed to
reduce,map,filteretc. (something that could be addressed by putting the logic into a loop body; on the other hand inlining can be tricky). Bounded recursion is doable but simply not optimized for as thefor…loopis the most basic (and performant) mode of iteration in JS.