Or... gulp... Haskell, which has your line noise and in addition significant white space syntax.
I would suggest that is obviously false. Most languages have operators. Is 4+5 really less readable than plus(4,5)? Haskell does not have very many operators. The fact that people see 3 operators they are not familiar with and decide "this is unreadable because of so many operators" speaks rather poorly of people's desire to learn.
NB: I know a little German, and almost no Haskell.
In fairness, there are good ways to search the documentation for those operators so at least you aren't stuck googling for line noise.
Bind a function which gets the contents of my system tmp directory to a function which takes anything and returns a monad, then return the evaluated monadic result.
Haskell doesn't really have that many operators built-in (that is, in the standard Prelude). Haskell is completely open to user-defined operators (whose names can either be alphanumeric or symbolic), which, combined with the fact that symbolic operators often are attempt to approximate symbols from the application domain in ASCII while avoiding duplication of symbols used in the prelude even if those in the application domain are the same as those used in the prelude often results in less-than-intuitive choices.
Whether this is more or less readable than alternatives, though, is pretty subjective -- operators are generally used to reduce visual complexity in a way which is (given the constraints discussed above) as familiar as practical given the notation used in the domain, so even with the problems introduced by those constraints I think it often results in code that is at least as readable, and often more, than the cumbersome structures that are the alternative in languages that don't support user-defined operators.
Or to phrase it another way, typical code prefers good names over lengthy names. See, having a preference is fine. But acting like your preference is objectively correct is not.
Since that didn't work, I'll be more explicit: in my opinion, an unfamiliar operator is usually both a terse and a bad name.
My argument is that I believe using descriptive words, even if they are longer, usually makes concepts easier to understand while reading than using either terser words that are less descriptive or symbols that are not in common use. That's not fact, but it's different than just saying "I don't like X".
The problem with your new argument is that it is just rephrasing "if I don't learn X, I don't understand X". The operators commonly used in haskell are in common use, by definition. Haskell is not unreadable just because you didn't learn how to read it. No, basic_arithmetic_addition_function is not clearer than +. So why would needlessly_long_name_that_conveys_no_extra_information be clearer than >>=?
Operators in common usage, like ">>=", are not at all a problem, because as you suggest, they only need to be learned once and aren't easily forgotten. Operators that are never used are also not a problem, because they are never used.
But I do see a problem in the middle, where I see an operator, figure out what it does, and then don't see it again for some time. Re-learning less frequently used operators constantly is not very efficient.
Your fake names are a false choice. The trick is to find good descriptive names, and using a name that is annoyingly long is probably worse than using one that is frustratingly terse. The trick is to pick a good one.
You could also say:
> Re-learning less frequently used command line programs constantly is not very efficient.
However in my experience re-learning is much easier than learning the first time. For instance if I've used a command line program before I can glance at the manual and figure out what I need very quickly.
Terse code is useful for domain experts, it allows them to quickly assess what's happening without having to read a lot, and have more of the program logic in the field of view at a time. Unfortunately it's hard for beginners to understand because a lot is implied through idiomatic usage.
Verbose code is easier for beginners, but domain experts may find it cumbersome and a chore to both read and write.
Perl has found an interesting spot on this spectrum, as through TIMTOWTDI it has the capacity for verbose code, as well as terse, idiomatic code. I'm not sure if that means it's optimized for intermediate level users, or if it's just schizophrenic.
Yes, they are certainly hyperbolic. But the idea was to make the point that longer is not better. If a variable has a short scope, you do not need to constantly be reminded what it is. If a variable is very general, a very general name is fine. Generally haskellers consider names like 's' and 'x' and 'i' to be very good names. Code is generally optimized for being read by people who know the language, not by people who are unfamiliar with it.
I found myself wondering what the point of using "s" and "z" instead of "succ" and "zero" could possibly be, besides some sort of mathematical bravado.