That's a neat little implementation. For bonus points, try adding these features:<p>1. More non-commutative operations, like Ruby's each_cons, each_slice, chunk (different than lodash's chunk). I especially enjoy implementing these both iteratively and recursively.<p>2. Infinite sequences (like Python's itertools.count). You may find that implementing the other operations becomes easier when you treat the sequences themselves as being lazy and potentially infinite. Do you still need to make the distinction between commutative and non-commutative operations?<p>3. Operations that combine multiple sequences, like iterools.zip, itertools.product, and merge (assuming sorted sequences).<p>4. Operations that <i>return</i> multiple sequences (say, a sequence of sequences). Can you implement the inverse of itertools.zip (perhaps call it unzip)?
In the article when comparing the native vs lodash implementation the native one is given as:<p>persons
.map(p => ({ ...p, age: p.age + 1 }))
.filter(p => p.age >= 30)
.slice(0, 5);<p>^ But this is intentionally(?) unoptimized. You would instead put the filter and slice first, i.e.<p>person.filter(p => p.age >= 29)
.slice(0,5)
.map(p => ({...p, age: p.age + 1})
Comparisons of lodash to native methods are interesting but they always miss the real selling points of lodash in my opinion, which are the richer data structure manipulations like groupBy, partition, intersection, difference, union, etc.
Good article detailing a particularly high-value part of Lodash.<p>I tend to be highly critical of the library overall:<p>- It takes most of its inspiration from functional programming, but sometimes surprises with unexpected mutation.<p>- Surprises of that kind are especially likely to be missed, because the API is quite large, and because (as the article author mentions) it provides a lot of shorthand functionality/magic behavior that one might not expect… especially combined.<p>- FP patterns like composition and currying are unnecessarily ergonomically difficult, because argument order is wrong throughout most of the API; the lodash/fp module mostly addresses this, but it’s not in wide use by a lot of projects heavily dependent on Lodash.<p>- Where composition is accounted for, it tends to exacerbate surprises caused by magic behavior.<p>All of that said, the laziness of chain is one bright spot that (afaik) is pretty faithful to FP expectations, notwithstanding those other issues. And while I’m not personally a fan of “fluent” APIs and chaining syntax, with laziness it’s not hard to squint and see it as roughly analogous to a threading macro/pipe operator.<p>IMO there are better-overall FP libraries in the ecosystem, but they tend to feel very unidiomatic. E.g. dropping in Haskell-like semantics and names that are likely unfamiliar to JS/TS devs who would nonetheless be familiar with similar equivalents in the ecosystem.<p>These days I mostly treat Lodash as YAGNI, and very seldom install or import it unless there’s a strong team preference. But I think, given its prevalence, I’d like to see a fresh “Lodash done right” which:<p>- Exports functions rather than a namespace (ESM and tree-shaking friendly, encourages use and composition of plain functions)<p>- Adopts either the native-equivalent name (if available) or the familiar Lodash name for functions (with convenience aliases if desired, but ideally isolated in some compat module)<p>- Places arguments in an order one would expect coming from the equivalent implementation in a FP language (collection first, operator/parameter after) to encourage composition<p>- Eliminates all implicit magic (missing arguments are treated as a mistake; null is a value)<p>- Provides/expects lightweight data types for explicit magic (eg `path('foo.bar')` is better and safer than 'foo.bar')<p>- Embraces evolution of the language/platform, deferring to native implementations as they’re available/introduced<p>- Engaged with the standardization process to coordinate and advocate for the principles and benefits of FP functionality<p>… and all of that’s a lot to ask. Certainly beyond my bandwidth alone. But I’d be happy to collaborate if other folks want to see it happen :)