4 ms·

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 develop

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.
        benreesman 5y ago
        Oh I also agree that haskell-language-server makes the wrong precision/usefulness tradeoff. Codex for example can usually get you somewhere at least useful. I was just pointing out that “solved” is a strong word for anything Eclipse or JetBrains did 5-10 years ago :) It’s easy to forget how shitty all the IDE stuff was before VSCode forced LSP through the clogged artery of language tooling.
        kasey_junk 5y ago
        I was personally using “go to definition” for Java with whatever IDEA’s tool was called in 2001-2002 (renamer?) and had the full suite of modern refactors in C# with Resharper by 2005. I honestly haven’t seen much of an improvement in IDE productivity in the last 5-10 years compared to Resharper circa 2008 but if Haskell could get to parity with that it would be a huge win.
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.

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.
        benreesman 5y ago
        Oh I also agree that haskell-language-server makes the wrong precision/usefulness tradeoff. Codex for example can usually get you somewhere at least useful. I was just pointing out that “solved” is a strong word for anything Eclipse or JetBrains did 5-10 years ago :) It’s easy to forget how shitty all the IDE stuff was before VSCode forced LSP through the clogged artery of language tooling.
        kasey_junk 5y ago
        I was personally using “go to definition” for Java with whatever IDEA’s tool was called in 2001-2002 (renamer?) and had the full suite of modern refactors in C# with Resharper by 2005. I honestly haven’t seen much of an improvement in IDE productivity in the last 5-10 years compared to Resharper circa 2008 but if Haskell could get to parity with that it would be a huge win.

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.