5 ms·

I would be interested in seeing a similar list for Haskell. Like OCaml, it's a great language, but definitely has a few long-standing warts that could be fixed.

I would be interested in seeing a similar list for Haskell. Like OCaml, it's a great language, but definitely has a few long-standing warts that could be fixed. (Among these, the many competing streaming libraries and cabal hell come to mind. Though maybe the first ain't so bad, since they are all pretty high-quality.)

tel 12y ago
I think there's a big difference between language issues (which are routinely being worked on) and community questions like the pipes libraries and cabal. Probably the two biggest problems, both of which are currently being worked on, is a solution to true modules/modular dependencies (which is highly beneficial to fixing the community problem of cabal hell) and a solution to the "record problem" which is probably going to come in a new GHC extension which automatically allows for structural subtyping on public records via row types.
- plinkplonk 12y ago
  "Probably the two biggest problems, both of which are currently being worked on, is a solution to true modules/modular dependencies " I'm looking forward to this. I have Haskell code in production and would greatly appreciate these features. Is there a url where I can check/follow for the state of these efforts? Who is working on these? Thanks in advance.
  - tel 12y ago
    Edward Z Yang[0] is doing a GSoC project (I think) on expanding Backpack[1][2]. He's a GHC contributor, so it's relatively big. And here's overloaded record syntax: http://www.well-typed.com/blog/84/ http://www.well-typed.com/blog/84/ [0]http://ezyang.com/ http://ezyang.com/ [1]http://plv.mpi-sws.org/backpack/ http://plv.mpi-sws.org/backpack/ [2]http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-global-uniqueness/ http://blog.ezyang.com/2014/07/type-classes-confluence-coher...
