5 ms·

> People and organizations are free to make their own considerations and choose their tools. Not true. If enough FUD is spread about Haskell, for example it be

• pron 10y ago
  > 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.
  • pka 10y ago
    > 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. In most cases management isn't qualified to make technical decisions. Managers rarely see the bigger picture. I've worked on a Haskell project that worked, never crashed, was lightning fast and was meeting deadlines for new features without a problem. Then higher management decided to throw away probably around 7-10 man-years and rewrite the whole thing in Java, quite literally "just because Java". We even had a consultant from FP complete come over to take a look at our codebase and talk in front of management about the advantages of a mature codebase in Haskell. Management didn't even come. Abandoning Haskell, in my case, had absolutely nothing to do with its technical merits and everything to do with incompetent management. When I left one year after they started rewriting the project in Java (I was staying to help maintain the Haskell code while the transition was happening) everything was buggy as hell, slow and unmaintainable. Not to mention that half the Java guys they hired had already left again.
    • pron 10y ago
      First, given the large effort involved and how much you wanted Haskell to succeed, I assume you carefully collected lots of metrics. By publishing them you could actually do Haskell and the software community at large some actual good other than just complain about incompetent management (and I've whined about management, too). You may have missed the chance in that company, but your well-researched report is sure to convince some others, so that's not a total waste at all. Second, such incompetence often works in the other direction, too, usually in companies where incompetence takes a different form, which is why a little actual information would be nice. Your technical report about a 7-10 man-year Haskell-and-then-Java project would make a great contribution! For an experiment of such non-trivial effort, and given that the project was later re-written in Java, you may even find a prestigious publication to publish your report.
      • pka 10y ago