[toastal]

When your code is sufficiently abstract, there often really aren't better variable names than a or x. My experience is that it's about the scope for that variable. If it's in a one-line lambda, then it'll be one letter. If it is going to be used in the next 10 lines or so, make an abbreviator. And it's longer, or particular unclear, spell it all out. Adding extra words don't make BusinessAbstractFactoryIBuilder more readable.

[delta_p_delta_x]

> BusinessAbstractFactoryIBuilder

While I understand and agree with this meme[1], I think that's the other extreme, where everything is a Factory Builder thing.

Even so, I would rather too much information than too little, which is what FP programs tend to do. Over-abstraction is also a problem, in my view. Even in a LINQ lambda, for instance, I might write

  someEnumerable.Select(what_is_actually_inside => doSomething(what_is_actually_inside))

rather than

  someEnumerable.Select(x => doSomething(x))

[1]: https://github.com/EnterpriseQualityCoding/FizzBuzzEnterpris...

[toastal]

Funny example since currying requires no intermediate variable to speak of

    someEnumerable |> select doSomething

[somebody1234]

even funnier when you realize that doesn't even need to be curried so it also works in c#:

    someEnumerable.Select(doSomething)

to be fair, i guess doSomething was supposed to be an actual function body instead of a helper function from somewhere else