- PieSquared 12y ago
  Disclaimer: This sounds critical of Haskell and may seem like disagreeing with what you're saying, but neither of those are intended. I agree with what you said, and use Haskell almost exclusively for programming. Completely agreed on the difference between language issues and community issues. From my perspective, the Haskell community does great with language issues. With GHC 7.10 we'll have AMP and OverloadedRecordFields, and I've seen a ton of work go into getting GHC ready for something like Backpack (throughout this summer). I think eventually these things will be solidified into a Haskell2018 or something, at which point a lot of the issues with Haskell-the-language that I've encountered when writing industry-style code will be gone. And I think that's great, and points to a bright future for Haskell; I don't think any other language has ever made me excited by the pace of progress in the language itself. (Some may say that in other languages you don't need to be excited by the next compiler release because the current one is good enough, but all languages have warts and deficiencies -- I think the GHC devs and the Haskell community do a great job finding these and trying to find clever and principled ways of improving them. See OverloadedRecordFields.) However, I think community questions like the pipes libraries , cabal hell (to a lesser extent -- I think this is partially a tech problem that Backpack-like modules will solve), problems with the Prelude, etc, are an even bigger issue. Sadly, I think those issues are actually much harder. For instance, in the Haskell community, we constantly have issues with Strings being the default datatype for text, because Strings are just [Char]. This is a pretty terrible model for text most of the time (not all of the time, but most of the time). However, changing this requires not only changing the base library, but also hundreds of other libraries on Hackage. Some of these are likely unmaintained, and would break and stay broken. There are many ways in which I think the Haskell Prelude could be fixed (String -> Text conversion, fmap -> map and mappend -> ++ renaming, getting rid of confusing Control.* and Data.* heirarchies, etc), but the undertaking is gargantuan, because any of these changes would affect hundreds of libraries (some now unmaintained) in the ecosystem. And because of this, I've seen no plans or proposals on how Haskell should handle these sorts of changes. Fixing Prelude is just one of the more difficult "community questions". We have a proliferation of very similar but competing libraries, which in some ways is good (people have choice, different libraries can make different design decisions, etc), but in some ways is bad (if I write a library that does streaming, I have to make a pipes version and a conduit version, or choose one). Again, Backpack modules will help here. Same goes for Haskell-to-Javascript compilers. However, with many of these, I think time will tell -- we have multiple options that are constantly evolving because we haven't really figured out the "right" way to do things yet, and eventually things will settle down. As always, some of the hardest problems in programming are not actually coding problems, but people problems. Hopefully we can find a way going forward to find solutions to those as well.

tel 12y ago

I think there's a big difference between language issues (which are routinely being worked on) and community questions like the pipes libraries and cabal. Probably the two biggest problems, both of which are currently being worked on, is a solution to true modules/modular dependencies (which is highly beneficial to fixing the community problem of cabal hell) and a solution to the "record problem" which is probably going to come in a new GHC extension which automatically allows for structural subtyping on public records via row types.

plinkplonk 12y ago
"Probably the two biggest problems, both of which are currently being worked on, is a solution to true modules/modular dependencies " I'm looking forward to this. I have Haskell code in production and would greatly appreciate these features. Is there a url where I can check/follow for the state of these efforts? Who is working on these? Thanks in advance.
- tel 12y ago
  Edward Z Yang[0] is doing a GSoC project (I think) on expanding Backpack[1][2]. He's a GHC contributor, so it's relatively big. And here's overloaded record syntax: http://www.well-typed.com/blog/84/ http://www.well-typed.com/blog/84/ [0]http://ezyang.com/ http://ezyang.com/ [1]http://plv.mpi-sws.org/backpack/ http://plv.mpi-sws.org/backpack/ [2]http://blog.ezyang.com/2014/07/type-classes-confluence-coherence-global-uniqueness/ http://blog.ezyang.com/2014/07/type-classes-confluence-coher...
PieSquared 12y ago
Disclaimer: This sounds critical of Haskell and may seem like disagreeing with what you're saying, but neither of those are intended. I agree with what you said, and use Haskell almost exclusively for programming. Completely agreed on the difference between language issues and community issues. From my perspective, the Haskell community does great with language issues. With GHC 7.10 we'll have AMP and OverloadedRecordFields, and I've seen a ton of work go into getting GHC ready for something like Backpack (throughout this summer). I think eventually these things will be solidified into a Haskell2018 or something, at which point a lot of the issues with Haskell-the-language that I've encountered when writing industry-style code will be gone. And I think that's great, and points to a bright future for Haskell; I don't think any other language has ever made me excited by the pace of progress in the language itself. (Some may say that in other languages you don't need to be excited by the next compiler release because the current one is good enough, but all languages have warts and deficiencies -- I think the GHC devs and the Haskell community do a great job finding these and trying to find clever and principled ways of improving them. See OverloadedRecordFields.) However, I think community questions like the pipes libraries , cabal hell (to a lesser extent -- I think this is partially a tech problem that Backpack-like modules will solve), problems with the Prelude, etc, are an even bigger issue. Sadly, I think those issues are actually much harder. For instance, in the Haskell community, we constantly have issues with Strings being the default datatype for text, because Strings are just [Char]. This is a pretty terrible model for text most of the time (not all of the time, but most of the time). However, changing this requires not only changing the base library, but also hundreds of other libraries on Hackage. Some of these are likely unmaintained, and would break and stay broken. There are many ways in which I think the Haskell Prelude could be fixed (String -> Text conversion, fmap -> map and mappend -> ++ renaming, getting rid of confusing Control.* and Data.* heirarchies, etc), but the undertaking is gargantuan, because any of these changes would affect hundreds of libraries (some now unmaintained) in the ecosystem. And because of this, I've seen no plans or proposals on how Haskell should handle these sorts of changes. Fixing Prelude is just one of the more difficult "community questions". We have a proliferation of very similar but competing libraries, which in some ways is good (people have choice, different libraries can make different design decisions, etc), but in some ways is bad (if I write a library that does streaming, I have to make a pipes version and a conduit version, or choose one). Again, Backpack modules will help here. Same goes for Haskell-to-Javascript compilers. However, with many of these, I think time will tell -- we have multiple options that are constantly evolving because we haven't really figured out the "right" way to do things yet, and eventually things will settle down. As always, some of the hardest problems in programming are not actually coding problems, but people problems. Hopefully we can find a way going forward to find solutions to those as well.