6 ms·

Another thing about C is it's also debuggable and, consequently, profilable. You don't need to guess like the article's author at what is slow. You can know exa

Another thing about C is it's also debuggable and, consequently, profilable. You don't need to guess like the article's author at what is slow. You can know exactly what functions are slow and also why by examining hazards reported for every instruction. And then you can change your program in a way, which will eliminate the hazards if you wish so (and if it's possible, of course). With a smart high level compiler, even if you will manage to match the binary to source somehow, good luck predicting what modifications to the source are going to do to the binary. Debuggability is also often overlooked. You can attach a debugger to a running image, and, provided you have symbol names, figure what's going on. Even if all you have is a core dump you can make a good guess of what has happened most of the time. Trying Haskell and doing some research on debugging it seems the only way other than debug prints is to instrument your program and even then you are not getting much.

pjmlp 10y ago
Haskell also has debugging and profiling tools, e.g. ThreadScope. Actually the languages that don't, aren't worth using in production environments, this isn't anything C special.
- pandaman 10y ago
  Language-specific profiling and debugging tools are not the tools I had in mind. Being language-specific and system-agnostic they are naturally blind to the details of the execution which don't exist in the language. E.g. things like cache misses, TLB misses, jump miss-predictions, etc etc. I somehow doubt Haskell has tools for this. Same with the debugger - you sure can set breakpoints in GHCi, but what do you do with a core dump? What if you have a bug, which happens on a single machine in Bangladesh and takes 18 hours to reproduce? With C I can just connect with the system level debugger and, at least, know what happens. Is there such a tool for Haskell? PS. And, again, even if such tools existed they were just for informational purposes since you don't have much control over the generated code so you cannot sensibly modify source to change the binary in expected way. For example, in C, if I see a high number of cache misses in some loop I can: a) change the data layout (e.g. align structure fields or move simultaneously accessed fields together) b) add a prefetch. What am I to do in Haskell?
  - pjmlp 10y ago
    I guess you can use tools like V-Tune for that. You can also do layout changes in Haskell, for example use a ByteString instead of Text, or an Array instead of Lists and so on. What you mean by doing prefetchin C? There isn't any ANSI C feature for that. Only compiler tricks and hope for the best.
    - pandaman 10y ago
      >I guess you can use tools like V-Tune for that. And I am saying you cannot. >What you mean by doing prefetchin C? There isn't any ANSI C feature for that. Actually, there is, it's called inline assembly. But any decent compiler has an intrinsic anyways. >You can also do layout changes in Haskell, for example use a ByteString instead of Text, or an Array instead of Lists and so on. So, I have this type data Vector3 = Vector3 Float Float Float. Can I change its layout without having to change the rest of the code? The only way I know is compiler-specific unboxing and even that has little predictable effect, as we don't even know if this type is going to hold boxed values to begin with.
      - pjmlp 10y ago
        > Actually, there is, it's called inline assembly. But any decent compiler has an intrinsic anyways. Which is a language extension and not a C feature. Nothing prevents an Haskell compiler to provide similar extensions. > So, I have this type data Vector3 = Vector3 Float Float Float. Can I change its layout without having to change the rest of the code? The only way I know is compiler-specific unboxing and even that has little predictable effect, as we don't even know if this type is going to hold boxed values to begin with. Yeah, with my limited Haskell knowledge I would say you would need to make use of Data.Vector.Unboxed or use unboxed values as compiler extension like on JHC. Still, there are ways to improve performance on Haskell applications, even if they require new ways of thinking. Back in the day higher level languages (including C) were quite bad at generating code on home computers, and we had to use Assembly if we cared about performance. So like C compiler quality and tooling has improved in these last decades due to high industry use, Haskell tools can also improve if its acceptance in the industry keeps increasing. And then we can probably enjoy such tools for Haskell as well.
- tmptmp 10y ago
  Try telling that thing about Haskell to actual enterprise developers. The lazy evaluation puts even experienced veterans off the track when it comes to profiling/speak-leaks/debugging. Haskell support is lousy for debugging and profiling except for toy programs, period. AFAIK, Standard Charter has asked the devs to develop an entirely different language which is not lazy at all. "Interestingly, Mu eschews Haskell’s laziness and is a strict language instead." [1] The Haskell community is silent on getting rid of lazy-ness from it or at least making it completely and entirely optional for people. So let me repeat this even if Haskell is good to train your mind in the comfort of your home, it is miles far from being enterprise ready. [1] http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf
  - pjmlp 10y ago
    You mean this type of enterprises? https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
    - deleted 10y ago
      [deleted]
    - LionessLover 10y ago
      https://en.wikipedia.org/wiki/Name-dropping https://en.wikipedia.org/wiki/Name-dropping For people without an argument. Because then you would have to know what those firms actually do. Read this: http://flyingfrogblog.blogspot.de/2010/05/why-is-haskell-used-so-little-in.html http://flyingfrogblog.blogspot.de/2010/05/why-is-haskell-use... It's from 2010 so things may be different - but it illustrates that you can't just drop names, you have to do your research.
      - merijnv 10y ago
        To be fair, John Harrop is notorious for having an axe to grind with Haskell. He's very knowledgable, but often makes gross mischaracterisations of Haskell. Which is a shame, because he knows better than that.
