Comment by tmptmp | Hacker News Reader

Comment by tmptmp | Hacker News Reader

Warning: be warned before you commit to Haskell. Not all is rosy about Haskell. You may find yourself in quagmire if you don't know for sure what you are going to get from Haskell, especially from the libraries. Although this is true for other languages also, the library support for Haskell is yet far from satisfactory as compared to the library support found for Python/Java. The Haskell community seems to have been divided over it.

Not so ago there was some discussion about "batteries" included with Haskell. [1] It compared situation of Haskell with that of Python/Java etc, worth reading if you are about to go the Haskell route.

It seems, the priorities (academic, commercial, library support and so on) of the members of Haskell community are at crossroads and they cannot seem to resolve those very good, IMHO.

My take: Haskell is good for learning some really deep concepts, but may be not so good when it comes to commercial projects, unless you are a Haskell veteran and also have an army of Haskell veterans with you.

[1] http://osdir.com/ml/haskell-cafe@haskell.org/2016-10/msg0001...

There's also a document maintained on GitHub that gives a rating of Haskell's support for different domains:

https://github.com/Gabriel439/post-rfc/blob/master/sotu.md

Which backs up your statements; many of the sections under "Common Programming Needs" are rated immature: Databases, Debugging, IDEs...

It sounds quite unsurprising that Haskell (or for that matter, any language that isn't java/python/c) doesn't have an ecosystem comparable to one of the most successful industrial languages around.

I'm not saying everything is great with Haskell, but so far, I haven't run into major holes for what I'm doing, library-wise.

You would think that a really rigorous language like Haskell would foster a better ecosystem of libraries than ad hoc languages like Python or JS but that has not been the case at all so far. I'm not sure exactly why but it's one of the main reasons I'm taking a wait and see attitude to Haskell.

> a really rigorous language

Is it rigorous in theory or in practice?

An academic veteran might want to better express his ideas in code while a professional veteran might want more readable code with better test coverage. And that's just 1 axis where the two viewpoints might diverge or even come in conflict.

I'm trying to imagine what "rigorous in practice but not theory" might look like. It seems to me that rigor derives from theory and can then be applied in practice. Haskell is rigorous in both.

I'm not talking about Haskell "the language", but about Haskell "the ecosystem".

Industrial rigor regarding code means:

* consistence in using a coding style

* having adequately named modules, functions and variables

* having adequate comments

* having an adequate level of code coverage through automated tests

* having performance and regression tests

* having good release notes

* etc.

Many of those things, required for high quality libraries, are often skipped for the academic projects Haskell is known for.

So that's why Python or even PHP or Javascript, as less "rigorous" theoretical languages, can have more "rigorous" libraries in practice.

So, like anything, the available libraries vary, but the important ones score pretty highly. Haddock documentation (like Doxygen) is considered a basic part of the job. "cabal test" will run embedded test harnesses. Stackage contains a set of libraries considered to be stable and of sufficient quality that most projects don't need to have qualms about using them. See for instance https://www.stackage.org/haddock/lts-7.10/http-client-0.4.31...

Reply on news.ycombinator.com