10 ms·

As others have said, it's not nearly as bad anymore as It was when Bob wrote that post, but I would say, please do not take that as a reason to not take what he

As others have said, it's not nearly as bad anymore as It was when Bob wrote that post, but I would say, please do not take that as a reason to not take what he says very seriously. I use haskell because it is a very practical tool, (bona fides: I am an experienced haskell developer and I actually use it full time for my job---not an armchair evangelist) but it has become very clear to me that the next great thing will be more like ML than like Haskell. There are of course many important lessons to be learned from Haskell though!

bronxbomber92 12y ago
Could you expand on why you think the next "great thing" will be more like ML than like Haskell?
- jonsterling 12y ago
  1. Call-by-value gives us both the ability reason by induction. It also typically results in the presence of non-pointed types, whereas Haskell only has pointed types. 2. Call-by-value gives us the ability to safely interleave effects. Now, I know you all think we should not be doing that at all, but I would say that this is only true in some cases. The point of reifying an effect in a monad is not because "effects are icky"; it is because we have written a non-extensional operation using effects, and we want it to be an extensional function. Wrapping it up in the monad "completes" the operation as such. However, there are plenty of extensional functions which may be written using computational effects (such as memoization): these should not be wrapped up in the monad. (FYI, it's the effects that preserve extensionality which is what Bob calls "benign effects", to the consternation of Haskell developers everywhere.) ML gives us the fine-grainedness to make these choices, at the cost of some reasoning facilities: more proofs must be done on paper, or in an external logical framework. I tend to think that the latter is inevitable, but some disagree. I am hoping for a middle-ground then: something like ML, in that effects are fundamental and not just bolted onto the language with a stack of monads; something like Haskell, where we can tell what effects are being used by a piece of code. The story hasn't been fully written on this, but I think that Call-by-push-value can help us with both recovering the benefits of laziness as well as reasoning about effects. 3. Modularity is something which Haskell people simply do not take seriously, even with the new "backpack" package-level module system they are building. One of the most-loved reasoning facilities present in Haskell depends, believe it or not, on global scope, and is therefore inherently anti-modular (this is the uniqueness of type class instances). As a result, you can never add modularity to Haskell, but we may be able to back-port some of the more beloved aspects of Haskell to a new nephew in the ML family. (Confusingly, laziness advocates often say that their brand of functional programming has better "modularity" than strict, because of the way that you can compose lazy algorithms to get more lazy algorithms that don't totally blow up in complexity. I would say that lazy languages are more "compositional", not more "modular"—I prefer to use the latter term for modularity at the level of architecture and systems design, not algorithms.)
  - tel 12y ago
    Could you expand on effects which preserve extensionality some more? I'm fairly sure I understand it, but I've never quite follows what Harper's "benign effects" meant in detail and I'd like to see how it all connects.
    - jonsterling 12y ago
      The most benign effect of them all is laziness. Haskell uses this in lieu of all other effects, basically. So memoizing data structures, or a higher order function for memoizing, utilizes a "benign effect".
      - tel 12y ago
        So extensionally equal simply means that there is a model with and without the effect such that extensionally, according to some model of observation, we cannot discern the existence of the effect? So, laziness is benign in total fragments.
        jonsterling 12y ago
        I wasn't thinking about models, but perhaps you could? I just mean that you get the same results for equal inputs; laziness is fine in this respect (but not in the presence of some other effects).
  - tel 12y ago
    I would love to see a "practical" CBPV language.
    - tome 12y ago
      Likewise, mostly because it would probably help me understand what CBPV actually is!
      - tel 12y ago
pjmlp 12y ago
Haskell belongs to the ML language family.
- coldtea 12y ago
  I'd bet that he knows that already. And C++ belongs to the C language family, but one could still say something like "the next great thing would come from a C rather than a C++ like language" (I'm not judging if this is true here, just that it's quite clear what it means).
  - pjmlp 12y ago
    No, because you can have other ML derived languages that are also lazy and strict, without being necessarily based on Haskell.
- pfh 12y ago
  and there is no such thing as a fish.
- ufo 12y ago
  He's probably saying that he things the next big thing will be strict by default and feature a neat module system.
  - jonsterling 12y ago
    Yes, that's close! I also think that we'll need a better treatment of effects than either ML or Haskell can give us, but I hope to have something that has been carefully thought about, rather than bolted on like Haskell's effects. It sounds like call-by-push-value gives a nice unifying approach to CBN/CBV and also effects. I am hoping that something interesting will come out of that work.
    - tome 12y ago
      It's been about 15 years since CBPV was proposed. Has there been any work on actually making a practical language along those lines?
CmonDev 12y ago
"the next great thing will be more like ML" ocaML or even better F#?
- progman 12y ago
  I wonder if Ocaml is actually much more practical than Haskell. Ocaml has been proven to be well usable in industry while Haskell seems to be suitable for research areas like math and language design. http://mirror.ocamlcore.org/wiki.cocan.org/companies.html http://mirror.ocamlcore.org/wiki.cocan.org/companies.html http://www.infoq.com/presentations/jane-street-caml-ocaml http://www.infoq.com/presentations/jane-street-caml-ocaml http://queue.acm.org/detail.cfm?id=2038036&ref=fullrss http://queue.acm.org/detail.cfm?id=2038036&ref=fullrss
  - ZenoArrow 12y ago
    I'm learning F# right now, it's flipping excellent! From what I understand it's similar to Ocaml, but has some other features that give it the edge (for me at least). I did try to learn Ocaml at one point, but I was put off by the standard library variation (the default one apparently has numerous shortcomings, Batteries project extends it and Core project aims to replace it, but neither one is the clear winner) and the lack of extensive parallel processing support (coming soon... https://www.youtube.com/watch?v=FzmQTC_X5R4 https://www.youtube.com/watch?v=FzmQTC_X5R4 ). F# comes with a sensible default library (including Unicode support as default), some nice syntactic sugar (the pipe forward operator is especially useful, and to be fair it has made it into Ocaml now too... http://stackoverflow.com/questions/8986010/is-it-possible-to-use-pipes-in-ocaml http://stackoverflow.com/questions/8986010/is-it-possible-to... ), seamless interoperability with all .NET libraries, and parallel processing is made comparatively easy (for example, if performing a map operation over a list, can just change the List.map function to Parallel.map to get the parallel version). This is probably the F# introduction I would recommend the most (it's a video, which I know isn't ideal, but it's a good one): http://channel9.msdn.com/Blogs/pdc2008/TL11 http://channel9.msdn.com/Blogs/pdc2008/TL11 Oh and type providers in F# blew my mind! I can't really summarise them yet, but imagine being able to mix Python or R or many other data sources in with F#. If anyone has a good introductory post on type providers, please feel free to share.
berdario 12y ago
Since there aren't a lot of full time Haskell developers, I'm curious to know what do you use to setup your projects and handle dependencies: hsenv, cabal-dev, cabal sandboxes, nix, stackage ... or do you include everything in your repository (any tool to automate that)?
- progman 12y ago
  I would love to use Haskell as a practical tool (I honestly tried that) but the very fact that the Haskell community was not yet able to implement a simple practical thing like a convenient working package manager reveals that Haskell is not so practical after all. We need sandboxes, nix oder even a new OS (NixOS) just for the purpose of developing Haskell software? Come on!
  - marcosdumay 12y ago
    You got very misinformed. Haskell is actually late to the sandbox party - up to recently you couldn't use them at all, and currently they are completely optional. But now that you can, it would be stupid to start a big project without them, like in any other language. Haskell package manager is called Cabal. Nix and NixOS are two completely unrelated projects, that not even be recommendable in a development environment.
    - progman 12y ago
      You have misunderstood me. I know cabal - with and without sandbox. I said am amazed that sandboxes or nix tools are necessary in Haskell _at all_ while every other language which uses a package manager has one that works out of the box without any hassle and without any sandbox tricks. > Nix and NixOS are two completely unrelated projects, that not even be recommendable in a development environment. Other Haskell developers don't agree. They prefer nix even over cabal sandboxes. Quote: "Nix helps me avoid Cabal hell" and "Nix is much better than cabal sandbox". https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-...
michaelochurch 12y ago
Where do you work? What has your experience been using Haskell "in the RealWorld"? I'd love to know more about this. My email address is michael.o.church at Google's email service. I got seriously into Haskell a few months ago, but I've used ML in algorithmic trading and was a major fan. I feel like it does us a disservice to complain about Haskell's (admittedly, warty) Exception system or "cabal hell" when what is actually going on is that we're holding the language to a higher standard. I agree that functions like head, fail, and possibly non-strict foldl, are warty; but these issues are downright minuscule when you consider what Haskell (language and community) brings to the table. (Also, every other language has warts.) The fact that our complaints about Haskell are minor annoyances compared to other languages' drawbacks, to me, signifies that the language got the major things right.
- tel 12y ago
  The exception system that Harper was complaining about really was terrifically bad. It's all based on a form of limited reflection, but previously was implemented in a way that let you pretty regularly and possibly accidentally lie to the compiler. Nasty stuff, now gone.
  - jonsterling 12y ago
    Yeah... I would say that Haskell's exceptions are still far worse than ML's, but I am not aware that they are unsafe anymore.
- boothead 12y ago
  I've just finished a stint running a team building a start up in Haskell and clojurescript. It's been an amazing year, and for me has completely vindicated my view that not only is Haskell fine for real world use, but for a number of reasons that it's a superior tool to use. I'm ben <at> perurbis <dot> com if you'd like me to expand on that a bit (I don't want to hijack this thread too much).

