3 ms·
I don't really see it as an FP thing at all, because the same argument can be made with respect to variable names. The issue is that without serious anonymous f
by KingMob 9y ago
I don't really see it as an FP thing at all, because the same argument can be made with respect to variable names. The issue is that without serious anonymous functions, you're forced to come up with more names, increasing cognitive load. An anonymous fn clearly communicates "I'm not going to be used elsewhere".
- xapata 9y agoSo call it something generic related to usage: keyfunc, repeat, parse, callback, etc.
- KirinDave 9y agoWhy increase the complexity and density of the code while complaining that the alternative would be too complex though? If I can simulate anonymous functions with locally scoped functions that then behave as lambdas then what hill is Python dying on here? The "we don't want to submit a patch to make our parser do this?" Hill? It's definitely possible to do. So...
- pseudalopex 9y agoThe small increase in cognitive load when writing the code pays off when reading it. My editor can tell me where a function is used. It can't tell me what a function does.
- xapata 9y agoAnd with anonymous functions, your traceback often hasn't a clue where the function was defined.
- KirinDave 9y agoThat's untrue. That's usually the least interesting part of the stack trace, but the easiest to compute. But your complaint isn't without merit here, a profusion of unique nameless verbs can get overbearing sometimes. It's often better than the alternatives (e.g., dependency injection vs lambdas in an environment) but Haskell, ocaml and lisps all seek to have a small but very robust set of combiner and base primitives to help make this kind of code avoid a complexity explosion similar to OO ontology explosions.