4 ms·

The Foldable instance for Maybe is one of the biggest warts in Haskell. It's not limited to Haskell, by the way. def getUsers(f): return (logged_i

by tome 6y ago

The Foldable instance for Maybe is one of the biggest warts in Haskell. It's not limited to Haskell, by the way. def getUsers(f): return (logged_in_users(f), logged_out_users(f)) def userCount(f): return len(getUsers(f))

q3k 6y ago
Sure, but Python and Python developers don’t hype up its type system to be the solution to all your programming woes :).
- tome 6y ago
  I'm not sure what "Haskell developers" are saying, but this Haskell developer says "Haskell provides many tools that can be used to solve programming woes. One such tool is its strong and flexible types system (there are several other tools, such as immutability, functional style)."
  - Kednicma 6y ago
    And Python provides readable syntax. Your example has an easy-to-spot bug, just from reading the code and knowing Python's semantics. Haskell's "programmable semicolon" ends up being a problem here because, thanks to typeclasses, the programmer usually does not know which semicolon they are programming under! "Python provides many tools that can be used to solve programming woes. One such tool is its strong and readable syntax." Do you see how empty this sort of platitude is?
    - tome 6y ago
      I didn't intend to make this into a competition between Haskell and Python.
    - gtf21 6y ago
      I don't think that illustrates that promotion of the type system as a useful tool is an "empty platitude". A well constructed syntax is certainly a nice feature of a programming language. One might say a language like brainfuck does not have a syntax which makes the code easily readable, and therefore is the worse for it. Similarly, one might say that a strong type system is a useful tool. That doesn't make it a panacea (and I don't think that this was the claim), but that doesn't mean one can't appreciate it as a good tool.
    - ghostwriter 6y ago
      The problem with this comparison is that readable syntax is a subjective notion, whereas type system is an objective thing that can be evaluated based on its strictly defined boundaries - it's either possible or impossible to encode all required software specification with a provided type system, and if something is not possible, we know exactly what are these things that don't fit into the type system, and therefore we cannot rely on the compiler to prove their correctness.
    - wk_end 6y ago
      Er, the difference here is that we're given the Python code for `getUsers` but not the Haskell code for it. That makes the error in Python obvious. The incorrect `userCount` in Python looks just as obviously correct as the incorrect `userCount` in Haskell; and conversely, if we were given the code for the Haskell `getUsers` (or even just the type signature!) the error would be just as easy to spot.
4WIW 6y ago
To make this code clearer: def get_users(f) -> Tuple[List, List]: return (logged_in_users(f), logged_out_users(f)) def user_count(f) -> int: return len(get_users()) Now it's clear this is just wrong code. To fix it: def get_users(f) -> List: return logged_in_users(f) + logged_out_users(f) def user_count(f) -> int: return len(get_users())
- wk_end 6y ago
  That doesn't really "fix it". Even assuming there are no other callers of `get_users` that you might be breaking here (possibly silently, since lists and tuples in Python have overlapping interfaces), you're making `get_users` less useful by dropping structure that at least someone, at some point, thought was useful. Also, you should annotate the type of your lists :) def get_users(f) -> Tuple[List[User], List[User]]: return (logged_in_users(f), logged_out_users(f)) def user_count(f) -> int: logged_in_users, logged_out_users = get_users() return len(logged_in_users) + len(logged_out_users)
vindarel 6y ago
That's why Lisp has multiple return values, which are different from returning a tuple. It's great for refactoring. (https://lispcookbook.github.io/cl-cookbook/functions.html#multiple-return-values-values-multiple-value-bind-and-nth-value https://lispcookbook.github.io/cl-cookbook/functions.html#mu...)

by tome 6y ago

q3k 6y ago

Sure, but Python and Python developers don’t hype up its type system to be the solution to all your programming woes :).

tome 6y ago
I'm not sure what "Haskell developers" are saying, but this Haskell developer says "Haskell provides many tools that can be used to solve programming woes. One such tool is its strong and flexible types system (there are several other tools, such as immutability, functional style)."
- Kednicma 6y ago
  And Python provides readable syntax. Your example has an easy-to-spot bug, just from reading the code and knowing Python's semantics. Haskell's "programmable semicolon" ends up being a problem here because, thanks to typeclasses, the programmer usually does not know which semicolon they are programming under! "Python provides many tools that can be used to solve programming woes. One such tool is its strong and readable syntax." Do you see how empty this sort of platitude is?
  - tome 6y ago
    I didn't intend to make this into a competition between Haskell and Python.
  - gtf21 6y ago
    I don't think that illustrates that promotion of the type system as a useful tool is an "empty platitude". A well constructed syntax is certainly a nice feature of a programming language. One might say a language like brainfuck does not have a syntax which makes the code easily readable, and therefore is the worse for it. Similarly, one might say that a strong type system is a useful tool. That doesn't make it a panacea (and I don't think that this was the claim), but that doesn't mean one can't appreciate it as a good tool.
  - ghostwriter 6y ago
    The problem with this comparison is that readable syntax is a subjective notion, whereas type system is an objective thing that can be evaluated based on its strictly defined boundaries - it's either possible or impossible to encode all required software specification with a provided type system, and if something is not possible, we know exactly what are these things that don't fit into the type system, and therefore we cannot rely on the compiler to prove their correctness.
  - wk_end 6y ago
    Er, the difference here is that we're given the Python code for `getUsers` but not the Haskell code for it. That makes the error in Python obvious. The incorrect `userCount` in Python looks just as obviously correct as the incorrect `userCount` in Haskell; and conversely, if we were given the code for the Haskell `getUsers` (or even just the type signature!) the error would be just as easy to spot.

4WIW 6y ago

To make this code clearer: def get_users(f) -> Tuple[List, List]: return (logged_in_users(f), logged_out_users(f)) def user_count(f) -> int: return len(get_users()) Now it's clear this is just wrong code. To fix it: def get_users(f) -> List: return logged_in_users(f) + logged_out_users(f) def user_count(f) -> int: return len(get_users())

wk_end 6y ago
That doesn't really "fix it". Even assuming there are no other callers of `get_users` that you might be breaking here (possibly silently, since lists and tuples in Python have overlapping interfaces), you're making `get_users` less useful by dropping structure that at least someone, at some point, thought was useful. Also, you should annotate the type of your lists :) def get_users(f) -> Tuple[List[User], List[User]]: return (logged_in_users(f), logged_out_users(f)) def user_count(f) -> int: logged_in_users, logged_out_users = get_users() return len(logged_in_users) + len(logged_out_users)

vindarel 6y ago

That's why Lisp has multiple return values, which are different from returning a tuple. It's great for refactoring. (https://lispcookbook.github.io/cl-cookbook/functions.html#multiple-return-values-values-multiple-value-bind-and-nth-value https://lispcookbook.github.io/cl-cookbook/functions.html#mu...)