> If enough FUD is spread about Haskell, for example it being a failure at CS, then it becomes difficult to convince management.
Haskell is not yet at an adoption level where anything said about it would qualify as FUD. If I told you I have a great cold remedy and all of my friends really like it, you saying that you may want some more carefully researched information first doesn't qualify as FUD. I don't see why anyone can be expected to make a rational decision based on nothing but marketing from enthusiasts. Haskell is not even at the point where management is the part of the organization that needs convincing.
> If they want to use Haskell, don't stop them due to lack of case studies.
That is precisely the job of responsible management: to stop technical teams from using expensive technologies, that are not only unproven, but hardly have any actual anecdotal information at all. The precise difference between management and developers is that management sees the bigger picture. As a manager I wouldn't mind technical people experimenting with Haskell or any other unproven technology on side projects, though.
> The best way for other developers to understand why, is to try it.
Yes, but when you come out with an experimental, very expensive drug, you don't say, "the best way for people to see if it works is to try it". Instead, some people try it, and then they research and report on their experience. After all, you're not asking me to try a new sorting routine, but a whole new language ecosystem. I understand why some early adopters and PL enthusiasts would be happy to try, but most organizations don't and shouldn't act in this way. There are tons of promising technologies. Is every company supposed to just try each one? Do we all need to try Elixir, Kotlin, Clojure, Scala, Haskell, F#, and Go? Now, it may not be fair, but the fact is that the more expensive the experiment, the more data we'd want before we'd allocate resources to conducting it. A language like Kotlin is nearly free for Java shops to try. Haskell? Not so much. The best way for other developers to understand is, therefore, for the few early adopters to research and report on their experience, with some actual data (cost, duration, size etc.).
> You were implying that Haskell had failed somehow because SC had stopped using it.
Yes, that is a very negative signal. I don't see how choosing F# changes things.
> Decisions within large organisations are rarely made on purely technical grounds.
True, but in general, organizations shouldn't make decisions on "technical grounds", but "bottom line grounds". Even that doesn't always happen, but it generally does, and it's reasonable to guess that if Haskell had had a huge advantage, it wouldn't have been abandoned. Also, remember that the converse is also true. If abandoning a language isn't conclusive evidence that it isn't cost-effective, adopting it isn't conclusive evidence that it is. That's why we need some data. It can be anecdotal data, but it must be actual data, and not a marketing lecture.
> I can assure you there are many Haskell advocates still there.
I'm sure there are. Unfortunately, the number or enthusiasm of advocates is never a substitute for evidence. It's perfectly fine that some early adopters are swayed by the advocates, but it's also perfectly rational not to be swayed by it. I absolutely believe that some people truly enjoy Haskell and feel that it makes them more productive, but without some data, it would simply be irresponsible to pay so much based on marketing alone.