27 ms·

Can you expand on all of these complaints? I've been using Haskell for about 9 years and none of these are things I've ever had a complaint about, except packag

by axman6 10y ago

Can you expand on all of these complaints? I've been using Haskell for about 9 years and none of these are things I've ever had a complaint about, except package management, which I find stack's solution works incredibly well in practice.

tmptmp 10y ago
Here are some that I have encountered: Which string to use? String, ByteString or Text or something else? How to convert between zillions of String types, which are, it seems, completely incompatible even though providing similar functionality? So much for the support of abstraction. Which library is good for doing X? It seems, like String, the Haskell provides too many experimental and/or incompatible and/or immature libraries to do many trivial things. Then there are issues of laziness combined with IO and you get a `seq` shenanigan. Then there are issues of laziness combined with inability to profile/debug and you get a `analysis` shenanigan. Then there are issues of laziness combined with inability to handle exceptions without great grand-daddy-catch-all-bad-things IO monad and you get a `IO monad exceptions` shenanigan. So, there are a lot of Haskell shenanigans, too. Take your pick.
- tmptmp 10y ago
  It's not to say Haskell is bad, though. I'd be a fool to say so. The above comment is mainly to point out that there are its shortcomings and that it has a lot to improve and most of the times I have seen the proponents of Haskell tend to downplay and to avoid talking about these shortcomings. In fact, I have learned a lot many good programming practices/principles by spending time to learn Haskell. I do apply some of those in my projects in other languages.
- joseph 10y ago
  I have found the same to be true whenever I've tried to do anything in Haskell, especially with regards to error handling. I would try to decide on a specific style of handling errors, but the libraries I depended on maybe did it differently. So there ended up being a lot of boilerplate code to wrap other libraries to my own particular style. A lot of the problems I encountered probably boiled down to inexperience on my part, and perhaps not understanding idiomatic ways of doing things in the language. But another part of it is that I think the community has not settled on a set of common idioms. There are things about Haskell that I absolutely love. The expressiveness is amazing. Chaining a monadic sequence can feel magical at times. Treating errors as just values is nice. But what do you do when the libraries that you depend on throw exceptions instead of using Either? And those awful compiler errors can be so, so frustrating. But I will return to you again one day, dear Haskell.
  - mercurial 10y ago
    > Chaining a monadic sequence can feel magical at times. The issue is when this monad is actually a monad transformer tower, in which case there is actually a bunch of "magic" happening at each line.
  - tome 10y ago
    > what do you do when the libraries that you depend on throw exceptions instead of using Either? File a bug on them
    - krotton 10y ago
      And wait forever instead of getting any actual work done.
  - dllthomas 10y ago
    > But what do you do when the libraries that you depend on throw exceptions instead of using Either? tome's response is amusing, but assuming you need to keep getting work done and aren't interested in forking the library... You wrap the library in a shim that forces the return values, catches anything that's thrown, and returns Either. If it's a library that you only use in one or two places, that shim might be inlined.
    - dllthomas 10y ago
      I should note that, where you prefer to be dealing with exceptions, it's trivial to go the other way with a shim as well.
