[delta_p_delta_x]

Perhaps the snark caused the down-votes, but your point is legitimate. 'Pure FP' languages encourage code that is nearly unreadable and unparseable without any additional context (and sometimes, unreadable even with said context). There is some strange desperation for extreme terseness in pure FP languages like Haskell, Ocaml, Idris, etc.

Single-character variables and functions, point-free style... Coming from an imperative background, this just seems like flexing for the sake of flexing.

Why not make life a little easier by clearly naming variables? This isn't maths or physics where variables (for some equally-inane reason) must be one character. We have 4K screens today; I can accept lines that are significantly longer than 80 chars.

[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

[c-cube]

Fwiw, OCaml doesn't chase extreme terseness or point-free programming. It's not really equipped for that.

OCaml is designed for straightforward code centered on functions, modules, and a mix of imperative and immutable data structures; all with a _really_ simple execution model and a pretty nice type system. The core language has very few quirks and it's easy to predict what it does, and how efficiently.

There's not really any comparison with Haskell, which emphasizes heavy optimizations to make its terseness, based on lazy evaluation, work well in practice.

[BigJono]

There's nothing wrong with single character variables if you're not using them like a complete idiot. A line like reports.map(r => whatever) makes it blatantly obvious that r is a report.

[somebody1234]

there is zero desperation for extreme terseness in ocaml.

some very obvious examples:

- many, if not most, functions have sensible names instead of abnormally terse ones

- it's possible to make named parameters mandatory, and many do that - e.g. the base library