[platz]

I think the reason functional programmers like short, terse names is because they need to see the structure of the code more than the individual identifiers. More verbosity makes it hard to get a picture of whats going on locally. Pattern Matching and Recursion creates structures that are easier to understand if it fits on the screen.

[edgyswingset]

There's a happy middle ground there. At the call site is where it matters a lot more. If you have a function that's basically nothing but a pattern matching expression, the name of a parameter matters a lot less than the name of the input when you call that function. Same goes for what you name the result.

If you do this:

    let r = f x

Then you might be a fucker. But most good F# code I've seen is more reasonable:

    let res = getResult input 

Granted there's some exception, such as defining your own operators. F# does this itself, where "|>" is "let (|>) f g = g f". I don't think you gain much from adding verbosity to that.

[nv-vn]

In general, short names tend to be used for the most generic variables. Renaming "g" to "theFunction" in the (|>) one-liner doesn't really clear up anything. Just seeing it applied to something makes it clear enough that it's a function, etc. For something less generic the identifier can introduce the relevance of the variable better. But the thing about functional programming is that much of the code is written to be very generic, and so there's not much room to use longer names.

Also, another thing that I've noticed is that it becomes much easier to deal with short variable names in functional programming, because you know the value of the variable isn't about to change out of the blue. By restricting mutable state and side effects, it's possible to just substitute the values for variables wherever they exist. So for example,

    let r = getResult input
    let s = "abc" + r
    let t = doSomethingWith s
    printfn "%d" t

is known ahead of time to be exactly identical to

  "abc" + getResult input |> doSomethingWith |> printfn "%d"

Once you start introducing mutable state, something like that becomes a whole lot harder to read because you can never be sure if the values of those variables are changing, so you can't substitute in the declaration site.

[conceit]

Well, if you need to scroll to read the whole name, that's indicative of some deeper problems, alright. That's kind of what I was getting at, just that the code also needs to fit in my head. Use of verbose identifiers might be linked to verbose code and that might or might not be harder to follow. There is a sweet spot.

I am just defending that I don't know what car means mainly because I don't know LISP and I refuse to read documentation, but out of lazyness mind you.

On a related note, I often discover that trying to shorten text, sentences become a lot clearer when they are less verbose. Compare that to: On a related note, I often notice shorter sentences are clearer. Compare that to the overly terse Short Sentence Clarity!