Back

@Amirography oh well I have to say that to me C doesn't simply have tooling. There are some things, but I've never seen a C project actually effectively managing dependencies and doing linting the proper way, for example.

Taking this absence into account of course makes Haskell look like the cool kid on the block.

Actually the thing that irked me a lot at the time wasn't Cabal itself or Stack for example, but the fact that you had to know by heart which extensions for GHC you were using.

@dottorblaster I see your point and that also bothers me as well, but what is more disappointing to me is the sad state of backwards or forwards compatibility: it is non-existing.
Both of our criticisms are rooted in the tact that haskell is research language. But I still wished that there was something on par with haskell that was intended for industry, tooling-wise, without giving up the beauty of the language itself.

@Amirography really same same, when I had the feeling and I was actually explained that Haskell is a research language I almost lost interest in it, also I'm extremely aware that I found some toxic elements in the community so really not a super pleasant experience.

I wish the same, also because the industry _is_ actually taking advantage of GHC's capabilities in very specific areas, like Klarna or Meta or other companies _have_ production software written in Haskell.

@exa the competition I meant was of course of paradigm, where C being a champion of imparitive approach and and haskell the opposite.
This I find to be a rather common comparison.

@Amirography hm "neumann legacy" is kinda weird even with C. Is it actually a competition though? There are literally things that you can do with one approach but are literally unthinkable in the other one (but that's ok because no one would sanely choose to do so anyway). Imagine implementing `pandoc` imperatively versus say `pv` functionally... :D

@exa honestly I was just emphasizing that probably haskell's tooling only had to satisfy the standards of the time that the major players at the time were C.

@Amirography ok depends "which time" though...back then before usable cabal (mid 2000’s) there's been perl, PHP, java, few remaining prologs, veeery good lisps, plenty of magical closedsource C++libs, and a few other things with pretty good packaging systems (relative to the standards back then). C packages kinda exist as the "autoconf" ones, these are in use to date with no significant change in sight, but that's hardly a C language-related effort, more like unix/gnu distro related.

@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.

@exa to me, I just don't want to spend.as much time debugging my tooling as I am debugging my own code. So far though, i spent more time on it than reading books on haskell and working through excercism challenges, combined.

@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!

@adziahel yeah. Though Haskell seem to aggressively prune legacy by avoiding backwards compatibility. Which makes the language pretty interesting but efforts for maintaining tooling for it, to be pretty herculean tasks.

@Amirography avoids backward compatibility, huh? interesting, could you maybe give an example?

@adziahel
I have seen this page: https://github.com/fumieval/Haskell-breaking-changes
Also some of the simon peyton joneses talks gave me this impression.

Other than that serokells post on learning resources for haskell mentions that some of the code from "learn you a haskell for great good" is not working anymore. (Which might be because of the third party packages. I'm not sure.)