5 ms·

Haskell has well known deficiences in its std lib (Prelude). I would make a conjecture that it's also true for Lisps (quality of std lib is poor often) and oth

Haskell has well known deficiences in its std lib (Prelude). I would make a conjecture that it's also true for Lisps (quality of std lib is poor often) and other powerful libraries. On other hand, languages of simpler kind, like Java or Python, have more adequate std libs. It's because, for a really powerful language std lib has to be opinionated. And people understand that but they can't agree on something. So they live with whatever common denominator. And lost a lot of traction there. A counterexample is Clojure where std lib is very nice if heavily skewed towards FP, reinforcing my point.

bos 10y ago
There have been numerous well-known problems with the Java and Python standard libraries over the years. For instance, the date/time classes in Java were a disaster for a long time, and Python has taken decades to converge on a nearly-good-enough treatment of strings.
- hyperpape 10y ago
  Java's stdlib is mindblowing in places. My favorite is the treatment of iteration. You have immutable collections that support an iterator interface that allows modification and throws a runtime exception (so much for a type system...). There is an interface that lets you iterate over the elements of something that supports it without allowing removal, but it's not recommended, and it doesn't enable the enhanced for loop that came with Java 1.5: https://docs.oracle.com/javase/7/docs/api/java/util/Enumeration.html https://docs.oracle.com/javase/7/docs/api/java/util/Enumerat.... It's as if someone said "how wrong can we get this?"
hyperpape 10y ago
I tend to disagree. On the one hand, parts of the Haskell prelude are quite opinionated. String as a linked list? That's an impressive sort of FP purity: you can write tail recursive functions, and there are people out there who find that thrilling. It's just horribly space and time inefficient. Other parts are just old. I've read that there the reason head throws an exception when applied to an empty list rather than a Maybe was because working with Maybes was much more painful when Haskell was first written. That's just ordinary backwards compatibility pain. Other parts just seem painful for no reason whatsoever. Lazy and Strict ByteStrings/Text are both named ByteString/Text. They just live in different namespaces, so when you see code that reads "Text -> a", the only way to distinguish it is to look at what's been imported. If you couldn't decide which was preferred, they should be "StrictText"/"LazyText" (and programmers would be free to import them as Text if they so desired). (Nevermind that Text, while essential, isn't actually part of the Prelude...).
- Chris_Newton 10y ago
  Other parts are just old. This must be the curse of writing a language that becomes successful enough to grow a significant user base. You will inevitably discover that some of your original decisions about language features or standard library designs aren’t ideal. However, even if you know a much better way now, you can’t just replace the existing version without breaking a lot of existing code. Worse, over time people will start writing their own libraries, and some of them will adopt the same flawed conventions as your standard library by default. C++ has long struggled with strings and text processing for similar reasons.
wyager 10y ago
Complaints about Haskell's prelude usually fall strictly under the definition of "first-world problems". "Ugh, this length function isn't parameterized over the integrals?" Or, alternatively: "Ugh, this length function is parameterized over the foldables?" People will never agree what's best, but it doesn't really matter. One nice thing about Haskell is that all the "default" functions, types, and data structures are just imported from the Prelude library. You can just import your own version if you want, and people do that.
- seagreen 10y ago
  I wish this was the case, but it's not. A bad string type and lots of partial functions are legitimate red flags, not "first world problems".
  - wyager 10y ago
    > A bad string type It's only bad in the sense that it's inefficient. It's preferable to most other string types in many ways. It's also totally reasonable to have in the prelude: [] is there, and Char is there, so really all they've done is slapped the two together. The current situation (importing ByteString or Text for performance) is pretty good IMO. Haskell doesn't have Map or Set or anything in the prelude, so I think it's reasonable to leave powerful packed text types out as well. In fact, I would even support leaving [] out of the prelude and making the import of Data.List explicit. > lots of partial functions are legitimate red flags This is true, but the fact that we're even complaining about this is a first-world problem. Other languages have partial behavior built in to the language. Try going to a python or java developer and telling them "array access should return an optional type instead of throwing an exception on out-of-bounds". This is totally reasonable to deal with in Haskell, but inconceivable in other languages.
    - seagreen 10y ago
      The current situation (importing ByteString or Text for performance) is pretty good IMO. Haskell doesn't have Map or Set or anything in the prelude, so I think it's reasonable to leave powerful packed text types out as well. Interesting. Maybe all we have is a community problem then? Since `String` is right there, and `Text` is both an additional dependency and an import away `String` gets used in situations it shouldn't. Try going to a python or java developer and telling them "array access should return an optional type instead of throwing an exception on out-of-bounds". Alright, I think we have synthesis. From a Python programmers perspective the Prelude issues are somewhat trivial. From a Haskell programmers perspective it's offensive to good engineering. So it depends on your perspective:)

