Future of string lambda functions/string predicate functions

[bearophile]

Jakob Ovrum:

>> My opinion is that lambdas are more clean, and I usually 
>> prefer them, but in certain situations I prefer string lambdas.
>
> I think those few situations should forego string lambdas in 
> favour of reduced cognitive load and increased consistency.

In Scala they sometimes use lambdas where arguments are 
underscores 
(http://stackoverflow.com/questions/7673545/usage-of-in-scala-lambda-functions 
).

It's not good to give names to lambda arguments every time. In a 
program it's useful to give names to variables to make them more 
readable, but if you look at Haskell code you see several 
variable names like "a", "b", etc. They use such variable names 
not because they are lazy people, but because you are writing a 
very generic function, and very short names are good to remind 
you they are not important for their semantics, but for other 
things, like their position.

Using default names as 'a' and 'b' for very simple lambdas is 
nice. And "(a, b) => a > b)" doesn't give more information than 
"q{a > b}".

In functional-style code it's important to have means, when you 
desire it, to write compact code.

So I'd like to keep the string lambdas.

Bye,
bearophile