8 ms·

Haskell: Not pure enough?

30 points by profquail 16y ago

jeffdavis 16y ago
My take away was essentially: "if you try, you can write non-portable haskell code". I don't really get the significance.
- calpaterson 16y ago
  One of the intentions of Haskell is to provide certain guarantees about whatever pure code is compiled. These guarantees are important for some applications (especially concurrency and distributed parallelism). If these guarantees are lies, then there can be a problem. None of the examples are massively series, but hopefully it should prove the point that this topic matters.
  - calpaterson 16y ago
    Can't believe I wrote "series" instead of serious. :|
jpr 16y ago
When you subscribe to some ideology that can be described by a simple word, it is easy to dismiss all problems encountered while exercising that ideology by saying that "you are not being X enough", whether X is socialist, capitalist, vegan, carnivore, functional, object-oriented, static, dynamic, free, proprietary or whatever. I used to program in Haskell for fun and school and I liked it. I find it very well thought out language. I may very well come back to programming in Haskell when I encounter a suitable project. But there is a tendency among Haskeller's to get too caught up in praising purity and laziness, while ignoring the nice practical aspects of the language that could enable it to rise to be an even greater language. I'm not saying that author is guilty of this, this is just a general observation. And I must admit that I'm not quite up to date of what's up with Haskell. My point is that Haskell is great for reasons other than purity and laziness, too.
- calpaterson 16y ago
  That isn't true. There is an important justification for purity in Haskell. It increases the correctness of programs. There are plenty of important ideas that use only a single word, and the fact that they use a single word doesn't say anything good or bad about them.
  - alnayyir 16y ago
    That isn't true. There is an important justification for State control in Communism. It increases the fairness of societies. There are plenty of important ideas that use Communism to achieve their ends, and the fact that they use Communism doesn't say anything good or bad about them.
- qntm 16y ago
  The nature of programming is that you use the right tool for the right job. The question is what kind of tool we want Haskell to be. "I want Haskell to be most useful only in specific, limited situations where puritanical program correctness is imperative" is a legitimate answer to this question, as is "I want Haskell to be practical enough to be general-purpose". And if a programmer looks at a problem and says "Haskell isn't right for this situation; I'm going to use something else", then you or I, a Haskell advocate, may be okay with that.
- ezyang 15y ago
  I think what you're seeing here is not that we're dismissing all problems but that we look at some problems (say, distributed systems) and think "Man, our lives would be so much easier if we were purer." Of course there are trade offs, but when these new circumstances come up, it does nicely vindicate the extremists. :-)
