3 ms·

What this tells me most of all, is that humans will only acknowledge the legitimacy of studies that support their predetermined opinions. The arguments for and

What this tells me most of all, is that humans will only acknowledge the legitimacy of studies that support their predetermined opinions. The arguments for and against a type system like Haskell's have been going on seemingly forever, and the commonly parroted line from e.g., Clojure or JavaScript enthusiasts (like the curly-haired San Francisco guy) is that there has never been a single study to support the idea that a type system like Haskell's is generally a cheaper way to write reasonably robust software. Point them to a study like this, and you're met with "Nuh-uh! Not valid! Nope!" My observation is supported by section 7, "Lessons Learned". > …The reaction from the other participants, however, in particular those not familiar with the advantages of functional programming, was somewhat surprising, and is worth some discussion.… > …In conducting the independent design review at Intermetrics, there was a significance sense of disbelief. > …some observers have simply discounted the results because in their minds the use of higher-order functions to capture regions was just a trick that would probably not be useful in other contexts. One observer described the solution as “cute but not extensible” > We mention these responses because they must be anticipated in the future. If functional languages are to become more widely used, various sociological and psychological barriers must be overcome. As a community we should be aware of these barriers and realize that they will not disappear overnight. They're right. These barriers haven't disappeared overnight. They haven't even disappeared after a quarter of a century. People still come up with stupid reasons why they don't like Haskell.

fnord123 8y ago
>They're right. These barriers haven't disappeared overnight. They haven't even disappeared after a quarter of a century. The barriers disappeared since functional concepts were absorbed into other languages. Almost all languages have higher order functions. Many languages have a preference for immutable data. Recursion was rightly not adopted as iterators are a better solution - keep the map/filter/fold, leave the TCO. >People still come up with stupid reasons why they don't like Haskell One expects that if Haskell was superior, then it would be impossible for successful Haskell projects to materialize as they've done with Python, Go, Rust, Java, C++. And yet, successful Haskell projects are rare. There must be a because there is a hidden variable that this study in 1994 didn't capture. There's certainly not a cabal of project managers forcing C++ down peoples' throats. So instead of calling the reasons stupid, why not try to find out what this hidden variable is?
- yakshaving_jgt 8y ago
  > And yet, successful Haskell projects are rare. There must be a because there is a hidden variable that this study in 1994 didn't capture. I'd argue that Haskell projects are just rare generally, at least partly for the reasons described in the study. It's not debatable that so much of a technology's adoption comes primarily down to network effects, and not a technology's technical merit alone.
  - otabdeveloper1 8y ago
    They're rare because attempts to actually use Haskell in the field result in disaster. When you're hiring random programmers off the street to code your shitty business logic in Haskell, the result is a horrible mess of 'Unsafes, exploding memory leaks and random crashes. It's a train wreck.
    - yakshaving_jgt 8y ago
      100% of my income is from web applications written in Haskell. I hire Haskellers, and it's been a positive experience so far. None of my projects use unsafePerformIO. I track metrics across everything, and I'm not suffering memory leaks or random crashes. Everything you have said is nonsense.
    - Jtsummers 8y ago
      That's why you don't hire random programmers. You hire good ones, or you develop a training program and ensure they're good before you give them the responsibility for making or breaking your business. Why would anyone trust "random programmers" to some of their most critical business efforts?
      - AnimalMuppet 8y ago
        Because random businesses don't know how to hire good programmers. (In fact, even good businesses struggle with it.)
acdha 8y ago
> Point them to a study like this, and you're met with "Nuh-uh! Not valid! Nope!" Are they really saying that or did they point out the small sample size, age of the study, inconsistent preparation of the participants, and ask about whether it had been replicated? I mean, the authors themselves acknowledge this and it'd be interesting to know how they would view it a couple of decades later, especially since there have been huge improvements across the board in languages and things like quality of tooling, availability of documentation, etc. Unfortunately, the way you chose to start that post sounded like you were assuming that any position which didn't support your favorite language couldn't be correct. I think that's just as unproductive as the sentiment you complained about, especially because one of the big trends over the last couple of decades has been appreciation for the exact concepts you quoted in other languages. People are writing more functional-styled code than ever before so it seems more likely that extremely complex and important decisions like choice of programming language aren't driven by a single purity test.

fnord123 8y ago

>They're right. These barriers haven't disappeared overnight. They haven't even disappeared after a quarter of a century. The barriers disappeared since functional concepts were absorbed into other languages. Almost all languages have higher order functions. Many languages have a preference for immutable data. Recursion was rightly not adopted as iterators are a better solution - keep the map/filter/fold, leave the TCO. >People still come up with stupid reasons why they don't like Haskell One expects that if Haskell was superior, then it would be impossible for successful Haskell projects to materialize as they've done with Python, Go, Rust, Java, C++. And yet, successful Haskell projects are rare. There must be a because there is a hidden variable that this study in 1994 didn't capture. There's certainly not a cabal of project managers forcing C++ down peoples' throats. So instead of calling the reasons stupid, why not try to find out what this hidden variable is?

yakshaving_jgt 8y ago
> And yet, successful Haskell projects are rare. There must be a because there is a hidden variable that this study in 1994 didn't capture. I'd argue that Haskell projects are just rare generally, at least partly for the reasons described in the study. It's not debatable that so much of a technology's adoption comes primarily down to network effects, and not a technology's technical merit alone.
- otabdeveloper1 8y ago
  They're rare because attempts to actually use Haskell in the field result in disaster. When you're hiring random programmers off the street to code your shitty business logic in Haskell, the result is a horrible mess of 'Unsafes, exploding memory leaks and random crashes. It's a train wreck.
  - yakshaving_jgt 8y ago
    100% of my income is from web applications written in Haskell. I hire Haskellers, and it's been a positive experience so far. None of my projects use unsafePerformIO. I track metrics across everything, and I'm not suffering memory leaks or random crashes. Everything you have said is nonsense.
  - Jtsummers 8y ago
    That's why you don't hire random programmers. You hire good ones, or you develop a training program and ensure they're good before you give them the responsibility for making or breaking your business. Why would anyone trust "random programmers" to some of their most critical business efforts?
    - AnimalMuppet 8y ago
      Because random businesses don't know how to hire good programmers. (In fact, even good businesses struggle with it.)

acdha 8y ago

> Point them to a study like this, and you're met with "Nuh-uh! Not valid! Nope!" Are they really saying that or did they point out the small sample size, age of the study, inconsistent preparation of the participants, and ask about whether it had been replicated? I mean, the authors themselves acknowledge this and it'd be interesting to know how they would view it a couple of decades later, especially since there have been huge improvements across the board in languages and things like quality of tooling, availability of documentation, etc. Unfortunately, the way you chose to start that post sounded like you were assuming that any position which didn't support your favorite language couldn't be correct. I think that's just as unproductive as the sentiment you complained about, especially because one of the big trends over the last couple of decades has been appreciation for the exact concepts you quoted in other languages. People are writing more functional-styled code than ever before so it seems more likely that extremely complex and important decisions like choice of programming language aren't driven by a single purity test.