5 ms·

One of the main uses of valgrind is to discover undefined behavior. Haskell doesn't have undefined behavior, so you don't need it. I don't think the C tooling

by Peaker 13y ago

One of the main uses of valgrind is to discover undefined behavior. Haskell doesn't have undefined behavior, so you don't need it. I don't think the C tooling is that great. Haskell has some neat tooling of its own.

taeric 13y ago
I think you are misrepresenting valgrind some. Just going by the bullet list on their homepage, they do more than just undefined. Offering fairly nice analysis at the cache level. Also, has support for finding threading errors. Note, this isn't just a "do mutexes work" sort of thing, but offers analysis that shared memory is safely shared. (And, from my understanding, this doesn't require modification of the code to make it slower/larger.) So, this really doesn't answer my question. I can't but agree that the tooling in Haskell is above that of plain C. However, what class of bugs will be prevented in the kernel, that isn't already fairly well handled with existing tooling. Consider that the kernel is actually fairly solid code, if I'm not off my rocker.
- codygman 13y ago
  Wouldn't "class of bugs prevented by tooling" not be quite as good as "class of bugs disallowed by programming language"?
  - agentultra 13y ago
    You might end up in the trap of only writing correct bugs.
    - codygman 13y ago
      Correct bugs, logic errors I'm assuming, are a better problem to have than logic errors + undefined behavior in my opinion.
      - agentultra 13y ago
        Undefined behavior is a perfectly acceptable abstraction [1]. The C specification is pretty clear on what it has purposefully left undefined which has made it rather resilient to changes in underlying hardware architectures. Must be why Haskell's run-time support is written in C [2] [1] http://thoughtmesh.net/publish/367.php http://thoughtmesh.net/publish/367.php [2] https://github.com/ghc/ghc/tree/master/rts https://github.com/ghc/ghc/tree/master/rts
        Peaker 13y ago
        Undefined behavior has advantages, of course. The C language is excellent at certain things, too. However, not every kernel driver and not every application needs the benefit of C or undefined behavior. The fact that Haskell's RTS is written in C is evidence that the kind of code in RTS's has more to gain from C than from Haskell. Some parts of drivers might also be best written in C.
        codygman 13y ago
        I will have to check that video out. I'm aware that Haskell's run-time support is written in C and I don't believe that is a mistake. Right tool for the job after all. For many use cases in my experience though, you don't want undefined behavior.
    - Peaker 13y ago
      With rich types, you can get rid of the correct bugs, too. You can encode an arbitrary amount of information into a verified, proven specification. The specification is orders of magnitude smaller and simpler than the actual code, so much easier to get correct.
      - agentultra 13y ago
        I've heard that before. "Proven," in as far as you trust the axioms and assumptions made by the Haskell compiler. It's an important distinction because you must assume that the 50k lines of C code that get compiled and statically linked into your Haskell programs is also, "correct," by extension despite it living outside the set of axioms and assumptions your program has been proven within. Don't get me wrong, Haskell is a neat language, I just don't accept its trade-offs for most of the work I do.
        codygman 13y ago
        That's certainly a valid opinion, but I believe you may be doing yourself a disservice by not trying to use Haskell in some of that work you do. However I can't say that for sure yet, I'm still evaluating how useful Haskell is for me in my "real world" tasks. Thus far I've been able to accomplish things rather easily, but I don't believe I've written enough to form a solid opinion yet. As far as the Haskell compiler living outside of that set of axioms and assumptions my program has been proven with, that is something that does needle me a little but it seems to be a smaller hole than most languages are working with.
        Peaker 13y ago
        Sure, you'll hit an underlying platform bug, once in a few years, whether in the RTS or the OS.. But you'll prevent orders of magnitude more bugs that would waste your time debugging in the best case, or hit production in a slightly worse case.
  - astrobe_ 13y ago
    The problem is that, from a pragmatic perspective, you have to balance the benefits of a safer language and the cost of "explaining" to it that what you're doing is safe. If you want to make it accept a particular construct as "safe", you have to feed it with a lot more information, whereas in a more permissive language you can just be imperative and tell it "I know it's ok, just do it". The tooling approach is, it seems, more attractive because it adds a bit of safety at a moderate cost.
    - codygman 13y ago
      I guess I'm different in that I prefer to have a substantial amount of safety with "safe" code. If it's something that doesn't require that safety, it seems that something truly dynamic like lisp or racket is best. For intstance, languages with weak static typing seem to lead to "stringly typed" solutions.
    - chongli 13y ago
      The tooling approach is, it seems, more attractive because it adds a bit of safety at a moderate cost. There's one cost you've ignored: feedback time. A type-checker can be run on the fly with tools such as flymake. Debugging tools and tests are (orders of magnitude) slower to run and thus dramatically slow down the feedback cycle between bug detection and bug fix. This is especially prevalent when doing major refactoring work and the code is a long way from working again.
  - taeric 13y ago
    Right, which is why I was asking which class of bugs are we talking about. If "undefined" is the only class that this would remove, it sounds less than compelling. Especially if it in any way impedes considering the logic of what is actually getting done. (I mean, correct me if I'm wrong and "undefined" is actually a large part of the problems that afflict writing code for the kernel.)

by Peaker 13y ago

taeric 13y ago

I think you are misrepresenting valgrind some. Just going by the bullet list on their homepage, they do more than just undefined. Offering fairly nice analysis at the cache level. Also, has support for finding threading errors. Note, this isn't just a "do mutexes work" sort of thing, but offers analysis that shared memory is safely shared. (And, from my understanding, this doesn't require modification of the code to make it slower/larger.) So, this really doesn't answer my question. I can't but agree that the tooling in Haskell is above that of plain C. However, what class of bugs will be prevented in the kernel, that isn't already fairly well handled with existing tooling. Consider that the kernel is actually fairly solid code, if I'm not off my rocker.

