Hacker Timesnew | past | comments | ask | show | jobs | submitlogin

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.



it's sweet but can't do basic go to definition?


Go to definition in libraries is different than basic go to definition


But something solved for 20 or more years in IDEs for mainstream languages.


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.


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.


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.


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.




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: