> And as long as Haskell is used by such a tiny group of people
I'm guessing Haskell is used by more people than you think. There are 6500 packages on hackage. The Haskell subreddit has more than 16,000 subscribers. And there are usually more than 1300 people in the #haskell IRC channel at any given time. That's more than #ruby and ##javascript and about the same as #python. Also, Standard Chartered bank has roughly 1.3 million lines of Haskell code running in production.
> And the tradeoffs people have to make aren't clear, and if the tradeoffs aren't clear, the merits aren't clear either. They're at best hypotheses of potential merits, or merits in the eyes of the very particular group that's currently using the language.
This statement applies equally to pretty much every language out there. We don't understand the tradeoffs between mainstream languages either. We have no idea how those choices are actually going to end up affecting our projects. To claim otherwise is intellectually dishonest. How do you know that Ruby or Perl would be better than Brainfuck? The tradeoffs and merits aren't clear. They're at best hypotheses of potential merits. So how do we actually make these decisions in practice? We look at the language features and think about how they can help us manage common situations in software development, then we go with our best guess. We can do that for Haskell just as well as we can do that for Java, C, Ruby, etc.
> We look at the language features and think about how they can help us manage common situations in software development
Maybe some people do, but when I pick a programming language, language features are among the last things on my mind. I look at the available tools (profilers etc.), available libraries (particularly in the domain that interests me), quality of documentation, the size of the community and its vibrancy. I also look at similar projects done in the language. Only after all these do I look at the language features, but they don't matter so much, because I know I'll be very productive in a language with a very large selection of libraries and a large user community. I'm saying this after 20 years of developing software in languages like BASIC, Pascal, x86 asm, C, C++, Matlab, Java, Clojure, Scheme and more. I can't think of a single case where language features mattered more than any one of the things I listed.
All this is, of course, for serious projects intended for production. For a toy project I might look at the language features first.
If there were superb tooling, libraries, and documentation available for Brainfuck or INTERCAL, you would not find that sufficient reason to program in those languages. Of course, you will say, such a situation would never exist, because nobody is going to write libraries for INTERCAL. With this argument, though, you concede that language features are important. You just estimate them by proxy: languages with features that encourage library authorship pass your test. Rather than use this proxy test, some of us who are well informed about PLT choose to judge languages on their merits directly.
Nobody in this thread is talking about toy projects. Developers who use mainstream programming languages do not have a monopoly on real work. The consistent assumption made in these discussions that FP practitioners don't work on "serious projects intended for production" is misguided and insulting.
I think your cause and effect are reversed. I think that the biggest difference between "pragmatic" languages and research languages, is that pragmatic languages are driven by actual need, and with consideration for current practices and workflow. The language features are designed around that. Research languages, OTOH, are made to explore an idea, or conduct an experiment, usually made to answer the question "how would these language features affect development" (they could increase productivity, reduce bugs, improve performance etc). The result of the experiment are very valuable, and the successful, proven, ideas are then integrated into pragmatic languages. It is very rare that a research language achieves mainstream adoption. In fact, I would argue that if it does, it's failed as a research language because its widespread adoption probably means it wasn't adventurous enough.
Haskell is a prime example of a rather adventurous research language. It's an experiment that's been run for about 15 years now. First the early steps, and now people are experimenting with real world applicability. I'm really interested in the results, so I'd really like more people to run the experiment, but I have no doubt that Haskell itself will never gain widespread adoption. If it does its job well, its best ideas will be copied by other, non-research languages.
Now, I'm certainly not saying that Haskellers don't work on serious projects. But it is a fact that Haskell is much more common in academia than it is in the industry. Again, this is intentional. Haskell is meant to venture into unchartered territory and explore. Some of the things it aims to do work well and might be adopted in the industry, and others don't and won't. If Haskell teaches us even a few things, then it is a great success. What I don't like is that some Haskellers deny the true purpose of the language, and instead of examining it as researchers should do, they preach it.
You're starting with a fundamental assumption that there are two classes of languages, which you are calling pragmatic languages and research languages. I disagree. Researchers study languages of all sorts (there are plenty of research papers on Java), and practitioners use languages of all sorts (there are plenty of businesses using Haskell). Furthermore, many of the characteristics that make a language worth studying also make it worth using in practice.
Haskell has been around for nearly 25 years, not 15, and the ML family has been around for nearly 40. Strong type systems are not a research curiosity, and have not been for decades. They have significant and well-understood benefits, in practice.
I wish your hypothesis that the best ideas from research would be copied by other languages were true, but the history does not bear this out. A notable recent example is Swift: though it does make progress compared to its reference class, it still does not use any research more recent than roughly the 1970s. Clearly, the "pragmatic" languages are not keeping up. In what sense is it "pragmatic" to constrain yourself to decades-old technology?
The Haskell language is not constrained by some God-given purpose to be a research language for all time. Haskellers aren't "deny[ing] the true purpose of the language", they're choosing to use a useful tool, because doing so is pragmatic.
I'm guessing Haskell is used by more people than you think. There are 6500 packages on hackage. The Haskell subreddit has more than 16,000 subscribers. And there are usually more than 1300 people in the #haskell IRC channel at any given time. That's more than #ruby and ##javascript and about the same as #python. Also, Standard Chartered bank has roughly 1.3 million lines of Haskell code running in production.
> And the tradeoffs people have to make aren't clear, and if the tradeoffs aren't clear, the merits aren't clear either. They're at best hypotheses of potential merits, or merits in the eyes of the very particular group that's currently using the language.
This statement applies equally to pretty much every language out there. We don't understand the tradeoffs between mainstream languages either. We have no idea how those choices are actually going to end up affecting our projects. To claim otherwise is intellectually dishonest. How do you know that Ruby or Perl would be better than Brainfuck? The tradeoffs and merits aren't clear. They're at best hypotheses of potential merits. So how do we actually make these decisions in practice? We look at the language features and think about how they can help us manage common situations in software development, then we go with our best guess. We can do that for Haskell just as well as we can do that for Java, C, Ruby, etc.