I wish there were more articles like this. So much content online on programming languages go trough the basics of the language itself, with very "forced" code examples to showcase some feature of the language, and while they're great for what they are, they don't tell me anything about "what does the software development life cycle actually look in this language?" (including tools like package managers, IDEs etc etc)
> Haskell is in the best-of-class category when it comes to documentation. Haskell's type system quickly earns your trust, and once it does, you almost never need to read someone else's code in order to understand it; you can just read the type signatures shown in the docs and get on with your life.<p>I don't think this is an accurate representation of how the Haskell community itself views the state of Haskell documentation. A large section of the community views the state of documentation as <i>very not</i> best-of-class and strongly advocates for improving it (and views type signatures as a poor replacement for at least examples). See e.g. <a href="https://www.reddit.com/r/haskell/comments/2ory86/there_is_a_documentation_problem_stop_pretending/" rel="nofollow">https://www.reddit.com/r/haskell/comments/2ory86/there_is_a_...</a><p>Likewise "Otherwise, toss a coin!" as a response to Cabal or Stack makes me sad. Tooling can often depend on exclusively either one or the other (see e.g. <a href="https://plugins.jetbrains.com/plugin/8258-intellij-haskell" rel="nofollow">https://plugins.jetbrains.com/plugin/8258-intellij-haskell</a>) and the fact that from a capability point of view, they're converging on the same thing makes it an unnecessary point of friction for new users, although I understand the reasons for why they both came to be.<p>EDIT: I should detach myself from the usual curmudgeonly HN comment to say that the organization of the article is very well done. I would like to see how non-Haskellers approach it because I think stuff like "What language idioms are available?" is a good way to approach a new language.<p>EDIT 2: The original Reddit link was far older than I thought it would be. Here's a more extreme (more than I personally agree with) take on the situation, but is a lot more recent: <a href="https://old.reddit.com/r/haskell/comments/or93z3/what_is_your_opinion_on_haskell_remaining_as/h6h6q12/" rel="nofollow">https://old.reddit.com/r/haskell/comments/or93z3/what_is_you...</a>
I learned Haskell a few years ago, enough to read it, but not fluent enough to comfortably write it. Haskell scratches a real intellectual itch, related to how it formally captures certain concepts (types, purity, etc). But my opinion is that Haskell collapses under the weight of its terseness and academic complexity. Can it be extremely elegant? Yes, in contrived examples[0]. Is it able to maintain this elegance when dealing with common problems? No.<p>0. <a href="https://wiki.haskell.org/Introduction#Quicksort_in_Haskell" rel="nofollow">https://wiki.haskell.org/Introduction#Quicksort_in_Haskell</a>
It might be worth giving a pointer on setting up your own stackage server. Otherwise, Haskell projects can become an ugly monolith sooner in a company's lifetime than one might expect. It can then become a double-edged sword that you're quite productive in the language.<p>The CI for a medium-sized Haskell-using company should have multiple instances of:<p>Project repo -> CI compilation -> tests -> publish library to company's internal stackage.<p>That way, when someone inevitably publishes something that breaks things, the other teams will have an <i>easy</i> mitigation / known-good-version to fall back on.<p>In other codebases (especially if they use the typical popular dynamic languages), you might start breaking things up into microservices sooner than you would with Haskell. But given that Haskell runs much, much faster than those other languages, and isn't quite the memory hog that the JVM is (when we're comparing to Scala), you might find that it'd help you scale if you broke up the codebase into libraries, rather than breaking it up into microservices. This is especially the case if your company / project is bottlenecked on ops (which many companies are, not just ones using Haskell). Multiple libraries is much easier to manage than microservices and forestalls the point at which you'll need serious dedicated ops.
I like the article much but I am missing some statements around IDE. What I like about typed languages is the code completion and refactoring it enables when used in a good IDE. Code completion also enables me to "explore" what is possible at the current location. Are there any good IDE's out there for Haskell?
From a practical software development POV I think the biggest problem with Haskell is the laziness by default. It's the central theoretical motivation for the language but when it comes to real work there are so many ways it can bite you, which is ironic given how much Haskell prioritizes safety in almost every other aspect of the language.<p>To me it's always been hard to reconcile that you have to deal with so many restrictions in the language that save you from ending up in some ill-behaving program state, yet a wrong fold can basically blow your entire program up.