jerf 16y ago
Engineering school: The costs and benefits for each problem must be analyzed and decided on a per-case basis. The cost of bring full, absolute perfection are absolutely staggering. One of the biggest ones that is easy to miss is that you rigidly limit yourself to current implementations; consider the case of writing your perfect specification in 1998, then spending a lot of time right now wishing a metaphorical half your 64-bit machine wasn't sitting there idle. The benefits of this absolute purity vs. what we already have right now? Pretty small next to the costs. But that's just one example. Besides, fixing some of those all but requires a new hardware and OS platform. Floating point is intrinsically nasty from a mathematical point of view, but as long as it is what the hardware supports, it's going to have to be in your language, for instance, unless you just want to give up on numerical performance. Some of the os module nastiness is hard to actually kill without going not merely the full-on JVM-as-OS route but beyond, as even the JVM exposes some OS differences. But I am serious about the case-by-case thing. There may be some things that are wrong and are worth being fixed. My previous paragraphs dismissed the idea of fixing the totality of the problem but that doesn't mean any given thing may not be an improvement.
- jhpriestley 16y ago
  If your algorithm works on both 32-bit and 64-bit integers, then you can parameterize it: safeAdd :: (SmallInt i) => i -> i -> Maybe i safeAdd x y = if (maxBound - x) > y then Just (x + y) else Nothing `maxBound` would be a member of the `SmallInt` typeclass, with different values for `Int32, `Int64`, `Int23`, etc.
  - aristidb 16y ago
    Bounded is the typeclass you want.
    - jhpriestley 16y ago
      Ah, right. I don't actually do much numerically sensitive programming. Why aren't Haskell's SmallInt functions parameterized over Int size, anyway? Of the points brought up in the blog post, this one seems the easiest to fix.
droz 16y ago
Many of these criticisms seem to be compiler specific rather than language specific (perhaps with the exception of the os example). * I like knowing explicitly what kind of integers I'm working with and plan on using the full 32 or 64 bits available to me. * IEEE floating point issues will be around forever. If you want something more precise, store the numerator and denominator, or factorization. * foldr doesn't have to be implemented recursively.
- nwhitehead 16y ago
  The IEEE problems are actually specific to x87 and the fact that x87 has extended precision in registers and single/double precision in memory. So your result can depend on whether the compiler spilled intermediate calculations to memory or kept them in registers. Luckily SSE doesn't have this issue. You get single or double precision consistently. IEEE actually gives a consistent functional specification for arithmetic that fits purely functional programming pretty well.
hristov 16y ago
None of these are examples of lack of purity. Maybe they are examples of lack of portability. But not of lack of purity. Purity means that the result of an expression is the same while the program is running. These calculations may differ if run on different computers or sometimes even if run at different times on the same computer, but once you run them you can be reasonably sure that they return the same result while the program is running.
- ezyang 15y ago
  One of the things I want out of pure programs is reproducibility. If a pure fragment of code doesn't give the same result over multiple executions, that's not very reproducible. Maybe that's OK, but it does make my ears twitch.

30 points by profquail 16y ago

My take away was essentially: "if you try, you can write non-portable haskell code". I don't really get the significance.

calpaterson 16y ago
One of the intentions of Haskell is to provide certain guarantees about whatever pure code is compiled. These guarantees are important for some applications (especially concurrency and distributed parallelism). If these guarantees are lies, then there can be a problem. None of the examples are massively series, but hopefully it should prove the point that this topic matters.
- calpaterson 16y ago
  Can't believe I wrote "series" instead of serious. :|

jpr 16y ago

When you subscribe to some ideology that can be described by a simple word, it is easy to dismiss all problems encountered while exercising that ideology by saying that "you are not being X enough", whether X is socialist, capitalist, vegan, carnivore, functional, object-oriented, static, dynamic, free, proprietary or whatever. I used to program in Haskell for fun and school and I liked it. I find it very well thought out language. I may very well come back to programming in Haskell when I encounter a suitable project. But there is a tendency among Haskeller's to get too caught up in praising purity and laziness, while ignoring the nice practical aspects of the language that could enable it to rise to be an even greater language. I'm not saying that author is guilty of this, this is just a general observation. And I must admit that I'm not quite up to date of what's up with Haskell. My point is that Haskell is great for reasons other than purity and laziness, too.

calpaterson 16y ago
That isn't true. There is an important justification for purity in Haskell. It increases the correctness of programs. There are plenty of important ideas that use only a single word, and the fact that they use a single word doesn't say anything good or bad about them.
- alnayyir 16y ago
  That isn't true. There is an important justification for State control in Communism. It increases the fairness of societies. There are plenty of important ideas that use Communism to achieve their ends, and the fact that they use Communism doesn't say anything good or bad about them.
qntm 16y ago
The nature of programming is that you use the right tool for the right job. The question is what kind of tool we want Haskell to be. "I want Haskell to be most useful only in specific, limited situations where puritanical program correctness is imperative" is a legitimate answer to this question, as is "I want Haskell to be practical enough to be general-purpose". And if a programmer looks at a problem and says "Haskell isn't right for this situation; I'm going to use something else", then you or I, a Haskell advocate, may be okay with that.
ezyang 15y ago
I think what you're seeing here is not that we're dismissing all problems but that we look at some problems (say, distributed systems) and think "Man, our lives would be so much easier if we were purer." Of course there are trade offs, but when these new circumstances come up, it does nicely vindicate the extremists. :-)

jerf 16y ago

Engineering school: The costs and benefits for each problem must be analyzed and decided on a per-case basis. The cost of bring full, absolute perfection are absolutely staggering. One of the biggest ones that is easy to miss is that you rigidly limit yourself to current implementations; consider the case of writing your perfect specification in 1998, then spending a lot of time right now wishing a metaphorical half your 64-bit machine wasn't sitting there idle. The benefits of this absolute purity vs. what we already have right now? Pretty small next to the costs. But that's just one example. Besides, fixing some of those all but requires a new hardware and OS platform. Floating point is intrinsically nasty from a mathematical point of view, but as long as it is what the hardware supports, it's going to have to be in your language, for instance, unless you just want to give up on numerical performance. Some of the os module nastiness is hard to actually kill without going not merely the full-on JVM-as-OS route but beyond, as even the JVM exposes some OS differences. But I am serious about the case-by-case thing. There may be some things that are wrong and are worth being fixed. My previous paragraphs dismissed the idea of fixing the totality of the problem but that doesn't mean any given thing may not be an improvement.

jhpriestley 16y ago
If your algorithm works on both 32-bit and 64-bit integers, then you can parameterize it: safeAdd :: (SmallInt i) => i -> i -> Maybe i safeAdd x y = if (maxBound - x) > y then Just (x + y) else Nothing `maxBound` would be a member of the `SmallInt` typeclass, with different values for `Int32, `Int64`, `Int23`, etc.
- aristidb 16y ago
  Bounded is the typeclass you want.
  - jhpriestley 16y ago
    Ah, right. I don't actually do much numerically sensitive programming. Why aren't Haskell's SmallInt functions parameterized over Int size, anyway? Of the points brought up in the blog post, this one seems the easiest to fix.

droz 16y ago

Many of these criticisms seem to be compiler specific rather than language specific (perhaps with the exception of the os example). * I like knowing explicitly what kind of integers I'm working with and plan on using the full 32 or 64 bits available to me. * IEEE floating point issues will be around forever. If you want something more precise, store the numerator and denominator, or factorization. * foldr doesn't have to be implemented recursively.

nwhitehead 16y ago
The IEEE problems are actually specific to x87 and the fact that x87 has extended precision in registers and single/double precision in memory. So your result can depend on whether the compiler spilled intermediate calculations to memory or kept them in registers. Luckily SSE doesn't have this issue. You get single or double precision consistently. IEEE actually gives a consistent functional specification for arithmetic that fits purely functional programming pretty well.

hristov 16y ago

None of these are examples of lack of purity. Maybe they are examples of lack of portability. But not of lack of purity. Purity means that the result of an expression is the same while the program is running. These calculations may differ if run on different computers or sometimes even if run at different times on the same computer, but once you run them you can be reasonably sure that they return the same result while the program is running.

ezyang 15y ago
One of the things I want out of pure programs is reproducibility. If a pure fragment of code doesn't give the same result over multiple executions, that's not very reproducible. Maybe that's OK, but it does make my ears twitch.