I'm really hoping that functional languages will evolve in a way that they become more readable at a glance.
I don't find that really true; if you've used any structured language with static typing, there's a lot of carryover, especially if you've ever done any formal study of CS, since even when imperative languages are used functional patterns are pretty common.
The biggest problem I see is that there isn't a lot of pragmatic guidance on the bits that are unique to Haskell -- a lot of the documentation is very abstract, without a lot of guidance on solving specific real world problems. The power of Haskell is that you can make very general solutions in it quite easily; the weakness of the documentation of Haskell is that virtually all of it focusses on that highly general facilities and not enough on the kind of specifics that would help people get familiar with it while solving real problems.
Basically, people are trying to make Haskell code look like math and the truth is that math's symbolic notation is optimized for hand writing speed, /not/ reading comprehension.
Take a look at Ada code. Maybe they're taking it a bit far, but it's very readable. Spelling words out and being very very sparing with symbols is a very good thing, I think.
I doubt the majority of Haskell programmers would prefer a more verbose notation. I think that, like the parent post, they consider Haskell very clean and readable.
A friend of mine who is a proficient Haskeller told me he often struggles to understand new Haskell libraries. Then the library "clicks" for him and he can begin to use it. I -- who program in Java for my day job -- have trouble understanding this, because this is seldom the case for Java: you may not understand what problem a Java library is intended to solve, but using it is usually trivial (and mis-using it is trivial as well, of course!). I think it's unfair to compare both languages this way, because in Java there is a fairly low use of general abstractions, and Java's syntax (and coding practices) have evolved to reflect this. The verbose syntax that works (1) for Java is not suitable for other kinds of programming.
(1) for some values of "works".
I'm not a mathematician, but I heard that math is most frequently written on a whiteboard. If that's true, then optimizing for speed and space efficiency of hand-writing suddenly makes sense.
> I doubt the majority of Haskell programmers would prefer a more verbose notation
The exact same thing can be said about PERL programmers. But why stop there, take a look at APL, J, K languages. J, for example, ships with all standard verbs aliased to words, like "under", "behead", "curtail" etc. Of course, nobody uses those, they write "&.", "}.", "{." instead.
The difference is that in J you have small, consistent core vocabulary (http://www.jsoftware.com/help/dictionary/vocabul.htm), and once you learn it and it "clicks", you very much are ready to do anything with the language. Haskell way makes you go through the same process again and again with almost every library. The sad thing is that you could write Haskell in a way which wouldn't require you to internalize large numbers of new symbols, but you generally don't. Is it really because of how much better the abbreviated, symbol-based notation is so much better, I have to wonder.
But a lot of math is read from papers as opposed to written. Math and logic papers employ the concise notation we're talking about. You'd think mathematicians would have evolved a better notation for paper-writing if one was lacking (there being already many conventions and style guides that apply exclusively to paper writing and that are odd for everything else).
> The exact same thing can be said about PERL programmers. But why stop there, take a look at APL, J, K languages. J, for example, ships with all standard verbs aliased to words, like "under", "behead", "curtail" etc. Of course, nobody uses those, they write "&.", "}.", "{." instead.
Indeed, the same could be said about other languages. I was even going to write in my original post "of course, Haskell programmers are self-selecting". There are problems with the syntax of some of the languages you mentioned, probably because they require a special keyboard, which is an obvious hurdle. Others may not have prevailed because they were jarring to programmers that also had to program in mainstream languages (therefore, the familiarity argument all over again). Yet others are arguable -- PERL for example is joked about as a "write only" language, but how much of that is truly because of its syntax? Maybe idiomatic PERL merely leads to barely understandable programs. Maybe PERL is simply not a good language, no matter what (note: I'm not arguing this is the case, not being a PERL programmer myself). And maybe it's not true that PERL programmers find no fault in its syntax; maybe they have trouble reading their own code, which would put them in a different category than Haskell programmers!
In the end, all of this amounts to: a language syntax is aimed at its intended audience, programmers using that language and familiar with its intended degree of abstraction and with the problems it aims to solve. Programmers from other languages will often find it weird (and in Haskell this problem is increased by the fact it seems to belong in a different category than languages such as Java/C++/C#/etc.). It is a mistake to say that, because of this, language X has a "harder syntax"; the more correct claim would be "language X has a syntax that will likely be harder to learn for programmers used to F-inspired languages". This is probably related to the Blub paradox :)
Yeah, I mostly agree. But I believe there is some objective notion of readability and that syntax can be objectively more or less readable. However, that's only my belief, as we have no objective way to measure readability yet. (There's this wiki article: http://en.wikipedia.org/wiki/Readability but as far as I can tell nobody bothered to apply methods mentioned there to code)
So, as it's almost impossible to have a meaningful discussion on readability, I don't try to argue that Haskell is or isn't readable at all. However, the fact(? seems intuitive enough, but maybe it's wrong?) that it's easier to associate meaning to words than to abstract symbols and the frequent use of abstract symbols to name things in Haskell makes me argue that Haskell is harder to learn than for example J (btw, J and K use only ASCII characters). But that, too, is open to discussion - one can claim that names like <*> are easier to learn and more precise, because they come without any prior associations in the reader's mind.
In the end, the only thing I can say is that for me - probably because of a whole lot of factors and influences - word-based identifiers are easier to learn and use than symbol-based ones. It's entirely possible that a majority of Haskell programmers are different in this regard (and yes, they - as for all languages - are most certainly self-selecting).
OCaml code, on average, has less symbol-based infix functions and tends to be more readable (for me). But I'm not a Haskell programmer, so maybe that's a matter of getting used to, like parens in Lisps...
Just a few things like type inference and implicits and case classes would be enough to make Java devs drool without getting scared by FP or performance scares.
I don't think the community wants to go in that direction though. Who Scala attracted was a lot of FP programmers (Haskell/ML) who wanted to do work on the JVM; not Java programmers looking for a better alternative to Java on the JVM.
So is life.
(1) i.e. my coworkers, and people I know in other companies.