4 ms·

> No he didn't. He took the time to learn ocaml. Not before writing his initial benchmarks, which is what we're talking about. > The closest thing to evidence

by lpw25 13y ago

> No he didn't. He took the time to learn ocaml. Not before writing his initial benchmarks, which is what we're talking about. > The closest thing to evidence I can find suggests that it is no more difficult to write fast code in haskell: > http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te.. http://benchmarksgame.alioth.debian.org/u64/benchmark.php?te.... That measures ridiculous highly tuned implementations of the benchmarks, often written by the creators of the languages themselves. It contains absolutely no evidence of how hard it is to write fast programs in a language. Besides, I'm pretty sure citing the language shoot-out is an automatic disqualification in any argument about language speed.

nousernamesleft 13y ago
>Not before writing his initial benchmarks Yes, he did. Try talking to him. >That measures ridiculous highly tuned implementations of the benchmarks So, fast code. Which is what is at question. >It contains absolutely no evidence of how hard it is to write fast programs in a language. There is both lines of code, and actually looking at the code itself. Both of which make it appear that writing fast code is no more difficult in haskell than in ocaml. >I'm pretty sure citing the language shoot-out is an automatic disqualification in any argument about language speed. I'm pretty sure the language shoot-out is of greater value as evidence than personal anecdote is.
- lpw25 13y ago
  > So, fast code. Which is what is at question. No the question is about whether fast code is easy to write, if it has to be highly tuned then it is not easy to write. > I'm pretty sure the language shoot-out is of greater value as evidence than personal anecdote is. Actually, I think that the shoot-out causes a lot of harm to people's attempts to understand whether a language is fast or not. When people ask: "Is language X fast?" what they mean is "if I write my programs in it will they be fast". They do not mean "is the highly tuned code of an expert fast". The question of whether a language is fast is about whether code written in the natural idioms of the language is fast, not about whether you can coerce the compiler into producing the precise assembly code you are aiming for. If you are going to do that you might as well write the assembly code directly and call it using an FFI. Many implementations on the shoot-out bare no resemblance to the code people naturally write in those languages.
  - nousernamesleft 13y ago
    You could just look at the code instead of making up a strawman to try to dismiss the only evidence presented. Poor evidence > no evidence.
    - lpw25 13y ago
      It's not a strawman. Just look at the code for reverse-complement in Haskell. It is full of strictness annotations (unidiomatic) and uses inlinePerformIO (unsafe). It also uses a few inlining pragmas (unidiomatic). The fact that this code is fast tells you nothing about whether idiomatic Haskell is fast. wrong evidence < no evidence.
      - nousernamesleft 13y ago
        Yes, it is a strawman. Strictness annotations are not unidiomatic any more than using laziness is in ocaml. The ocaml code is effectively using unsafePerformIO all over, ocaml doesn't offer the safety you are complaining that the haskell example gives up. And both of your invalid complaints are completely irrelevant to the question at hand. The question was about difficulty, not a subjective idea of what idiomatic code looks like. Are you seriously claiming that the average haskell example there is more difficult to write than the average ocaml example? If so, just say that. Trying to redirect the discussion back to your subjective preferences is not productive.
        lpw25 13y ago
        Note that using `unsafePerformIO` is more unsafe than that, because the compiler assumes that functions are pure and will make transformations which alter the semantics in the presence of side effects. The OCaml compiler does not do these optimisations because it has to assume everything is impure. And `inlinePerformIO` is much more unsafe, because it requires that you do no memory allocation inside it. This property is specific to the Haskell implementation, and is certainly not easy to guarantee.
      - codygman 13y ago
talex5 13y ago
(blog author here) I certainly tried to treat them equally. If I cut-and-pasted from the web more often for the Haskell, it's because I got stuck more often. For example, I didn't need to search the web for how to read argv[0] in OCaml. It's just Sys.argv.(0). Easy. Would you really expect a beginner to figure out the Haskell version on their own?
- nousernamesleft 13y ago
  No, I would expect a beginner to use getProgName. I would also expect anyone else to use getProgName also.
  - talex5 13y ago
    That doesn't work. It only gives you the leaf (basename), not the path.
    - nousernamesleft 13y ago
      getExecutablePath
      - talex5 13y ago
        Thanks - good to know that's been fixed now. I don't know why all the previous requests were marked as "wontfix".
        nousernamesleft 13y ago
        Huh? Are you sure they weren't marked as duplicates of the original request made in 2010, which was closed as "fixed" in 2012? The functionality was available as a library on hackage starting in 2009. It was added to the standard library in 2012 as part of ghc 7.6.1. Your website says you were testing with 7.6.3. https://www.haskell.org/ghc/docs/latest/html/users_guide/release-7-6-1.html https://www.haskell.org/ghc/docs/latest/html/users_guide/rel...