codygman 13y ago
Wouldn't "class of bugs prevented by tooling" not be quite as good as "class of bugs disallowed by programming language"?
- agentultra 13y ago
  You might end up in the trap of only writing correct bugs.
  - codygman 13y ago
    Correct bugs, logic errors I'm assuming, are a better problem to have than logic errors + undefined behavior in my opinion.
    - agentultra 13y ago
      Undefined behavior is a perfectly acceptable abstraction [1]. The C specification is pretty clear on what it has purposefully left undefined which has made it rather resilient to changes in underlying hardware architectures. Must be why Haskell's run-time support is written in C [2] [1] http://thoughtmesh.net/publish/367.php http://thoughtmesh.net/publish/367.php [2] https://github.com/ghc/ghc/tree/master/rts https://github.com/ghc/ghc/tree/master/rts
      - Peaker 13y ago
        Undefined behavior has advantages, of course. The C language is excellent at certain things, too. However, not every kernel driver and not every application needs the benefit of C or undefined behavior. The fact that Haskell's RTS is written in C is evidence that the kind of code in RTS's has more to gain from C than from Haskell. Some parts of drivers might also be best written in C.
      - codygman 13y ago
        I will have to check that video out. I'm aware that Haskell's run-time support is written in C and I don't believe that is a mistake. Right tool for the job after all. For many use cases in my experience though, you don't want undefined behavior.
  - Peaker 13y ago
    With rich types, you can get rid of the correct bugs, too. You can encode an arbitrary amount of information into a verified, proven specification. The specification is orders of magnitude smaller and simpler than the actual code, so much easier to get correct.
    - agentultra 13y ago
      I've heard that before. "Proven," in as far as you trust the axioms and assumptions made by the Haskell compiler. It's an important distinction because you must assume that the 50k lines of C code that get compiled and statically linked into your Haskell programs is also, "correct," by extension despite it living outside the set of axioms and assumptions your program has been proven within. Don't get me wrong, Haskell is a neat language, I just don't accept its trade-offs for most of the work I do.
      - codygman 13y ago
        That's certainly a valid opinion, but I believe you may be doing yourself a disservice by not trying to use Haskell in some of that work you do. However I can't say that for sure yet, I'm still evaluating how useful Haskell is for me in my "real world" tasks. Thus far I've been able to accomplish things rather easily, but I don't believe I've written enough to form a solid opinion yet. As far as the Haskell compiler living outside of that set of axioms and assumptions my program has been proven with, that is something that does needle me a little but it seems to be a smaller hole than most languages are working with.
      - Peaker 13y ago
        Sure, you'll hit an underlying platform bug, once in a few years, whether in the RTS or the OS.. But you'll prevent orders of magnitude more bugs that would waste your time debugging in the best case, or hit production in a slightly worse case.
- astrobe_ 13y ago
  The problem is that, from a pragmatic perspective, you have to balance the benefits of a safer language and the cost of "explaining" to it that what you're doing is safe. If you want to make it accept a particular construct as "safe", you have to feed it with a lot more information, whereas in a more permissive language you can just be imperative and tell it "I know it's ok, just do it". The tooling approach is, it seems, more attractive because it adds a bit of safety at a moderate cost.
  - codygman 13y ago
    I guess I'm different in that I prefer to have a substantial amount of safety with "safe" code. If it's something that doesn't require that safety, it seems that something truly dynamic like lisp or racket is best. For intstance, languages with weak static typing seem to lead to "stringly typed" solutions.
  - chongli 13y ago
    The tooling approach is, it seems, more attractive because it adds a bit of safety at a moderate cost. There's one cost you've ignored: feedback time. A type-checker can be run on the fly with tools such as flymake. Debugging tools and tests are (orders of magnitude) slower to run and thus dramatically slow down the feedback cycle between bug detection and bug fix. This is especially prevalent when doing major refactoring work and the code is a long way from working again.
- taeric 13y ago
  Right, which is why I was asking which class of bugs are we talking about. If "undefined" is the only class that this would remove, it sounds less than compelling. Especially if it in any way impedes considering the logic of what is actually getting done. (I mean, correct me if I'm wrong and "undefined" is actually a large part of the problems that afflict writing code for the kernel.)