bos 10y ago

There have been numerous well-known problems with the Java and Python standard libraries over the years. For instance, the date/time classes in Java were a disaster for a long time, and Python has taken decades to converge on a nearly-good-enough treatment of strings.

hyperpape 10y ago
Java's stdlib is mindblowing in places. My favorite is the treatment of iteration. You have immutable collections that support an iterator interface that allows modification and throws a runtime exception (so much for a type system...). There is an interface that lets you iterate over the elements of something that supports it without allowing removal, but it's not recommended, and it doesn't enable the enhanced for loop that came with Java 1.5: https://docs.oracle.com/javase/7/docs/api/java/util/Enumeration.html https://docs.oracle.com/javase/7/docs/api/java/util/Enumerat.... It's as if someone said "how wrong can we get this?"

hyperpape 10y ago

I tend to disagree. On the one hand, parts of the Haskell prelude are quite opinionated. String as a linked list? That's an impressive sort of FP purity: you can write tail recursive functions, and there are people out there who find that thrilling. It's just horribly space and time inefficient. Other parts are just old. I've read that there the reason head throws an exception when applied to an empty list rather than a Maybe was because working with Maybes was much more painful when Haskell was first written. That's just ordinary backwards compatibility pain. Other parts just seem painful for no reason whatsoever. Lazy and Strict ByteStrings/Text are both named ByteString/Text. They just live in different namespaces, so when you see code that reads "Text -> a", the only way to distinguish it is to look at what's been imported. If you couldn't decide which was preferred, they should be "StrictText"/"LazyText" (and programmers would be free to import them as Text if they so desired). (Nevermind that Text, while essential, isn't actually part of the Prelude...).

Chris_Newton 10y ago
Other parts are just old. This must be the curse of writing a language that becomes successful enough to grow a significant user base. You will inevitably discover that some of your original decisions about language features or standard library designs aren’t ideal. However, even if you know a much better way now, you can’t just replace the existing version without breaking a lot of existing code. Worse, over time people will start writing their own libraries, and some of them will adopt the same flawed conventions as your standard library by default. C++ has long struggled with strings and text processing for similar reasons.

wyager 10y ago

Complaints about Haskell's prelude usually fall strictly under the definition of "first-world problems". "Ugh, this length function isn't parameterized over the integrals?" Or, alternatively: "Ugh, this length function is parameterized over the foldables?" People will never agree what's best, but it doesn't really matter. One nice thing about Haskell is that all the "default" functions, types, and data structures are just imported from the Prelude library. You can just import your own version if you want, and people do that.

seagreen 10y ago
I wish this was the case, but it's not. A bad string type and lots of partial functions are legitimate red flags, not "first world problems".
- wyager 10y ago
  > A bad string type It's only bad in the sense that it's inefficient. It's preferable to most other string types in many ways. It's also totally reasonable to have in the prelude: [] is there, and Char is there, so really all they've done is slapped the two together. The current situation (importing ByteString or Text for performance) is pretty good IMO. Haskell doesn't have Map or Set or anything in the prelude, so I think it's reasonable to leave powerful packed text types out as well. In fact, I would even support leaving [] out of the prelude and making the import of Data.List explicit. > lots of partial functions are legitimate red flags This is true, but the fact that we're even complaining about this is a first-world problem. Other languages have partial behavior built in to the language. Try going to a python or java developer and telling them "array access should return an optional type instead of throwing an exception on out-of-bounds". This is totally reasonable to deal with in Haskell, but inconceivable in other languages.
  - seagreen 10y ago
    The current situation (importing ByteString or Text for performance) is pretty good IMO. Haskell doesn't have Map or Set or anything in the prelude, so I think it's reasonable to leave powerful packed text types out as well. Interesting. Maybe all we have is a community problem then? Since `String` is right there, and `Text` is both an additional dependency and an import away `String` gets used in situations it shouldn't. Try going to a python or java developer and telling them "array access should return an optional type instead of throwing an exception on out-of-bounds". Alright, I think we have synthesis. From a Python programmers perspective the Prelude issues are somewhat trivial. From a Haskell programmers perspective it's offensive to good engineering. So it depends on your perspective:)