- tene 10y ago
  I've never personally understood the exaggeration people use when talking about string types in Haskell. You say "zillions", but there's only really five. Five is the most disappointing "zillions" I've ever encountered. There's strict and lazy ByteString, which you should use whenever you're working with buffers of bytes that don't have any associated encoding and aren't text. There's strict and lazy Text, which you use for human-readable text that's decoded from some specific encoding, like ASCII or Unicode. There's String, which you use when interacting with an API that requires use of String, like anything in the language standard. It's certainly some amount of complexity, but it's not anywhere near as complex as I keep seeing claimed, unless I'm missing something. It's certainly ugly that we still have to deal with String, and that's a notable wart on the language, but I rarely even think about it. One guess I've had about part of the confusion is that ByteString has the word "String" in it, which might make people assume that it's for text. A better name would be "Buffer" or "Bytes". I've also speculated that maybe part of the complexity is having to explicitly encode and decode to get Text, instead of the implicit coercion you get in other languages that freely mix bytes and text. If you want a greatly simplified way to unify string conversion, you can use string-conv. https://hackage.haskell.org/package/string-conv-0.1/docs/Data-String-Conv.html https://hackage.haskell.org/package/string-conv-0.1/docs/Dat... Edited to add: it's been pointed out to me that "zillions" might not have actually been a claim that there's enough string types actually keep track of them, but is probably just hyperbole to express some frustration. If that's the case, my apologies for my failure at reading comprehension.
  - bunderbunder 10y ago
    The optimal number of core string types for a language to have is one. Python got to two, and the community decided that was enough of a PITA to merit a breaking change in the language in order to get back down to one. C++ also has two, but we put up with it because it's C++ so really we're just thankful it's not three or four. Five is so far beyond the pale that it is absolutely reasonable to hyperbolize it as "zillions".
    - tene 10y ago
      ByteString isn't really a "string" type; it's a byte buffer. It's not about text. I think that it's entirely reasonable to have a dedicated "Text" type that works with decoded human text, separate from buffers of bytes. I also think that it's entirely reasonable to have lazy and strict variants of core data types; they have very different time/space tradeoffs. It's definitely frustrating that the core language definition has a data type "String" that's a pretty bad choice for almost any application (it's a linked list of characters), and that's a legitimate problem, but I think an accurate characterization of the real problem with string data types in Haskell is much more like "You should be able to use Text everywhere to deal with decoded unicode text, but for unfortunate legacy reasons you have to use String to interact with large parts of the standard library". Treating all bytes as if they happen to accidentally represent utf-8 encoded unicode text would be a big mistake; there's significant advantages to representing text and byte buffers separately. They are very different things. Choosing to support only strict or only lazy handling of byte buffers or text would be quite unfortunate; there are significant advantages to both for different algorithms and use cases, and encoding the difference in the type system seems entirely reasonable to me. I'm curious which of these you disagree with. Would you prefer that Text and ByteString be merged into one data type, so that the compiler doesn't consider it a mistake to treat arbitrary bytes as if it were text without specifying any encoding? Would you prefer that Text and/or ByteString discard support for lazy representation, or for strict representation?
- deleted 10y ago
  [deleted]
- tome 10y ago
  > Which library is good for doing X? https://haskelliseasy.readthedocs.io/en/latest/ https://haskelliseasy.readthedocs.io/en/latest/

by axman6 10y ago

tmptmp 10y ago

Here are some that I have encountered: Which string to use? String, ByteString or Text or something else? How to convert between zillions of String types, which are, it seems, completely incompatible even though providing similar functionality? So much for the support of abstraction. Which library is good for doing X? It seems, like String, the Haskell provides too many experimental and/or incompatible and/or immature libraries to do many trivial things. Then there are issues of laziness combined with IO and you get a `seq` shenanigan. Then there are issues of laziness combined with inability to profile/debug and you get a `analysis` shenanigan. Then there are issues of laziness combined with inability to handle exceptions without great grand-daddy-catch-all-bad-things IO monad and you get a `IO monad exceptions` shenanigan. So, there are a lot of Haskell shenanigans, too. Take your pick.

tmptmp 10y ago
It's not to say Haskell is bad, though. I'd be a fool to say so. The above comment is mainly to point out that there are its shortcomings and that it has a lot to improve and most of the times I have seen the proponents of Haskell tend to downplay and to avoid talking about these shortcomings. In fact, I have learned a lot many good programming practices/principles by spending time to learn Haskell. I do apply some of those in my projects in other languages.
joseph 10y ago
I have found the same to be true whenever I've tried to do anything in Haskell, especially with regards to error handling. I would try to decide on a specific style of handling errors, but the libraries I depended on maybe did it differently. So there ended up being a lot of boilerplate code to wrap other libraries to my own particular style. A lot of the problems I encountered probably boiled down to inexperience on my part, and perhaps not understanding idiomatic ways of doing things in the language. But another part of it is that I think the community has not settled on a set of common idioms. There are things about Haskell that I absolutely love. The expressiveness is amazing. Chaining a monadic sequence can feel magical at times. Treating errors as just values is nice. But what do you do when the libraries that you depend on throw exceptions instead of using Either? And those awful compiler errors can be so, so frustrating. But I will return to you again one day, dear Haskell.
- mercurial 10y ago
  > Chaining a monadic sequence can feel magical at times. The issue is when this monad is actually a monad transformer tower, in which case there is actually a bunch of "magic" happening at each line.
