5 ms·

> (2) The Haskell code is nowhere near idiomatic This isn't meant as a personal attack firstly. Secondly, I've heard this said more than a few times lately and

> (2) The Haskell code is nowhere near idiomatic This isn't meant as a personal attack firstly. Secondly, I've heard this said more than a few times lately and am generally curious: Do you know which Haskell examples are idiomatic, which aren't, and why? I feel like in the case of some it's just parroting someone elses argument.

jakevn 12y ago
A glance at the source quickly reveals an unsafe implementation.
- codygman 12y ago
  I didn't see an import for unsafe or foreign in: fannkuch-redux pidigits binary-trees
  - jakevn 12y ago
    fannkuch-redux heavily utilizes unsafe operations on a mutable vector. binary-trees uses artificial strictness for the sake of the benchmark. Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance).
    - imanaccount247 12y ago
      >fannkuch-redux heavily utilizes unsafe operations on a mutable vector. They are just not bounds checked. That is not "writing C in Haskell". >binary-trees uses artificial strictness for the sake of the benchmark What on earth is "artificial strictness"? Forcing evaluation when you need something to be evaluated immediately is not artificial, not unidiomatic, and not "writing C in Haskell". >Nine of the ten Haskell implementations are demonstrations of writing C in Haskell And end up shorter than rust? The idea that writing lower level code is "writing C in haskell" is nonsense, the ability to write more verbose but faster code is not harmful, it is useful. But the fact that lower level haskell is still shorter than rust and yet you want to act like it is some sort of horrible thing makes it hard to believe that you are really concerned about the horrors of writing slightly more verbose code.
      - jakevn 12y ago
        The Rust code is both safer and faster at the cost of more keystrokes. I'm not certain the point of writing unsafe code in Haskell when there are better tools for the job. Haskell is fast enough as is and using it to hammer screws just reeks of wrong tool for the job.
        imanaccount247 12y ago
        Your comment says absolutely nothing, and that appears to be the goal. What is the point of writing any code in any language? It is a benchmark, the point of it is to write the fastest code you can. You aren't obligated to write lower level code in haskell, nobody has a gun to your head. So why do you pretend it is a problem, and claim other languages are "better tools" for that job despite haskell clearly being very good at that job?
        igouy 12y ago
        >>It is a benchmark, the point of it is to write the fastest code you can.<< The point of it is to show the performance differences, but that doesn't exclude a program like -- http://benchmarksgame.alioth.debian.org/u64q/program.php?test=meteor&lang=ghc&id=4 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... -- or like -- http://benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=ghc&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... etc
        imanaccount247 12y ago
        It doesn't exclude "idiomatic" versions, but the data is presented so as to make them useless. How do I compare "idiomatic" rust to "idiomatic" haskell? All you can get is "here's the fastest versions from each language". If you want to compare any other version you have to do it on an individual basis, one at a time. So there's absolutely no reason for people to bother adding "idiomatic" versions.
        12y ago
    - codygman 12y ago
      > binary-trees uses artificial strictness for the sake of the benchmark Using strict evaluation when appropriate is most certainly idiomatic Haskell code. > Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance). This (C in Haskell accusation) is debatable, though I'm not sure there's much to be gained even given a totally successful discussion where we both communicate our points 100% effectively.
      - jakevn 12y ago
        There probably isn't a point to it, as we're likely trying to argue different points. I posit that using Haskell in such a way is a disservice to the language. If you want to code in such a way, why use Haskell? Haskell is plenty fast as is and doesn't need to resort to unsafe code. What's the point?
        tel 12y ago
        Mutability and strictness aren't a disservice to Haskell. They're both considered to be things which are available as choices and should be taken when needed. In particular, the entire ST monad is all about mutability and is very well behaved. Furthermore, even if you write nearly everything in the IO monad Haskell you'll gain a lot from the type system and from easily peeling out small, meaningful pure segments.
