Haskell: The Bad Parts, part 2 (2020)

Re:Haskell: The Bad Parts, part 2 (2020) by tikhonj on Tuesday February 09, 2021 @06:14PM (#26083801)

The practical problem is that backwards compatibility and making real improvements to the language are fundamentally at odds. There's just no way around it. If you can't break compatibility, you can't make meaningful improvements except for adding features and capabilities—and most of the problems in this article are about things that need to be taken away, not things that need to be added!

[ Parent | on HN ]

Re:Haskell: The Bad Parts, part 2 (2020) by willtim on Wednesday February 10, 2021 @11:43AM (#26091482)

I was responding to "Can Haskell evolve?", I was trying to say "I think it can, but I would prefer it to evolve in a new language". The standard library is riddled with partial functions, like head and tail. We should not take them away and break thousands of projects, research papers, books and blog articles.

[ Parent | on HN ]

Re:Haskell: The Bad Parts, part 2 (2020) by tome on Wednesday February 10, 2021 @12:12PM (#26091912)

> We should not take them away and break thousands of projects

How about the middle ground of marking them as deprecated and not to be used in new code?

[ Parent | on HN ]

Re:Haskell: The Bad Parts, part 2 (2020) by dllthomas on Monday February 22, 2021 @04:26AM (#26222435)

And I mean, they're perfectly suitable for futzing around in ghci. I think we need different preludes for different contexts.

[ Parent | on HN ]

Re:Haskell: The Bad Parts, part 2 (2020) by willtim on Wednesday February 10, 2021 @12:51PM (#26092447)

Yes, deprecation is fine, as long as they are not removed.

[ Parent | on HN ]