- tome 10y ago
  > what do you do when the libraries that you depend on throw exceptions instead of using Either? File a bug on them
  - krotton 10y ago
    And wait forever instead of getting any actual work done.
- dllthomas 10y ago
  > But what do you do when the libraries that you depend on throw exceptions instead of using Either? tome's response is amusing, but assuming you need to keep getting work done and aren't interested in forking the library... You wrap the library in a shim that forces the return values, catches anything that's thrown, and returns Either. If it's a library that you only use in one or two places, that shim might be inlined.
  - dllthomas 10y ago
    I should note that, where you prefer to be dealing with exceptions, it's trivial to go the other way with a shim as well.
tene 10y ago
I've never personally understood the exaggeration people use when talking about string types in Haskell. You say "zillions", but there's only really five. Five is the most disappointing "zillions" I've ever encountered. There's strict and lazy ByteString, which you should use whenever you're working with buffers of bytes that don't have any associated encoding and aren't text. There's strict and lazy Text, which you use for human-readable text that's decoded from some specific encoding, like ASCII or Unicode. There's String, which you use when interacting with an API that requires use of String, like anything in the language standard. It's certainly some amount of complexity, but it's not anywhere near as complex as I keep seeing claimed, unless I'm missing something. It's certainly ugly that we still have to deal with String, and that's a notable wart on the language, but I rarely even think about it. One guess I've had about part of the confusion is that ByteString has the word "String" in it, which might make people assume that it's for text. A better name would be "Buffer" or "Bytes". I've also speculated that maybe part of the complexity is having to explicitly encode and decode to get Text, instead of the implicit coercion you get in other languages that freely mix bytes and text. If you want a greatly simplified way to unify string conversion, you can use string-conv. https://hackage.haskell.org/package/string-conv-0.1/docs/Data-String-Conv.html https://hackage.haskell.org/package/string-conv-0.1/docs/Dat... Edited to add: it's been pointed out to me that "zillions" might not have actually been a claim that there's enough string types actually keep track of them, but is probably just hyperbole to express some frustration. If that's the case, my apologies for my failure at reading comprehension.
- bunderbunder 10y ago
  The optimal number of core string types for a language to have is one. Python got to two, and the community decided that was enough of a PITA to merit a breaking change in the language in order to get back down to one. C++ also has two, but we put up with it because it's C++ so really we're just thankful it's not three or four. Five is so far beyond the pale that it is absolutely reasonable to hyperbolize it as "zillions".
  - tene 10y ago
    ByteString isn't really a "string" type; it's a byte buffer. It's not about text. I think that it's entirely reasonable to have a dedicated "Text" type that works with decoded human text, separate from buffers of bytes. I also think that it's entirely reasonable to have lazy and strict variants of core data types; they have very different time/space tradeoffs. It's definitely frustrating that the core language definition has a data type "String" that's a pretty bad choice for almost any application (it's a linked list of characters), and that's a legitimate problem, but I think an accurate characterization of the real problem with string data types in Haskell is much more like "You should be able to use Text everywhere to deal with decoded unicode text, but for unfortunate legacy reasons you have to use String to interact with large parts of the standard library". Treating all bytes as if they happen to accidentally represent utf-8 encoded unicode text would be a big mistake; there's significant advantages to representing text and byte buffers separately. They are very different things. Choosing to support only strict or only lazy handling of byte buffers or text would be quite unfortunate; there are significant advantages to both for different algorithms and use cases, and encoding the difference in the type system seems entirely reasonable to me. I'm curious which of these you disagree with. Would you prefer that Text and ByteString be merged into one data type, so that the compiler doesn't consider it a mistake to treat arbitrary bytes as if it were text without specifying any encoding? Would you prefer that Text and/or ByteString discard support for lazy representation, or for strict representation?
deleted 10y ago
[deleted]
tome 10y ago
> Which library is good for doing X? https://haskelliseasy.readthedocs.io/en/latest/ https://haskelliseasy.readthedocs.io/en/latest/