Maybe it's also time to loosen the 80char limit a little bit, screen resolutions have advanced dramatically and large screens are commonplace.

I'm not a fan of sacrificing readability for some arbitrary screen-width limitation.

Going up to 100 or 120 is already sufficient

Contrariwise, I try to keep my code under 72 columns wide, and impose a hard limit at 80. Long lines are hard to read, no matter what screen they're on.

You'd need to make a case of which value, and why, and why it is better, so that the terminals can standardize on it.

I actually like the limitation, because it makes me use more enters, so that the information ends up not within one line but in multiple. Which mans more lines (and LOC) but better readability.

I guess a good comparison is Twitter's limitation on the characters. It has its pros and cons.

Point taken that it is ok to use i, x, y, z sometimes (eg. when iterating), but the notion 'a meaningless parameter that is just a variable' doesn't really exist... if it's meaningless, why are you saving it?

Only other use case I can think of is doing metaprogramming or some sort of templating where you have a variable, but might no even know what it represents, because it isn't your concern.

What about implementing something like map for lists? You know literally nothing about the values and the function except for their types.

    map :: (a -> b) -> [a] -> [b]
    map f [] = []
    map f (a:as) = f a : map f as

Personally I don't see any reason to use longer names than f, a, and as because you can't add any additional information.

You might say "well I don't write code like that", and I don't have any answer for you. But I find I write a fair amount of generic code.

> you can't add any additional information

Well you could...

    map transforming_function (element:rest_of_list) = transforming_function element : map transforming_function rest_of_list

...but the cost in terms of loss of brevity would far outweigh a benefit that would only accrue to complete beginners, who would be better served by comments and test cases.

> if it's meaningless, why are you saving it?

Because you are writing abstract code.

Odds are that a lot of your code is better done abstract, and only fully specified in a short context.

A variable can be a substitute for a longer expression for which a name/description is unnecessary because the expression itself is self-explanatory. The substitution with a (essentially meaningless) short name just makes repeated use of that expression more readable. Using a long, descriptive name would defeat the point.