What were FP wrappers and what was the fad?
No, I just keep pointing back to the idea that there should be one obvious way to do "it," whatever it is you need. As people vote for their favorite whatever from another language, the number of options of how to do something increases, drastically. The reason for a "language of mostly idioms" (maybe not to "Shaka, when the walls fell" level) is that we must read and maintain our code.
I am a Perl refugee. It had the opposite philosophy: many ways to skin a cat. The result was a write-once, read-only-in-abject-terror language. You never knew if someone decided it was Code Golf Day and they wanted to try to cram in a dozen things into a single string of executable line noise.
I think Python is (slowly) abandoning some of the PEP 20 precepts one hardly-objectionable feature at a time.
If you won't say what you're talking about then please stop commenting here.
Any single feature recently added would find an advocate and a defender. Therefore, selecting one of the bunch is a mistake because it does not focus on the actual problem: the pack of features, plural, getting added in.
It is like someone dumping a ton of sand in your driveway. "Surely you cannot object to this grain of sand. Or that one. Or this one over here." The problem is in the aggregate.
Basically flipping around the args in a function and returning a "curried" function call. So instead of
_.map(["1"], parseInt)
_.map(parseInt, ["1"])
const parseArrayFunc = _.map(parseInt)
const parsed = parseArrayFunc(["1"])
In software though, it just seems like code golf for people who can’t or won’t write a function as a way of sharing code between call sites:
def serialize(fn, data, path):
…
yamlize = partial(
serialize,
yaml.dump
)
jsonize = partial(
serialize,
json.dumps
)
def serialize(fn, data, path):
…
a = lambda f: partial(serialize, f)
yamlize = a(yaml.dump)
jsonize = a(json.dumps)
def write(data, path):
…
def write_yaml(data, path):
write(yaml.dump(data), path)
def write_json(data, path):
write(json.dumps(data), path)A curried function is like a partial application for each argument. If mul:=(a,b)=>a*b then currying would be being able to say double:=mul(2). Currying everything and requiring all function calls to have one parameter per call — six:=mul(2)(3) — might have some benefit in avoiding bugs.
Generally speaking though my hunch is that the lodash author grew tired of the project’s focus on meta programming: noodling around with JavaScript using programming paradigms that hinder rather than help its users. Dropping the noodling and focusing on features is a “back to basics” moment, if you will.
They looked like write-only code to me and at high-risk of assaulting the GC (aka slower than lodash).