4 ms·

People who write Haskell don't just leave their symbolic operators undocumented. It's definitely heavy on the symbols but that and type signatures are certainly

by vore 6y ago

People who write Haskell don't just leave their symbolic operators undocumented. It's definitely heavy on the symbols but that and type signatures are certainly not the only tools Haskell devs have.

dllthomas 6y ago
On the one hand, the parent's comment is certainly hyperbole. On the other hand, it's also the case that too any Haskell projects are under-documented. Probably worse than the typical language, and certainly worse than the best-in-class. On the gripping hand... while types make poor documentation, they are always correct documentation, and they are automatically generated documentation. When I write Python or (apparently) Common Lisp, I can expect to get reasonable documentation by interrogating anything someone hands me. In Haskell, insofar as I have learned to get good information from the types, I get some (correct!) documentation for things that I have newly assembled myself!
- newen 6y ago
  I find type information for functions incredibly useful. I get so lost in Python code once it get past a certain size even after years of Python programming experience because of the its lack of ability to put a useful amount of structure into the code. After having programmed in Haskell for a while, I just miss tabbing a function and being able to see its type signature.
  - dleslie 6y ago
    That, and more, is available in common lisp. * (describe #'+) #<FUNCTION +> [compiled function] Lambda-list: (&REST SB-KERNEL::NUMBERS) Declared type: (FUNCTION (&REST NUMBER) (VALUES NUMBER &OPTIONAL)) Derived type: (FUNCTION (&REST T) (VALUES NUMBER &OPTIONAL)) Documentation: Return the sum of its arguments. With no args, returns 0. Known attributes: foldable, flushable, unsafely-flushable, movable, commutative Source file: SYS:SRC;CODE;NUMBERS.LISP Docstrings and type information can (optionally, but recommended) be added to all code. Users of your API can use documentation/describe to discover information about it without ever having to look at the implementation.

by vore 6y ago

People who write Haskell don't just leave their symbolic operators undocumented. It's definitely heavy on the symbols but that and type signatures are certainly not the only tools Haskell devs have.

dllthomas 6y ago

On the one hand, the parent's comment is certainly hyperbole. On the other hand, it's also the case that too any Haskell projects are under-documented. Probably worse than the typical language, and certainly worse than the best-in-class. On the gripping hand... while types make poor documentation, they are always correct documentation, and they are automatically generated documentation. When I write Python or (apparently) Common Lisp, I can expect to get reasonable documentation by interrogating anything someone hands me. In Haskell, insofar as I have learned to get good information from the types, I get some (correct!) documentation for things that I have newly assembled myself!

newen 6y ago
I find type information for functions incredibly useful. I get so lost in Python code once it get past a certain size even after years of Python programming experience because of the its lack of ability to put a useful amount of structure into the code. After having programmed in Haskell for a while, I just miss tabbing a function and being able to see its type signature.
- dleslie 6y ago
  That, and more, is available in common lisp. * (describe #'+) #<FUNCTION +> [compiled function] Lambda-list: (&REST SB-KERNEL::NUMBERS) Declared type: (FUNCTION (&REST NUMBER) (VALUES NUMBER &OPTIONAL)) Derived type: (FUNCTION (&REST T) (VALUES NUMBER &OPTIONAL)) Documentation: Return the sum of its arguments. With no args, returns 0. Known attributes: foldable, flushable, unsafely-flushable, movable, commutative Source file: SYS:SRC;CODE;NUMBERS.LISP Docstrings and type information can (optionally, but recommended) be added to all code. Users of your API can use documentation/describe to discover information about it without ever having to look at the implementation.