3 ms·

Dragging Haskell Kicking and Screaming into the Century of the Fruitbat

15 points by jessaustin 5y ago

rwmj 5y ago
> things like how head is antithetical to everything we like about Haskell What does this mean?
- jim-jim-jim 5y ago
  `head` throws a runtime error when used on an empty list, where it should really return a value wrapped in `Maybe` instead. This is some accident of history afaik.
- Zababa 5y ago
  'head' is a function that returns the first element of a list. On empty lists, it raises an exception. I'm not sure what's the origin of this, I know that standard ML also does that. The thing is that ~20 years ago exceptions in functional programming languages were seen as something normal, whereas these days people tend to prefer sum types. So what they would want is for head on a list of number to return a Maybe number, which can be Just number, or Nothing. This would allow the compiler to check for errors, and allow for easier composition since Maybe is monadic (if you don't know what monads are, think of them as an ubiquitous interface, like Iterator in another language).
ok_dad 5y ago
I would pay money for a Haskell that wasn’t always backwards compatible and got rid of the old and useless or old and broken things like head and etc. As it is I really want to like Haskell, but it’s too hard to separate the wheat from the chaff.
- throwaway81523 5y ago
  You might try a newer Haskell dialect like Purescript.
  - ok_dad 5y ago
    I tried it but the tooling was not great. No IDE support last time I used it and it only compiles to JS.
    - throwaway81523 5y ago
      Idris maybe? I agree Purescript's npm dependence makes it unattractive, but it does have some other backends besides JS. I haven't worried about IDE's much for Haskell. They just haven't seened important.
throwaway81523 5y ago
Btw we had a thread about this last month when it went up (Nov 12). It's the post about among other things removing (/=) from the Eq typeclass. It is kind of a yawner imho.
eyelidlessness 5y ago
I don't have a dog in any of the fights that might be picked here, but I will say that while I admire the author's steel-man approach (and I'm glad to have learned that term reading this article), the conclusion sounds an awful lot like Python 3. And some lessons from that should be anticipated.
- Zababa 5y ago
  The big difference here is the cost: > In the particular example of (/=), there isn’t even any cost. There are ~50 packages that define (/=), and the solution is just to delete those definitions. Yes, it’s churn, but I personally am willing to send a patch to each package. If you’re the maintainer of such a package, email me and I’ll just go fix it for you. The author also developped a semi-automatic tool for this migration: https://reasonablypolymorphic.com/blog/comby/ https://reasonablypolymorphic.com/blog/comby/. While as some people said, breakage is breakage, having a very easy migration path helps with that. However, there's one point that isn't talked about here: code that doesn't get update often. Lots of small changes like that can be very annoying for code like that, but I don't see a good solution here (except to never deprecate anything).
  - eyelidlessness 5y ago
    To be clear, this is the part that sounds like Python 3 to me: > Since we’re just about to break things, might I again suggest we add Foldable1, and clean up Prelude? If breakage is breakage (it is), we might as well take advantage of it and do as much cleanup as possible. This is an excellent opportunity. The status-quo is for all of us to argue about it every week, with half the people saying “these are bad circumstances and we should fix them,” with the other half saying “yes, they are bad circumstances, but breakage is worse.” > But given that we now have breakage, let’s make the most of it. I don’t know how costly that larger scope is. Maybe it’s similarly low to this one change?

15 points by jessaustin 5y ago

rwmj 5y ago

> things like how head is antithetical to everything we like about Haskell What does this mean?

jim-jim-jim 5y ago
`head` throws a runtime error when used on an empty list, where it should really return a value wrapped in `Maybe` instead. This is some accident of history afaik.
Zababa 5y ago
'head' is a function that returns the first element of a list. On empty lists, it raises an exception. I'm not sure what's the origin of this, I know that standard ML also does that. The thing is that ~20 years ago exceptions in functional programming languages were seen as something normal, whereas these days people tend to prefer sum types. So what they would want is for head on a list of number to return a Maybe number, which can be Just number, or Nothing. This would allow the compiler to check for errors, and allow for easier composition since Maybe is monadic (if you don't know what monads are, think of them as an ubiquitous interface, like Iterator in another language).

ok_dad 5y ago

I would pay money for a Haskell that wasn’t always backwards compatible and got rid of the old and useless or old and broken things like head and etc. As it is I really want to like Haskell, but it’s too hard to separate the wheat from the chaff.

throwaway81523 5y ago
You might try a newer Haskell dialect like Purescript.
- ok_dad 5y ago
  I tried it but the tooling was not great. No IDE support last time I used it and it only compiles to JS.
  - throwaway81523 5y ago
    Idris maybe? I agree Purescript's npm dependence makes it unattractive, but it does have some other backends besides JS. I haven't worried about IDE's much for Haskell. They just haven't seened important.

throwaway81523 5y ago

Btw we had a thread about this last month when it went up (Nov 12). It's the post about among other things removing (/=) from the Eq typeclass. It is kind of a yawner imho.

eyelidlessness 5y ago

I don't have a dog in any of the fights that might be picked here, but I will say that while I admire the author's steel-man approach (and I'm glad to have learned that term reading this article), the conclusion sounds an awful lot like Python 3. And some lessons from that should be anticipated.

Zababa 5y ago
The big difference here is the cost: > In the particular example of (/=), there isn’t even any cost. There are ~50 packages that define (/=), and the solution is just to delete those definitions. Yes, it’s churn, but I personally am willing to send a patch to each package. If you’re the maintainer of such a package, email me and I’ll just go fix it for you. The author also developped a semi-automatic tool for this migration: https://reasonablypolymorphic.com/blog/comby/ https://reasonablypolymorphic.com/blog/comby/. While as some people said, breakage is breakage, having a very easy migration path helps with that. However, there's one point that isn't talked about here: code that doesn't get update often. Lots of small changes like that can be very annoying for code like that, but I don't see a good solution here (except to never deprecate anything).
- eyelidlessness 5y ago
  To be clear, this is the part that sounds like Python 3 to me: > Since we’re just about to break things, might I again suggest we add Foldable1, and clean up Prelude? If breakage is breakage (it is), we might as well take advantage of it and do as much cleanup as possible. This is an excellent opportunity. The status-quo is for all of us to argue about it every week, with half the people saying “these are bad circumstances and we should fix them,” with the other half saying “yes, they are bad circumstances, but breakage is worse.” > But given that we now have breakage, let’s make the most of it. I don’t know how costly that larger scope is. Maybe it’s similarly low to this one change?