I agree. In another forum someone was asking what level of competency you should be at with a language to put on the resume. Most responses were related to the language itself, but I argued it was more about the knowledge around the language. Knowing testing, tooling, packaging, and standard library is way more important than syntax. In turn, I think it's easier to write an article about syntax since its likely to be correct forever. While an article about dev life cycle is much more tied to the time at which it was written.

> 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 very not best-of-class and strongly advocates for improving it

Almost every time (though it's quite rarely) that I end up on a Haskell documentaiton page, I facepalm and move on. Yes, there's a dump of inpenetrable types. But... how do I actually use those types? :)

If I compare Python docs and Haskell docs even the official python docs are completely terrible. For example let's take the regex library and want to look up how to get match groups: https://docs.python.org/3/library/re.html

99 out of 100 times someone will land on this page and already know what regexes are. So basically 1/3 of the page is useless. After a while you find you need to use the `match` method. Great! Now I see I get a match object. How do I deal with those? There is not a clickable link here. In the example it's an opaque object. So I scroll further maybe ctrl+F to find match object. Here I find what I'm looking for. So this take me pages of scrolling and then manually searching for the object a method returns. That SUCKS. Everytime I use the re library and need to refresh my knowledge I'm in pain.

Compare this to Haskell: https://hackage.haskell.org/package/regex-compat-0.95.2.1/do...

Great. I instantly see how to construct a regex. The next thing I see is the `matchRegex` function. The bread and butter of using regexes. And what does it return? "Maybe [String]". Literally couldn't be easier then that.

Of course this doesn't hold for every Haskell library and Python library. But this is my general experience.

I think, coming from other languages, it takes a while to really absorb how much you can rely on types to tell you what a function is doing - to the degree that for some functions you can infer the implementation from them[1].

That said, Haskell documentation tends to be really lacking on some of the basics that other ecosystems get right, like where to start, shielding beginners from functions for more niche usecases, examples of how to build or deconstruct values, or end-to-end case studies. Some of the nicest things to _use_ have an API that primarily comes from typeclasses in base, and don't provide any documentation beyond a list of typeclasses. My impression has been that most Haskellers seem to be on the same page that those things need work, though - I'm optimistic about the situation improving, but it's still hard to recommend to anyone expecting the experience of working with popular libraries from more mainstream ecosystems.

[1] https://bartoszmilewski.com/2014/09/22/parametricity-money-f...

Cabal and stack are also very hard to understand when starting out.

In your opinion, is that still the case if the company uses a one-version monorepo? Ideally every test would break when the library team tried to commit.

I find VS Code with the Haskell extension to be very good for displaying type signatures, code completion and navigation, etc. Holes (which are covered by the article) are the go-to way to see what's possible at the current location. You type an underscore in your code and the compiler tells you a bunch of information about what goes there including things you could put there that would typecheck.

How is developing with Haskell? I've been considering picking it up because I love functional programming. I usually write quick n dirty stuff in python and lately I've been picking up go as well, which is a breeze to write with.

Can I get moving quickly with Haskell or will it take a while to get accustomed to it switching from other languages? My fear is that, like when I started picking up rust, it'll be a bit of a slog.

> I do write pretty terse, higher order code, with lots of higher order functions, applicative functors, monad transformers, and many other abstractions that relatively tersely describe what is happening

Can other people understand what is happening? Can people with less expertise understand what is happening? Can you yourself understand what is happening 6 months from now?

What formal methods did you use?

> (To be fair, there is one well-known foot gun, which is that if you lazily read from a file and close the file, the consumer of the file's contents will often get truncated results. So don't do that. Maybe it's been fixed by now, or that API's been deprecated? I haven't really kept up on current events in the Haskell world.)

I think the API is still there, but lazy IO is so heavily discouraged that no one is using it. It's not relevant anymore and considered a mistake.

So what is "Haskell itself"? Writing everything with the Prelude and the `IO` Monad?

Sure some people go off the rails with some things, but it's possible to write mostly vanilla Haskell and get a lot done.

It comes up when you're dealing with large amounts of data; you go to evaluate the value of a function and it crashes because the stack limit was exceeded. (Ghc changed some things awhile back so that it just allocates more memory now instead of crashing, but still it can cause performance/memory use issues if what looks like just an integer is actually just pointing to an unevaluated thunk pointing to megabytes of data.) Laziness is also annoying when trying to get parallel code to actually run in parallel instead of having expensive computations deferred to whenever the consumer evaluates the value of something.

Laziness does have real benefits sometimes though. It's nice to be able to define infinite data structures, for instance.

My experience:

For one, it makes reasoning about runtime (as in "how long") harder: E.g. an innocent looking "take 5" might be what actually executes half of the code you've written... which is also harder to reason about than if it would be "all of it". This can also make debugging harder: Values are only evaluated when they are needed, and a "value" itself may not be just, say, a single number, but a complex data structure consisting of many values, so that "evaluated" has many different stages between "a thunk, not evaluated at all" and "weak head normal form". So code does not get executed when you wrote so in your program, but potentially much much later. Semantically that should not make a difference (the results should be the same), but when you want to debug program flow...[1]

You can see how "thunks" in general add a certain dimension to everything you do. Throw in interaction with garbage collection, and things aren't always obvious in resource usage.

Also, there is maybe an argument that if you have infinite data structures that you only tend to evaluate partially (which is what makes laziness really fun, actually), then accidentally trying to fully evaluate such a data structure makes your program not terminate anymore. But I'm not sure how that's really a problem coming from laziness. Laziness allows you to handle infinite data structures in the first place, mishandling them is not much different than accidentally writing an infinite loop in a strict language, in my opinion.

That being said, I still enjoy writing Haskell very much when I get to. It makes me feel much more productive, and I do lament having to use other languages at work. I must say using Haskell was always on private projects, and I have never tried doing so in a team, though.

[1] On the flip side, I find the pureness and strictness of Haskell to make debugging easier, or just less necessary.

It can sometimes be an issue in certain "Gotta go fast" scenarios, where you'd otherwise be able to reason quite confidently about program behaviour with a strict language.