This kind of thing is always a balancing act. There's the argument that implementation details should be hidden, therefore separate named functions should be d

This kind of thing is always a balancing act. There's the argument that implementation details should be hidden, therefore separate named functions should be defined and their behaviour should be clear from the name. In my experience, those who go too far in this direction may not be used to first class functions; for example, I worked on a PHP project which dated way before the addition of closures, and even their JS had no lambdas: all functions, even trivial one-liners which were only used once, were given top-level, globally-scoped names, defined all together in a separate file. There's the argument that each expression shouldn't do too much, hence pulling a lambda out into a (locally scoped) name. There's the argument that variables which are only used once should be written inline to avoid the mental cost of indirection. There's the argument that values should have the tightest possible scope. There's the argument that common 'utility functions' should be pulled out to a separate place. In situations like this, I usually favour doing the 'real work' in a locally scoped function, and writing the argument-plumbing inline. That lies somewhere in between the author's "labelled_lambda" (tightly scoped definitions, but conflates processing with argument juggling) and "isolated_functions" (separates processing from argument juggling, but has a wider scope). PS: Having only dabbled in Erlang, to me the real problem exposed by those examples is the lack of a combined lambda/case, e.g. as (eventually) found in Haskell https://unknownparallel.wordpress.com/2012/07/09/the-long-and-epic-journey-of-lambdacase-2/ https://unknownparallel.wordpress.com/2012/07/09/the-long-an...