2 ms·

I load the module into ghci and use the :t command. But I mostly do this during development. This is the big reason that production-quality code should genera

I load the module into ghci and use the :t command. But I mostly do this during development. This is the big reason that production-quality code should generally have explicit type signatures for top-level functions.

Periodic 17y ago
If we're talking about making code easy to read, type signatures are one of the best tools. Many times you can look at the name of a function and its arguments and you have a very good idea of what it does. This is unlike many dynamic languages where the returned value could be an object of just about any class. Are we getting a hash? An array? A custom class? Who knows without reading the details of the function.
hristov 17y ago
Well this kind of proves my point. If you have to compile code simply to read it, then the language is not very easy to read. What if you are reading the code in order to debug it and the code cant compile? And I know code should have type signatures but it often doesn't.
- jrockway 17y ago
  And I know code should have type signatures but it often doesn't. Often? All the libraries in GHC have type signatures. All the libraries on HackageDB I've used have type signatures. All the apps I've written have type signatures. Even most Haskell blog posts (and wiki pages) use type signatures. I think you should just peruse some production Haskell code, and try writing a bit of your own. If you set aside your belief that everyone is out to confuse you for a few minutes, I think you'll find that most Haskell is quite readable, and quite writable. You'll see how other people compose functions, what the idioms are, and then stuff like "sum = foldr1 (+)" won't confuse you anymore. Instead, I think you'll see how you can read and write code more quickly, and how to understand your program in terms of function application instead of in terms of passing around boxes that hold data.

Periodic 17y ago

If we're talking about making code easy to read, type signatures are one of the best tools. Many times you can look at the name of a function and its arguments and you have a very good idea of what it does. This is unlike many dynamic languages where the returned value could be an object of just about any class. Are we getting a hash? An array? A custom class? Who knows without reading the details of the function.

hristov 17y ago

Well this kind of proves my point. If you have to compile code simply to read it, then the language is not very easy to read. What if you are reading the code in order to debug it and the code cant compile? And I know code should have type signatures but it often doesn't.

jrockway 17y ago
And I know code should have type signatures but it often doesn't. Often? All the libraries in GHC have type signatures. All the libraries on HackageDB I've used have type signatures. All the apps I've written have type signatures. Even most Haskell blog posts (and wiki pages) use type signatures. I think you should just peruse some production Haskell code, and try writing a bit of your own. If you set aside your belief that everyone is out to confuse you for a few minutes, I think you'll find that most Haskell is quite readable, and quite writable. You'll see how other people compose functions, what the idioms are, and then stuff like "sum = foldr1 (+)" won't confuse you anymore. Instead, I think you'll see how you can read and write code more quickly, and how to understand your program in terms of function application instead of in terms of passing around boxes that hold data.