4 ms·
Types aren’t documentation, no matter how many Haskell users delude themselves thinking it is. Documentation is more than a function definition. Types don’t ex
by FranzFerdiNaN 8y ago
Types aren’t documentation, no matter how many Haskell users delude themselves thinking it is.
Documentation is more than a function definition. Types don’t explain rationales and how to use functions and programs. Types don’t give proper examples.
- hasahmed 8y agoIt's better documentation than no documentation
- chowells 8y agoTypes are really good documentation. I can tell I'm not deluded by thinking so because I can sit down with a Haskell library containing zero examples and write code that uses it. If your assertion was correct, that would be impossible. But it's not only possible, it's easy. Perhaps there is more to types than you realize.
- pmoriarty 8y agoAlice: Hey Bob, want to try my nifty new function? Bob: Sure, Alice, what does it do? Alice: It takes an object and it returns an object. Bob: But what does it actually do? Alice: I told you. It takes an object and it returns an object. Bob: But what does it do with the object? What's it for? Why should I use it? Alice: Hey, I just gave you the full documentation for my function. You have everything you need. Now go use it. Bob: Um, no thanks. I like to know more about what I'm getting myself in to.
- xboxnolifes 8y agoThankfully, Haskell supports much nicer types than only `Object`
- pvorb 8y agoAlice: Hey Bob, want to try my nifty new function? Bob: Sure, Alice, what does it do? Alice: It takes a string and it returns an integer. Bob: But what does it actually do? Alice: I told you. It takes a string and it returns an integer. Bob: But what does it do with the string? What's it for? Why should I use it? Alice: Hey, I just gave you the full documentation for my function. You have everything you need. Now go use it. Bob: Um, no thanks. I like to know more about what I'm getting myself in to.
- ilovecaching 8y agoI think you're criticizing a language you have no experience in. Haskell development is type driven. You start by defining and constraining your types until you get a DSL to write signatures in. See the Idris O'reilly book for more on type driven development. By the time you've added type constrains through typeclasses, selected types named after the domain, and selected a suitable name for the function, it's possible to write against the signature with no knowledge of the body or comments. You're also forgetting that signature includes the name of the function. reverse :: [a] -> [a] is easy to understand by it's name and type.
- pvorb 8y agoI didn't critisize Haskell. I only criticized a statement about its type system. > You're also forgetting that signature includes the name of the function. That's what I wanted to point out. The name of a function is even more important than its types. Types alone seldomly give you the complete picture of what's going on in a function. Of course the name can be wrong whereas types can't, but the name is less likely to be wrong than a comment.
- deleted 8y ago[deleted]
- deleted 8y ago[deleted]
- StavrosK 8y agoTypes are documentation. Documentation isn't types.
- ilovecaching 8y agoI suggest reading Type-Driven Development with Idris by Edwin Brady. I don't think you have enough experience writing Haskell to understand the outcome of type driven development. In Haskell you start by defining your domain as types, and constrain those types with typeclasses. By the time you get to writing signatures, the implementations can almost be inferred (in Idris they actually can be inferred, the code literally writes itself). In an imperative language with side effects, examples and documentation are a must because behavior is hidden in the body of a function; the signatures lie. A journeyman Haskeller can write code that is completely self documenting. No examples are required, because the types coupled with the purity of the language allows us to tell the whole story.
- Buttons840 8y agoThis is (probably often) true for all those who can load a few dozen arbitrary type signatures into their active memory and start drawing conclusions. For the rest of us a few examples of how to do common things would help a lot. Please include documentation. I have experienced what you're talking about with Haskell but it was a lot of uncomfortable work. But it's "technically" true that the types often describe how to use a library, sometimes so well that errors cannot happen.