4 ms·
One of the points the author touches is documentation. I just couldn't get why then he gave advantage to Haskell, since the documentation of Haskell libraries f
by dragandj 8y ago
One of the points the author touches is documentation. I just couldn't get why then he gave advantage to Haskell, since the documentation of Haskell libraries famously consists of a few definitions of types. So, you know that there is an abstractly named monadic function, you know it takes a foo and returns monad foo. What more guidance would you ever need?
But when it comes to CL, he has expectations:
>I’ve opened an issue on GitHub of one quite popular library, asking the maintainer to write documentation, but after 6 months it’s still not written (strange, right?).
- forkerenok 8y agoI think that was indeed a bit biased. That said, and not defending the author, I would add, that as an advanced beginner in Haskell, I find types to be sufficient documentation. Very often if I look for something in Hoogle, I would be just skimming through type signatures looking for what I want. If I look for something specific I would just put the type I want into the search field. On the contrary, f.x. with Java I tend to either google the operation I want to do using queries like "How to do blah" or read javadoc in advance to mentally index what a given library has. And there you really need to read into the text trying to figure out why a method is overloaded multiple times with some obscure extra boolean flags. edit: grammar
- bad_user 8y agoI’m a Scala developer, using many libraries inspired by Haskell equivalents. I have to disagree, types are not sufficient as documentation and this is what kept me from making the jump to Haskell actually. But types are better than nothing, or better than outdated documentation. I can’t imagine anything worse than code written in a dynamic language and without any documentation. This is the same discussion as with types vs tests. Types give you certain proofs for free, freeing you from writing certain types of tests. And they make property based testing easier. But the ideal is to have types + tests, types + good documentation, etc.