6 ms·

“But net/net, when a GHC contributor rolls up his or her sleeves, they on average have a bigger range than people who argue about ReactJS vs Ember.” I think th

“But net/net, when a GHC contributor rolls up his or her sleeves, they on average have a bigger range than people who argue about ReactJS vs Ember.” I think that’s going to be true for most people who have both the skill to contribute to anything like GHC and the drive to do so, I’m not convinced it’s specific to Haskell no matter how much you’d like that to be true.

dgb23 5y ago
They didn't say it was specific to Haskell, the wording was "than most other languages". My intuition is that they are right. More powerful and fitting tools with a higher learning curve attract different kinds of people than stuff that is tailored for the mainstream. There are also pragmatists who are extremely smart and capable and choose to deepen their expertise in Java (for example). But at _first glance_ it says more about a person if they are proficient in a specialized language than a mainstream one.
benreesman 5y ago
Maybe what I’m saying is that I give better odds for the typical senior Haskell hacker to get a useful diff into GHC than I do for the typical senior JS developer to get a useful diff into v8.
- kasey_junk 5y ago
  I actually think this is what is holding back the Haskell community from broader adoption. The senior Haskell hackers are much more interested in building compilers and runtimes and the like so the things that most developers really benefit from are missing. The IDE support, dependency management, performance monitoring and application frameworks are all just plain worse in the Haskell ecosystem than others. Smarter maybe holding the language back because it doesn’t correlate with shipping useful application software as well as other traits such as being customer oriented or empathetic to other workflows.
  - benreesman 5y ago
    Reason #9143346356 why I’m so grateful for VSCode even though I’d never use it: haskell-language-server —-lsp is pretty good. It’s kinda sad it can’t precise go to definition on libraries, but otherwise it’s really sweet.
    - beanjuiceII 5y ago
      it's sweet but can't do basic go to definition?
      - flylikeabanana 5y ago
        Go to definition in libraries is different than basic go to definition
        kasey_junk 5y ago
        But something solved for 20 or more years in IDEs for mainstream languages.
        benreesman 5y ago
        With the possible exception of Visual Studio, the only thing that mainstream IDEs have been “go to”-ing in the presence of an NP-hard dependency resolution graph for 20 years is the wrong place with a UI that simply exudes confidence.
        kasey_junk 5y ago
        You are sort of making my point for me. In theory dependency graph traversal is NP hard but in practice you can use heuristics to get to really good accuracy. This really good accuracy is almost always better than the system not working at all. Very frequently (not always) the Haskell community let’s the perfect get in the way of the good on issues like this and I end up with tooling that is worse than 20 year old IDEs.
- toqy 5y ago
  I once inherited a medium size python service and small front end at work that was primarily developed by someone that was super into Haskell. He chose to use mongodb and built a lot of functionality around the constraint that he didn't know what an index was. I'm very thankful his manager didn't let him write it in Haskell. Now he's where he belongs back in academia doing NLP research.
  - benreesman 5y ago
    In fairness, enthusiasts from lots of language communities got duped into using MongoDB.
    - computerliker69 5y ago
      Why would you say duped? Is there some major problem with mongoDB? The way you've stated this makes it sound like there's some common knowledge I should be aware of.
      - marcosdumay 5y ago
        > Is there some major problem with mongoDB? Yes, plenty. It's mostly useless for relational data. Nowadays that's clear on the documentation and you won't get loud people proclaiming that it's useful there, but there was a time when both of those were false.
        redwood 5y ago
        By relational data do you mean data that has no nesting or arrays? Or data that you always want to query with a join? Something else?
        marcosdumay 5y ago
        That that you would want to query with a join and have invariants that spread through those places you would want to join. Just keeping invariants of any kind is already non-trivial and will probably break at some point in a long lived system.

dgb23 5y ago

They didn't say it was specific to Haskell, the wording was "than most other languages". My intuition is that they are right. More powerful and fitting tools with a higher learning curve attract different kinds of people than stuff that is tailored for the mainstream. There are also pragmatists who are extremely smart and capable and choose to deepen their expertise in Java (for example). But at _first glance_ it says more about a person if they are proficient in a specialized language than a mainstream one.

benreesman 5y ago

Maybe what I’m saying is that I give better odds for the typical senior Haskell hacker to get a useful diff into GHC than I do for the typical senior JS developer to get a useful diff into v8.

kasey_junk 5y ago
I actually think this is what is holding back the Haskell community from broader adoption. The senior Haskell hackers are much more interested in building compilers and runtimes and the like so the things that most developers really benefit from are missing. The IDE support, dependency management, performance monitoring and application frameworks are all just plain worse in the Haskell ecosystem than others. Smarter maybe holding the language back because it doesn’t correlate with shipping useful application software as well as other traits such as being customer oriented or empathetic to other workflows.
- benreesman 5y ago
  Reason #9143346356 why I’m so grateful for VSCode even though I’d never use it: haskell-language-server —-lsp is pretty good. It’s kinda sad it can’t precise go to definition on libraries, but otherwise it’s really sweet.
  - beanjuiceII 5y ago
    it's sweet but can't do basic go to definition?
    - flylikeabanana 5y ago
      Go to definition in libraries is different than basic go to definition
      - kasey_junk 5y ago
        But something solved for 20 or more years in IDEs for mainstream languages.
        benreesman 5y ago
        With the possible exception of Visual Studio, the only thing that mainstream IDEs have been “go to”-ing in the presence of an NP-hard dependency resolution graph for 20 years is the wrong place with a UI that simply exudes confidence.
        kasey_junk 5y ago
        You are sort of making my point for me. In theory dependency graph traversal is NP hard but in practice you can use heuristics to get to really good accuracy. This really good accuracy is almost always better than the system not working at all. Very frequently (not always) the Haskell community let’s the perfect get in the way of the good on issues like this and I end up with tooling that is worse than 20 year old IDEs.
toqy 5y ago
I once inherited a medium size python service and small front end at work that was primarily developed by someone that was super into Haskell. He chose to use mongodb and built a lot of functionality around the constraint that he didn't know what an index was. I'm very thankful his manager didn't let him write it in Haskell. Now he's where he belongs back in academia doing NLP research.
- benreesman 5y ago
  In fairness, enthusiasts from lots of language communities got duped into using MongoDB.
  - computerliker69 5y ago
    Why would you say duped? Is there some major problem with mongoDB? The way you've stated this makes it sound like there's some common knowledge I should be aware of.
    - marcosdumay 5y ago
      > Is there some major problem with mongoDB? Yes, plenty. It's mostly useless for relational data. Nowadays that's clear on the documentation and you won't get loud people proclaiming that it's useful there, but there was a time when both of those were false.
      - redwood 5y ago
        By relational data do you mean data that has no nesting or arrays? Or data that you always want to query with a join? Something else?
        marcosdumay 5y ago
        That that you would want to query with a join and have invariants that spread through those places you would want to join. Just keeping invariants of any kind is already non-trivial and will probably break at some point in a long lived system.