4 ms·

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.

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.