Jweb_Guru 12y ago
Just in the first two examples on that page, you'll find allocaArray, mallocByteString, writeAlu, unsafeUseAsCString, unsafeIndex, withForeignPtr, unsafeDrop, and more. You really don't have to know Haskell very well (and I'm not claiming to be an expert by any stretch) to understand that this is far from idiomatic in a lazily evaluated, pure functional language. No parroting required.
- imanaccount247 12y ago
  You should know it at least a tiny bit though, or else you lump perfectly "idiomatic" functions in with low level functions that aren't often used and pretend they're a problem. How is a indexing an array without a bounds check somehow counter to lazy evaluation or functional programming? It is the exact same thing as indexing it normally, just without checking the length.
  - bjz_ 12y ago
    The point is that is unsafe. You don't need to do that in idiomatic Rust code, because the bounds-check-free indexing is encapsulated inside the iterator library. So to re-frame it: fast, idiomatic Rust code is safer and easier to write than fast, idiomatic Haskell code.
    - imanaccount247 12y ago
      >The point is that is unsafe No, the point was that it is "far from idiomatic". Did you read the post I was replying to?
  - coldtea 12y ago
    How is indexing an array OK with functional programming of the level of purity Haskell strives for (not to mention without bounds checking)? In "Real World Haskell" they advise you to forgo of arrays, and even has a chapter "Life without arrays", saying "arrays and hash tables are often used as collections indexed by key, and in Haskell we use trees for that purpose".
imanaccount247 12y ago
>I feel like in the case of some it's just parroting someone elses argument. It usually is. The reality is that like most memes like this, there's a grain of truth at the center, but most of the people repeating it don't know where the truth ends and the exaggeration begins. Regex-dna is using low level ByteString operations to squeeze out a bit of extra performance. This makes it quite a bit longer and would rarely be done in practice since the gain is small. Fasta again does some low level ByteString operations, but not nearly as significant as regex-dna. Not that bad. Others like fannkuch-redux are just using "unsafe" vector functions. All that is doing is leaving out bounds checks. That makes an miniscule difference in performance most of the time, but the way the shootout works there's only incentive to completely optimize for speed, so you get 1% optimizations you wouldn't normally see. I'd hardly call it unidiomatic though, you just normally use "read" instead of "unsafeRead", etc. In some cases I would say the unsafe calls are idiomatic. If you are going to be doing an operation repeatedly in a loop, doing the bounds checking once before looping and using the non-bounds checked calls in the loop is pretty standard. Pidigits is normal haskell (although you could argue the lack of spacing isn't idiomatic, but that hardly matters). I stopped there since the rest are getting enough slower than rust, but looking them over there's still nothing outrageous, just more low level ByteString usage. Overall none of them are that far from idiomatic, none of them do anything particularly crazy, and I think the speed gains from doing most of the optimizations they are doing are fairly small. I find it particularly odd that people act like the ability to write lower level code that is faster is a problem with haskell. Especially given that the "low level" haskell versions are often still shorter and no harder to read than the "idiomatic" rust versions.
- bjz_ 12y ago
  Ok, so perhaps I grant you the fact that unsafe indexing is idiomatic. The Rust code is still safer and more robust against buffer overflows in the long term. Also, isn't regex-dna using libpcre? That's a C library, no? Rust's regex library is pure Rust, with no unsafe code. I love Haskell, but I still don't think it occupies the same space as Rust.
  - codygman 12y ago
coldtea 12y ago
>Do you know which Haskell examples are idiomatic, which aren't, and why? Why wouldn't he? With a little familiarity with programming at large and Haskell syntax can learn to discern the two cases even if you're not a Haskell programmer.

jakevn 12y ago

A glance at the source quickly reveals an unsafe implementation.

codygman 12y ago
I didn't see an import for unsafe or foreign in: fannkuch-redux pidigits binary-trees
- jakevn 12y ago
  fannkuch-redux heavily utilizes unsafe operations on a mutable vector. binary-trees uses artificial strictness for the sake of the benchmark. Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance).
  - imanaccount247 12y ago
    >fannkuch-redux heavily utilizes unsafe operations on a mutable vector. They are just not bounds checked. That is not "writing C in Haskell". >binary-trees uses artificial strictness for the sake of the benchmark What on earth is "artificial strictness"? Forcing evaluation when you need something to be evaluated immediately is not artificial, not unidiomatic, and not "writing C in Haskell". >Nine of the ten Haskell implementations are demonstrations of writing C in Haskell And end up shorter than rust? The idea that writing lower level code is "writing C in haskell" is nonsense, the ability to write more verbose but faster code is not harmful, it is useful. But the fact that lower level haskell is still shorter than rust and yet you want to act like it is some sort of horrible thing makes it hard to believe that you are really concerned about the horrors of writing slightly more verbose code.
    - jakevn 12y ago
      The Rust code is both safer and faster at the cost of more keystrokes. I'm not certain the point of writing unsafe code in Haskell when there are better tools for the job. Haskell is fast enough as is and using it to hammer screws just reeks of wrong tool for the job.
      - imanaccount247 12y ago
        Your comment says absolutely nothing, and that appears to be the goal. What is the point of writing any code in any language? It is a benchmark, the point of it is to write the fastest code you can. You aren't obligated to write lower level code in haskell, nobody has a gun to your head. So why do you pretend it is a problem, and claim other languages are "better tools" for that job despite haskell clearly being very good at that job?
        igouy 12y ago
        >>It is a benchmark, the point of it is to write the fastest code you can.<< The point of it is to show the performance differences, but that doesn't exclude a program like -- http://benchmarksgame.alioth.debian.org/u64q/program.php?test=meteor&lang=ghc&id=4 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... -- or like -- http://benchmarksgame.alioth.debian.org/u64q/program.php?test=spectralnorm&lang=ghc&id=2 http://benchmarksgame.alioth.debian.org/u64q/program.php?tes... etc
        imanaccount247 12y ago
        It doesn't exclude "idiomatic" versions, but the data is presented so as to make them useless. How do I compare "idiomatic" rust to "idiomatic" haskell? All you can get is "here's the fastest versions from each language". If you want to compare any other version you have to do it on an individual basis, one at a time. So there's absolutely no reason for people to bother adding "idiomatic" versions.
        12y ago
  - codygman 12y ago
    > binary-trees uses artificial strictness for the sake of the benchmark Using strict evaluation when appropriate is most certainly idiomatic Haskell code. > Nine of the ten Haskell implementations are demonstrations of writing C in Haskell (without reaching C's performance). This (C in Haskell accusation) is debatable, though I'm not sure there's much to be gained even given a totally successful discussion where we both communicate our points 100% effectively.
    - jakevn 12y ago
      There probably isn't a point to it, as we're likely trying to argue different points. I posit that using Haskell in such a way is a disservice to the language. If you want to code in such a way, why use Haskell? Haskell is plenty fast as is and doesn't need to resort to unsafe code. What's the point?
      - tel 12y ago
        Mutability and strictness aren't a disservice to Haskell. They're both considered to be things which are available as choices and should be taken when needed. In particular, the entire ST monad is all about mutability and is very well behaved. Furthermore, even if you write nearly everything in the IO monad Haskell you'll gain a lot from the type system and from easily peeling out small, meaningful pure segments.

Jweb_Guru 12y ago

Just in the first two examples on that page, you'll find allocaArray, mallocByteString, writeAlu, unsafeUseAsCString, unsafeIndex, withForeignPtr, unsafeDrop, and more. You really don't have to know Haskell very well (and I'm not claiming to be an expert by any stretch) to understand that this is far from idiomatic in a lazily evaluated, pure functional language. No parroting required.

imanaccount247 12y ago
You should know it at least a tiny bit though, or else you lump perfectly "idiomatic" functions in with low level functions that aren't often used and pretend they're a problem. How is a indexing an array without a bounds check somehow counter to lazy evaluation or functional programming? It is the exact same thing as indexing it normally, just without checking the length.
- bjz_ 12y ago
  The point is that is unsafe. You don't need to do that in idiomatic Rust code, because the bounds-check-free indexing is encapsulated inside the iterator library. So to re-frame it: fast, idiomatic Rust code is safer and easier to write than fast, idiomatic Haskell code.
  - imanaccount247 12y ago
    >The point is that is unsafe No, the point was that it is "far from idiomatic". Did you read the post I was replying to?
- coldtea 12y ago
  How is indexing an array OK with functional programming of the level of purity Haskell strives for (not to mention without bounds checking)? In "Real World Haskell" they advise you to forgo of arrays, and even has a chapter "Life without arrays", saying "arrays and hash tables are often used as collections indexed by key, and in Haskell we use trees for that purpose".

imanaccount247 12y ago

>I feel like in the case of some it's just parroting someone elses argument. It usually is. The reality is that like most memes like this, there's a grain of truth at the center, but most of the people repeating it don't know where the truth ends and the exaggeration begins. Regex-dna is using low level ByteString operations to squeeze out a bit of extra performance. This makes it quite a bit longer and would rarely be done in practice since the gain is small. Fasta again does some low level ByteString operations, but not nearly as significant as regex-dna. Not that bad. Others like fannkuch-redux are just using "unsafe" vector functions. All that is doing is leaving out bounds checks. That makes an miniscule difference in performance most of the time, but the way the shootout works there's only incentive to completely optimize for speed, so you get 1% optimizations you wouldn't normally see. I'd hardly call it unidiomatic though, you just normally use "read" instead of "unsafeRead", etc. In some cases I would say the unsafe calls are idiomatic. If you are going to be doing an operation repeatedly in a loop, doing the bounds checking once before looping and using the non-bounds checked calls in the loop is pretty standard. Pidigits is normal haskell (although you could argue the lack of spacing isn't idiomatic, but that hardly matters). I stopped there since the rest are getting enough slower than rust, but looking them over there's still nothing outrageous, just more low level ByteString usage. Overall none of them are that far from idiomatic, none of them do anything particularly crazy, and I think the speed gains from doing most of the optimizations they are doing are fairly small. I find it particularly odd that people act like the ability to write lower level code that is faster is a problem with haskell. Especially given that the "low level" haskell versions are often still shorter and no harder to read than the "idiomatic" rust versions.

bjz_ 12y ago
Ok, so perhaps I grant you the fact that unsafe indexing is idiomatic. The Rust code is still safer and more robust against buffer overflows in the long term. Also, isn't regex-dna using libpcre? That's a C library, no? Rust's regex library is pure Rust, with no unsafe code. I love Haskell, but I still don't think it occupies the same space as Rust.
- codygman 12y ago

coldtea 12y ago

>Do you know which Haskell examples are idiomatic, which aren't, and why? Why wouldn't he? With a little familiarity with programming at large and Haskell syntax can learn to discern the two cases even if you're not a Haskell programmer.