alt Hacker News> The only complaint against Haskell was about long compilation times.
There is also this
> How do we make library docs full of copy-pastable, realistic examples, not just beautiful types?
Which is useful for humans as well as agents.
Haskell indeed has a very bad track record of documenting its libraries. For many people, just having the function signatures is documentation enough.
Rust is equally bad at compile times (if not worse) but its standards for documentation is at another level
Replies
toolslive • today at 3:48 PM
> Rust is equally bad at compile times
OCaml enters the room...
> For many people, just having the function signatures is documentation enough.
You make a fair point about a documentation gap. The first step is always defining the problem. Wanting to add lots of realistic examples sounds like a wish for more tutorial or beginner-friendly content. Do you see the problem differently?
On the other hand, a given pure function type only has only so many possible implementations — why tools such as djinn and MagicHaskeller exist or why Hoogle is actually useful, unlike the horror of searching for every `void (*)(const char *)` in C.
https://hackage.haskell.org/package/djinn
https://hackage.haskell.org/package/MagicHaskeller
https://hoogle.haskell.org/
From that perspective, Haskell docs tend to be more expert-friendly — perhaps a rationalization, granted — which seems ideally suited for an in-IDE model to help bridge between developer intent and typechecked code. However, this comes at the expense of putting in the reps to rewire the developer’s brain to think in functional terms and the resulting mind opening and horizon expansion to think new thoughts she wasn’t capable of even considering. In these days of LLMs, fretting over that particular opportunity cost may be thinking nostalgically about the loss of craftsmanship in fine, well-balanced buggy whips.
In the limit now, will all programming be strictly literate?