Well right, but what I'm saying is that the people who actually use the language are the kind of people who like the operators. I know Latin, and a language whose functions were named in Latin would not be a practical impediment to me, but I wouldn't say that such a language would be practical in general. Haskell's operators aren't on that level, but I do think if you introduced it in a company where people were hired to write Python/Ruby/C/whatever, there'd be people who found them a practical problem.
Again, whether or not people like the operators is irrelevant. Aesthetic opinions about syntax don't have a material effect on productivity. As I said, there are people using the language professionally who have an aesthetic distaste for the use of operators in, e.g., the lens library (i.e. your purported selection effect is empirically false). Those people will still admit that this has little practical effect, and certainly not enough to make a language choice based on it.
If there were a language written in Latin, and it was useful for some reason, people would quickly write aliases for all the Latin functions, named in English. This is very easy to do in Haskell: if your argument held, you would expect to see aliases for all of the operators. With a few exceptions (again, lens), this isn't the case.
You're choosing where to live based on the color of the neighbor's bikeshed, against evidence from previous tenants that the current color is quite pleasant.
It's not about liking, it's about looking at a piece of code and going and going "I understand all that" vs "What does all these signs and single-letter variables mean?". Naming matters.
Yes, it's very important that people who work in the language be able to read and understand it easily. It is not, however, important that people who do not work in the language be able to do so. The most persistent critique of Haskell is that it is hard to understand for people who haven't learned it. This is as reasonable as critiquing Java because it is hard to understand for people who do not know how to program. You're welcome to claim that Haskell has a larger barrier to entry, but that is a fundamentally different claim from the claim that operators make the language harder to read for practitioners. I have been attempting to refute the latter claim, using my experience discussing the issue with said practitioners. If you want to discuss the former claim, I'm happy to do that as well, but you have to acknowledge that it is a separate claim and be clear about what it is you actually mean.
>Yes, it's very important that people who work in the language be able to read and understand it easily. It is not, however, important that people who do not work in the language be able to do so.
Well, I guess we disagree there. And remember that some people may only work a little bit in a language, and it matters, to them, how much time they need to get into the groove with a language. Once you work enough in a language you get used to all the weirdness anyway, which is how you end up with people claiming C++ and PHP are actually kinda neat languages. The only good judges of language syntax are people who have never seen that syntax before.
I think the exact opposite: the only good judges of syntax are people who understand the semantics deeply enough to understand whether the syntax accurately reflects them.
It's all well and good to say that people should be able to bounce around between languages within a paradigm. A Rubyist should be able to read Python, Perl, and PHP, sure. A Java programmer should be able to read C++ and C#. Claiming that people should be able to read any programming language, though, means that languages aren't allowed to explore significantly different semantics. A JavaScript programmer isn't going to be able to pick up something written in Prolog or Forth and quickly understand exactly what's going on, and that's as it should be. The whole point of having multiple paradigms is that they can express different ideas and ways of approaching problems.
So, I agree that an SML or OCaml programmer should be able to "get into the groove" with Haskell quickly. In my experience, this is usually the case.
It's not just syntax. If the semantics and design patterns are different, then no matter if you call it (>>=) or bind, you won't be any closer to understanding the code; this is the "people who do not work in the language" part.
Would you expect to understand Forth or other concatenative languages even if all the operators are named?
The new set of semantics and patterns are the part that take time to understand. The syntax is not really the actual stumbling block.
