Hacker News Reader

Comment by ivanbakel | Hacker News Reader

My point is there's no "lack" of tooling. Nowadays, the Haskell IDE engine is good enough for general use. It's pretty trivial to plug into every general-purpose editor.

More and more beginners nowadays do not want to install a whole new IDE. They don't want to have to configure it, learn it, and understand all of its nuances and foibles. They prefer using their existing setup (VSCode, Atom, vim, emacs, etc.) with a nice slot-in for the new language - which is exactly what the Haskell tooling supports.

By comparison, a custom IDE is a massive undertaking, and a relatively fruitless one. It takes a tremendous effort to do well, and up until that point it actually negatively impacts the learning experience: if you encourage beginners to use a mediocre IDE, they will experience the language in a mediocre way.

View on HN

> Nowadays, the Haskell IDE engine is good enough for general use.

Sadly I am unconvinced of this. If it were true, there would not be an immediate and significant push to make `haskell-language-server`.

Having tried many times to get `hie` working, I can say that it's a pain in the bum.

Suppose I have 12 projects, one made every month for the last year. Each of these 12 will be using a different stack resolver, possibly with different ghc versions. As a result, I will need to compile and use up to twelve different versions of hie, and make sure that the correct one is on my $PATH depending on which project I have open.

I don't think it's quite that bad. Most likely you could easily use 1-2 ghc versions for those, and you need one build of IDE tools per ghc version, not per resolver, no ?

Sure, I'm outlining a worst-case. But realistically, even having two different hie versions is enough to make switching environments a Hard Problem.

There are a lot of tools, but last time I looked, they weren't particularly integrated, which is the point of an IDE. It doesn't have to be a haskell specific IDE, but there doesn't seem to be an intellij/pycharm/VS-for-some-languages equivalent experience anywhere to be found for haskell.

> Nowadays, the Haskell IDE engine is good enough for general use. It's pretty trivial to plug into every general-purpose editor.

Strong disagree. Even in small hobby projects it's slow, has limited functionality, and needs frequent restarts to function properly.

> My point is there's no "lack" of tooling.

All the more reason to have an IDE.

> More and more beginners nowadays do not want to install a whole new IDE

That's incommensurate with reality, to put it mildly. IntelliJ is out of control, partly because java itself is horrendously convoluted, but that's an exception. A beginner would rather have a tool to support their learning curve than not. I guess it's a matter of what constitutes a "beginner".

I do not disagree that people prefer to keep their own IDEs, but that's impractical across all languages. You're going to lose tooling along the integration path, naturally.

> All the more reason to have an IDE

No, all the less reason. The path existing Haskell tools are taking makes sense. An IDE would be a massive community undertaking to do well, and still a waste of massive community effort to do poorly.

> IntelliJ is out of control, partly because java itself is horrendously convoluted, but that's an exception.

...and partly because Java is many users' first language, and partly because its ecosystem is notoriously complicated to configure and use, and partly because IntelliJ is so mature, and....

I think IntelliJ doesn't prove your point at all. It is essentially nothing like what a hypothetical Haskell IDE would be, either in users or use-cases.

I appreciate that beginners want tooling, but I am arguing that an IDE is precisely not what that tooling should be.

Reply on news.ycombinator.com