bronxbomber92 12y ago

Could you expand on why you think the next "great thing" will be more like ML than like Haskell?

jonsterling 12y ago
1. Call-by-value gives us both the ability reason by induction. It also typically results in the presence of non-pointed types, whereas Haskell only has pointed types. 2. Call-by-value gives us the ability to safely interleave effects. Now, I know you all think we should not be doing that at all, but I would say that this is only true in some cases. The point of reifying an effect in a monad is not because "effects are icky"; it is because we have written a non-extensional operation using effects, and we want it to be an extensional function. Wrapping it up in the monad "completes" the operation as such. However, there are plenty of extensional functions which may be written using computational effects (such as memoization): these should not be wrapped up in the monad. (FYI, it's the effects that preserve extensionality which is what Bob calls "benign effects", to the consternation of Haskell developers everywhere.) ML gives us the fine-grainedness to make these choices, at the cost of some reasoning facilities: more proofs must be done on paper, or in an external logical framework. I tend to think that the latter is inevitable, but some disagree. I am hoping for a middle-ground then: something like ML, in that effects are fundamental and not just bolted onto the language with a stack of monads; something like Haskell, where we can tell what effects are being used by a piece of code. The story hasn't been fully written on this, but I think that Call-by-push-value can help us with both recovering the benefits of laziness as well as reasoning about effects. 3. Modularity is something which Haskell people simply do not take seriously, even with the new "backpack" package-level module system they are building. One of the most-loved reasoning facilities present in Haskell depends, believe it or not, on global scope, and is therefore inherently anti-modular (this is the uniqueness of type class instances). As a result, you can never add modularity to Haskell, but we may be able to back-port some of the more beloved aspects of Haskell to a new nephew in the ML family. (Confusingly, laziness advocates often say that their brand of functional programming has better "modularity" than strict, because of the way that you can compose lazy algorithms to get more lazy algorithms that don't totally blow up in complexity. I would say that lazy languages are more "compositional", not more "modular"—I prefer to use the latter term for modularity at the level of architecture and systems design, not algorithms.)
- tel 12y ago
  Could you expand on effects which preserve extensionality some more? I'm fairly sure I understand it, but I've never quite follows what Harper's "benign effects" meant in detail and I'd like to see how it all connects.
  - jonsterling 12y ago
    The most benign effect of them all is laziness. Haskell uses this in lieu of all other effects, basically. So memoizing data structures, or a higher order function for memoizing, utilizes a "benign effect".
    - tel 12y ago
      So extensionally equal simply means that there is a model with and without the effect such that extensionally, according to some model of observation, we cannot discern the existence of the effect? So, laziness is benign in total fragments.
      - jonsterling 12y ago
        I wasn't thinking about models, but perhaps you could? I just mean that you get the same results for equal inputs; laziness is fine in this respect (but not in the presence of some other effects).
- tel 12y ago
  I would love to see a "practical" CBPV language.
  - tome 12y ago
    Likewise, mostly because it would probably help me understand what CBPV actually is!
    - tel 12y ago

pjmlp 12y ago

Haskell belongs to the ML language family.

coldtea 12y ago
I'd bet that he knows that already. And C++ belongs to the C language family, but one could still say something like "the next great thing would come from a C rather than a C++ like language" (I'm not judging if this is true here, just that it's quite clear what it means).
- pjmlp 12y ago
  No, because you can have other ML derived languages that are also lazy and strict, without being necessarily based on Haskell.
pfh 12y ago
and there is no such thing as a fish.
ufo 12y ago
He's probably saying that he things the next big thing will be strict by default and feature a neat module system.
- jonsterling 12y ago
  Yes, that's close! I also think that we'll need a better treatment of effects than either ML or Haskell can give us, but I hope to have something that has been carefully thought about, rather than bolted on like Haskell's effects. It sounds like call-by-push-value gives a nice unifying approach to CBN/CBV and also effects. I am hoping that something interesting will come out of that work.
  - tome 12y ago
    It's been about 15 years since CBPV was proposed. Has there been any work on actually making a practical language along those lines?

CmonDev 12y ago

"the next great thing will be more like ML" ocaML or even better F#?

progman 12y ago
I wonder if Ocaml is actually much more practical than Haskell. Ocaml has been proven to be well usable in industry while Haskell seems to be suitable for research areas like math and language design. http://mirror.ocamlcore.org/wiki.cocan.org/companies.html http://mirror.ocamlcore.org/wiki.cocan.org/companies.html http://www.infoq.com/presentations/jane-street-caml-ocaml http://www.infoq.com/presentations/jane-street-caml-ocaml http://queue.acm.org/detail.cfm?id=2038036&ref=fullrss http://queue.acm.org/detail.cfm?id=2038036&ref=fullrss
- ZenoArrow 12y ago
  I'm learning F# right now, it's flipping excellent! From what I understand it's similar to Ocaml, but has some other features that give it the edge (for me at least). I did try to learn Ocaml at one point, but I was put off by the standard library variation (the default one apparently has numerous shortcomings, Batteries project extends it and Core project aims to replace it, but neither one is the clear winner) and the lack of extensive parallel processing support (coming soon... https://www.youtube.com/watch?v=FzmQTC_X5R4 https://www.youtube.com/watch?v=FzmQTC_X5R4 ). F# comes with a sensible default library (including Unicode support as default), some nice syntactic sugar (the pipe forward operator is especially useful, and to be fair it has made it into Ocaml now too... http://stackoverflow.com/questions/8986010/is-it-possible-to-use-pipes-in-ocaml http://stackoverflow.com/questions/8986010/is-it-possible-to... ), seamless interoperability with all .NET libraries, and parallel processing is made comparatively easy (for example, if performing a map operation over a list, can just change the List.map function to Parallel.map to get the parallel version). This is probably the F# introduction I would recommend the most (it's a video, which I know isn't ideal, but it's a good one): http://channel9.msdn.com/Blogs/pdc2008/TL11 http://channel9.msdn.com/Blogs/pdc2008/TL11 Oh and type providers in F# blew my mind! I can't really summarise them yet, but imagine being able to mix Python or R or many other data sources in with F#. If anyone has a good introductory post on type providers, please feel free to share.

berdario 12y ago

Since there aren't a lot of full time Haskell developers, I'm curious to know what do you use to setup your projects and handle dependencies: hsenv, cabal-dev, cabal sandboxes, nix, stackage ... or do you include everything in your repository (any tool to automate that)?

progman 12y ago
I would love to use Haskell as a practical tool (I honestly tried that) but the very fact that the Haskell community was not yet able to implement a simple practical thing like a convenient working package manager reveals that Haskell is not so practical after all. We need sandboxes, nix oder even a new OS (NixOS) just for the purpose of developing Haskell software? Come on!
- marcosdumay 12y ago
  You got very misinformed. Haskell is actually late to the sandbox party - up to recently you couldn't use them at all, and currently they are completely optional. But now that you can, it would be stupid to start a big project without them, like in any other language. Haskell package manager is called Cabal. Nix and NixOS are two completely unrelated projects, that not even be recommendable in a development environment.
  - progman 12y ago
    You have misunderstood me. I know cabal - with and without sandbox. I said am amazed that sandboxes or nix tools are necessary in Haskell _at all_ while every other language which uses a package manager has one that works out of the box without any hassle and without any sandbox tricks. > Nix and NixOS are two completely unrelated projects, that not even be recommendable in a development environment. Other Haskell developers don't agree. They prefer nix even over cabal sandboxes. Quote: "Nix helps me avoid Cabal hell" and "Nix is much better than cabal sandbox". https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-with-nixos.html https://ocharles.org.uk/blog/posts/2014-02-04-how-i-develop-...

michaelochurch 12y ago

Where do you work? What has your experience been using Haskell "in the RealWorld"? I'd love to know more about this. My email address is michael.o.church at Google's email service. I got seriously into Haskell a few months ago, but I've used ML in algorithmic trading and was a major fan. I feel like it does us a disservice to complain about Haskell's (admittedly, warty) Exception system or "cabal hell" when what is actually going on is that we're holding the language to a higher standard. I agree that functions like head, fail, and possibly non-strict foldl, are warty; but these issues are downright minuscule when you consider what Haskell (language and community) brings to the table. (Also, every other language has warts.) The fact that our complaints about Haskell are minor annoyances compared to other languages' drawbacks, to me, signifies that the language got the major things right.

tel 12y ago
The exception system that Harper was complaining about really was terrifically bad. It's all based on a form of limited reflection, but previously was implemented in a way that let you pretty regularly and possibly accidentally lie to the compiler. Nasty stuff, now gone.
- jonsterling 12y ago
  Yeah... I would say that Haskell's exceptions are still far worse than ML's, but I am not aware that they are unsafe anymore.
boothead 12y ago
I've just finished a stint running a team building a start up in Haskell and clojurescript. It's been an amazing year, and for me has completely vindicated my view that not only is Haskell fine for real world use, but for a number of reasons that it's a superior tool to use. I'm ben <at> perurbis <dot> com if you'd like me to expand on that a bit (I don't want to hijack this thread too much).