colinb 10y ago
I'm largely ignorant of Haskell, but isn't one the touted benefits of strictly typed languages (bondage and discipline typing I've heard it called) that SEGVs simply don't happen? I've built fairly complex systems written in similar languages which were capable of crashing in the sense of an un-handleable OOM, but they didn't just trip over a bad pointer and die. If this is more widely true of such languages, and not just an artefact of the implementation and problem domain I was working in, then perhaps the need to attach a debugger to running systems, or corefile-spelunk, is reduced. What do you think of that? FWIW, I would still have liked a better debugger on the system I used. We had a small team and they were making hard choices about what was capable of being implemented in the time to hand. So I did a bunch of printf-debugging of my logic, and learned to right some log-file analysis tools. But it never crashed.
- pandaman 10y ago
  Strict typing eliminates some run-time bugs but not all of them. You can type "tail []" in any Haskell interpreter and see what's going to happen. Also there are logical bugs, which won't go away. For example you typed '-' instead of '+' somewhere. Type system won't care since both operators are the same type but suddenly you get a bug report that the player character in a videogame sometimes shoves his gun up his ass instead of holstering it.
  - lkitching 10y ago
    The behaviour of 'tail []' is not a failure of static typing but of the specified type of tail. tail is partial but fails to represent that in its type when it could easily do so. Changing it to List a -> Maybe (List a) would be more accurate, albeit possibly a little more confusing for beginners.
    - pandaman 10y ago
      I agree. The point is that Haskell still throws run-time exceptions.
majewsky 10y ago
I've only done a bit of Haskell, but when I build a Haskell program, I usually debug a function with GHC's builtin REPL (ghci), by checking expressions inside the function until I find the place where their evaluation does not match my expectation. It's similar to printf debugging, but less tedious and more informative because e.g. you can get type information about subexpressions immediately. I can't say anything on debugging large-ish programs, though. Regarding profiling, GHC's runtime system includes a profiler that looks fairly competent from what I've seen. (For example, you can mark expressions that you want profiled, or you can just go with profiling per function.)

pjmlp 10y ago

Haskell also has debugging and profiling tools, e.g. ThreadScope. Actually the languages that don't, aren't worth using in production environments, this isn't anything C special.

pandaman 10y ago
Language-specific profiling and debugging tools are not the tools I had in mind. Being language-specific and system-agnostic they are naturally blind to the details of the execution which don't exist in the language. E.g. things like cache misses, TLB misses, jump miss-predictions, etc etc. I somehow doubt Haskell has tools for this. Same with the debugger - you sure can set breakpoints in GHCi, but what do you do with a core dump? What if you have a bug, which happens on a single machine in Bangladesh and takes 18 hours to reproduce? With C I can just connect with the system level debugger and, at least, know what happens. Is there such a tool for Haskell? PS. And, again, even if such tools existed they were just for informational purposes since you don't have much control over the generated code so you cannot sensibly modify source to change the binary in expected way. For example, in C, if I see a high number of cache misses in some loop I can: a) change the data layout (e.g. align structure fields or move simultaneously accessed fields together) b) add a prefetch. What am I to do in Haskell?
- pjmlp 10y ago
  I guess you can use tools like V-Tune for that. You can also do layout changes in Haskell, for example use a ByteString instead of Text, or an Array instead of Lists and so on. What you mean by doing prefetchin C? There isn't any ANSI C feature for that. Only compiler tricks and hope for the best.
  - pandaman 10y ago
    >I guess you can use tools like V-Tune for that. And I am saying you cannot. >What you mean by doing prefetchin C? There isn't any ANSI C feature for that. Actually, there is, it's called inline assembly. But any decent compiler has an intrinsic anyways. >You can also do layout changes in Haskell, for example use a ByteString instead of Text, or an Array instead of Lists and so on. So, I have this type data Vector3 = Vector3 Float Float Float. Can I change its layout without having to change the rest of the code? The only way I know is compiler-specific unboxing and even that has little predictable effect, as we don't even know if this type is going to hold boxed values to begin with.
    - pjmlp 10y ago
      > Actually, there is, it's called inline assembly. But any decent compiler has an intrinsic anyways. Which is a language extension and not a C feature. Nothing prevents an Haskell compiler to provide similar extensions. > So, I have this type data Vector3 = Vector3 Float Float Float. Can I change its layout without having to change the rest of the code? The only way I know is compiler-specific unboxing and even that has little predictable effect, as we don't even know if this type is going to hold boxed values to begin with. Yeah, with my limited Haskell knowledge I would say you would need to make use of Data.Vector.Unboxed or use unboxed values as compiler extension like on JHC. Still, there are ways to improve performance on Haskell applications, even if they require new ways of thinking. Back in the day higher level languages (including C) were quite bad at generating code on home computers, and we had to use Assembly if we cared about performance. So like C compiler quality and tooling has improved in these last decades due to high industry use, Haskell tools can also improve if its acceptance in the industry keeps increasing. And then we can probably enjoy such tools for Haskell as well.
