sort(items, key=lambda x: x.size)
but really anything much bigger should have a name stamped on it dammit. I find JS largely unintelligible due to lambda overuse and nesting. sort(items, key=lambda x: x.size)
but really anything much bigger should have a name stamped on it dammit. I find JS largely unintelligible due to lambda overuse and nesting.seems you're confused between "limitation" and "feature"...
it's a limitation due to python's "no-braces/indentations-only" policy -- can't think of a way to mark where a lambda starts and ends clearly and cleanly with indentation-only...
Python prefers different tools (comprehensions) to accomplish most of the same goals.
In Rust it's difficult to mess with memory: it's a limitation but also a feature. In Haskell you cannot mutate, a limitation if there ever was one, but also a feature.
for rust, it counts as a 'feature' because it provides safety guarantee, and they're opt-in (can use unsafe)
as for haskell, that immutability also provides guarantee of 'referential-transparency', which the users/libraries can use to their advantange.
But in python's case, you have to define the multi-line function *outside* the chaining, and 'forcing to name things' isn't always good (especially for constantly-changing code)
def hideEmail(user): return { ...user, email: user.hideEmail? '': user.email, }
users.map(hideEmail)
// later: def hideEmailAndPhone(user): return { ...user, email: user.hideEmail? '': user.email, phoneNo: ... // same stuff }
users.map(hideEmailAndPhone) ---
As for JS/TS, you can have 'named-callback-fn':
users.map(function hidePrivateFields(user) { ... })
and it's not difficult to come up with 'named-lambda-fn' standard
users.map(hidePrivateFields(user) => { ... })