Back

@Amirography
Man, when in history Haskell ever actually competed with C? Also can you cite some of the shortfalls of the tooling? The GPTish lack of reference in your claims leaves me wonder.

@exa as for specific tooling example, the language server, stack and GHC, all must be at the perfect sync, at all points. i have noticed that if the stack.yaml points to version compiled even by a 0.0.1± difference in version, the language server stops working.
The compiler error messages are horribly confusing . The code actions that come with linters sometimes result in broken codes. And again, coming back to the language-server, it takes an unwieldy amount of RAM.

@exa the documentation of the libraries apis that comes with LSP, most of the time only includes a function signature and no explanation or usage examples. There are some but those are far few.

@Amirography ah yes LSP, that's borked beyond recognition by design. I just use the terminal tools and primitive syntax highlighters, never spotted an actual error (and actually feel more productive than with IDEs because of pushing myself out of IDE pitfalls)

@Amirography ...that said, it is interesting to see the core reasons for the brokenness there (IDEs and LSP protocol don't really care about environment configuration except for a few dialog configs, forcing the authors to assume stuff and break othercs assumptions)

@Amirography There's actually plenty of emotion out there on the role of stack in the ecosystem -- it is unifying the environments for a price of assuming stuff and splitting the ecosystem.
. which somehow suits some programmers while others can't stand it (I'm in the other half). I guess programmers differ.

@Amirography haha well, I realized that the only cure is to have no tooling.. every help from an IDE I got has ever since turned into a thing I failed to learn and had to debug later. Painful to start tho. (also, do you know about typed holes right? these magically replace like 99% typical ide use for me :D)

@exa have you worked with rust or go before while utilizing an LSP on neovim before?
I really can understand why haskell's LSP would be optional. But the difference in experience when working with go is magnificent and honestly, I cannot imagine what kind.of genius could manage to code a medium sized application in rust without help of an LSP.
That difference is just too obvious to me when i code in haskell. Until I try compiling it. I feel like I'm shooting in the dark,

@exa Did that make sense?
If so, do you think you could easily write a backend server with.6 months of haskell learning overhead without LSP? I'm asking because the thought entered my mind that maybe the language, itself, is somehow handling that.

@Amirography Yeah, totally, I've got students learning this in a "slow course" over a semester without significant problems. Let me elaborate ...

@Amirography 1] haskell compiler can be used as a code query tool (and you can help yourself a lot using ghci if you don't like reading error messages). Try typed holes. Generally the language there helps you to build intuition by having the basic concepts done right. No idea how long you've practiced, but at the end the practice of just taking 20ish higher-level monadic combinators, arranging them on 1 line and getting a working&correct program after fixing the 1st compiler error is "common".

@Amirography 2] the optional status of the LSP is keeping the tooling extensible and sustainable. The LSP server is a moloch, and existence of molochs directly prevents development of alternate approaches to the issue (check out e.g. Agda workflow). Eventually we'd love to have something totally lightweight which just does the trick™. We're not there even with the compiler yet; standardizing the LSP would IMO make any new development in the right direction completely impractical.

@Amirography (btw the "unix philosophy" lessons kinda apply here: 1] LSP is complex and doesn't really help automation. 2] If you fail to code because your code is too complex, just write simpler code.)

@Amirography and extra note regarding the "web development" -- it is a common pitfall with haskell that beginners choose advanced libraries (say servant+selda for web) for simple tasks. They will fail because of the lack of required intuition, and LSP is only going to delay the realization of failure because it will make it look "doable". Most libraries have a beginner friendly counterpart (in this case I'd say scotty+sqlite-simple) that Just Works and already gives better power than e.g. Flask.

@exa thanks for the explanation. I see your points. I still think that a more interactive experience can help somewhat with the "learning-on-the-job" part. For example I learned a lot of common higher order functions in rust, through the suggestions offered by auto-complete and then reading their documentation and examples. That style of learning seems not to be an option with haskell though. Am I right? If so, do you have some suggestions with regards to function discovery?

@Amirography ah yeah discovery... I sometimes just copypaste a type of something I need to hoogle and it usually just works :)

@exa that's genius!