by lpw25 13y ago

nousernamesleft 13y ago

>Not before writing his initial benchmarks Yes, he did. Try talking to him. >That measures ridiculous highly tuned implementations of the benchmarks So, fast code. Which is what is at question. >It contains absolutely no evidence of how hard it is to write fast programs in a language. There is both lines of code, and actually looking at the code itself. Both of which make it appear that writing fast code is no more difficult in haskell than in ocaml. >I'm pretty sure citing the language shoot-out is an automatic disqualification in any argument about language speed. I'm pretty sure the language shoot-out is of greater value as evidence than personal anecdote is.

lpw25 13y ago
> So, fast code. Which is what is at question. No the question is about whether fast code is easy to write, if it has to be highly tuned then it is not easy to write. > I'm pretty sure the language shoot-out is of greater value as evidence than personal anecdote is. Actually, I think that the shoot-out causes a lot of harm to people's attempts to understand whether a language is fast or not. When people ask: "Is language X fast?" what they mean is "if I write my programs in it will they be fast". They do not mean "is the highly tuned code of an expert fast". The question of whether a language is fast is about whether code written in the natural idioms of the language is fast, not about whether you can coerce the compiler into producing the precise assembly code you are aiming for. If you are going to do that you might as well write the assembly code directly and call it using an FFI. Many implementations on the shoot-out bare no resemblance to the code people naturally write in those languages.
- nousernamesleft 13y ago
  You could just look at the code instead of making up a strawman to try to dismiss the only evidence presented. Poor evidence > no evidence.
  - lpw25 13y ago
    It's not a strawman. Just look at the code for reverse-complement in Haskell. It is full of strictness annotations (unidiomatic) and uses inlinePerformIO (unsafe). It also uses a few inlining pragmas (unidiomatic). The fact that this code is fast tells you nothing about whether idiomatic Haskell is fast. wrong evidence < no evidence.
    - nousernamesleft 13y ago
      Yes, it is a strawman. Strictness annotations are not unidiomatic any more than using laziness is in ocaml. The ocaml code is effectively using unsafePerformIO all over, ocaml doesn't offer the safety you are complaining that the haskell example gives up. And both of your invalid complaints are completely irrelevant to the question at hand. The question was about difficulty, not a subjective idea of what idiomatic code looks like. Are you seriously claiming that the average haskell example there is more difficult to write than the average ocaml example? If so, just say that. Trying to redirect the discussion back to your subjective preferences is not productive.
      - lpw25 13y ago
        Note that using `unsafePerformIO` is more unsafe than that, because the compiler assumes that functions are pure and will make transformations which alter the semantics in the presence of side effects. The OCaml compiler does not do these optimisations because it has to assume everything is impure. And `inlinePerformIO` is much more unsafe, because it requires that you do no memory allocation inside it. This property is specific to the Haskell implementation, and is certainly not easy to guarantee.
    - codygman 13y ago

talex5 13y ago

(blog author here) I certainly tried to treat them equally. If I cut-and-pasted from the web more often for the Haskell, it's because I got stuck more often. For example, I didn't need to search the web for how to read argv[0] in OCaml. It's just Sys.argv.(0). Easy. Would you really expect a beginner to figure out the Haskell version on their own?

nousernamesleft 13y ago
No, I would expect a beginner to use getProgName. I would also expect anyone else to use getProgName also.
- talex5 13y ago
  That doesn't work. It only gives you the leaf (basename), not the path.
  - nousernamesleft 13y ago
    getExecutablePath
    - talex5 13y ago
      Thanks - good to know that's been fixed now. I don't know why all the previous requests were marked as "wontfix".
      - nousernamesleft 13y ago
        Huh? Are you sure they weren't marked as duplicates of the original request made in 2010, which was closed as "fixed" in 2012? The functionality was available as a library on hackage starting in 2009. It was added to the standard library in 2012 as part of ghc 7.6.1. Your website says you were testing with 7.6.3. https://www.haskell.org/ghc/docs/latest/html/users_guide/release-7-6-1.html https://www.haskell.org/ghc/docs/latest/html/users_guide/rel...