tmptmp 10y ago
Try telling that thing about Haskell to actual enterprise developers. The lazy evaluation puts even experienced veterans off the track when it comes to profiling/speak-leaks/debugging. Haskell support is lousy for debugging and profiling except for toy programs, period. AFAIK, Standard Charter has asked the devs to develop an entirely different language which is not lazy at all. "Interestingly, Mu eschews Haskell’s laziness and is a strict language instead." [1] The Haskell community is silent on getting rid of lazy-ness from it or at least making it completely and entirely optional for people. So let me repeat this even if Haskell is good to train your mind in the comfort of your home, it is miles far from being enterprise ready. [1] http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf http://anil.recoil.org/papers/2011-cufp-scribe-preprint.pdf
- pjmlp 10y ago
  You mean this type of enterprises? https://wiki.haskell.org/Haskell_in_industry https://wiki.haskell.org/Haskell_in_industry
  - deleted 10y ago
    [deleted]
  - LionessLover 10y ago
    https://en.wikipedia.org/wiki/Name-dropping https://en.wikipedia.org/wiki/Name-dropping For people without an argument. Because then you would have to know what those firms actually do. Read this: http://flyingfrogblog.blogspot.de/2010/05/why-is-haskell-used-so-little-in.html http://flyingfrogblog.blogspot.de/2010/05/why-is-haskell-use... It's from 2010 so things may be different - but it illustrates that you can't just drop names, you have to do your research.
    - merijnv 10y ago
      To be fair, John Harrop is notorious for having an axe to grind with Haskell. He's very knowledgable, but often makes gross mischaracterisations of Haskell. Which is a shame, because he knows better than that.

colinb 10y ago

I'm largely ignorant of Haskell, but isn't one the touted benefits of strictly typed languages (bondage and discipline typing I've heard it called) that SEGVs simply don't happen? I've built fairly complex systems written in similar languages which were capable of crashing in the sense of an un-handleable OOM, but they didn't just trip over a bad pointer and die. If this is more widely true of such languages, and not just an artefact of the implementation and problem domain I was working in, then perhaps the need to attach a debugger to running systems, or corefile-spelunk, is reduced. What do you think of that? FWIW, I would still have liked a better debugger on the system I used. We had a small team and they were making hard choices about what was capable of being implemented in the time to hand. So I did a bunch of printf-debugging of my logic, and learned to right some log-file analysis tools. But it never crashed.

pandaman 10y ago
Strict typing eliminates some run-time bugs but not all of them. You can type "tail []" in any Haskell interpreter and see what's going to happen. Also there are logical bugs, which won't go away. For example you typed '-' instead of '+' somewhere. Type system won't care since both operators are the same type but suddenly you get a bug report that the player character in a videogame sometimes shoves his gun up his ass instead of holstering it.
- lkitching 10y ago
  The behaviour of 'tail []' is not a failure of static typing but of the specified type of tail. tail is partial but fails to represent that in its type when it could easily do so. Changing it to List a -> Maybe (List a) would be more accurate, albeit possibly a little more confusing for beginners.
  - pandaman 10y ago
    I agree. The point is that Haskell still throws run-time exceptions.

majewsky 10y ago

I've only done a bit of Haskell, but when I build a Haskell program, I usually debug a function with GHC's builtin REPL (ghci), by checking expressions inside the function until I find the place where their evaluation does not match my expectation. It's similar to printf debugging, but less tedious and more informative because e.g. you can get type information about subexpressions immediately. I can't say anything on debugging large-ish programs, though. Regarding profiling, GHC's runtime system includes a profiler that looks fairly competent from what I've seen. (For example, you can mark expressions that you want profiled, or you can just go with profiling per function.)