4 ms·

;) How many "innocent" hurried changes have you seen blow up in production. I agree with what your saying, just don't know how applicable it is to the class of

• ErrantX 17y ago
  very. There are some extremely good programmers who make a living by being available at a moments notice to fix critical bugs. If you have a variable introducing a $0.0001 accounting error into some bank software it doesn't take long for that to stack up. If said bank delays for even a few hours in rushing a fix they could be screwed (note: this happens a surprising amount). I suspect ATC requires a lot less critical fixing but there are parallels. You pay a guy $1000 an hour to shore it up in 2. Then employ a contractor to build and test a proper fix for next month. I would like to point out Im not disagreeing with Rider at all :)
  • kscaldef 17y ago
    What I find distressing about this example is that it's being used to support the idea of writing such systems in C++, where such errors are very easy to make; rather than in a language where you can protect against it in the type system.
    • JoeAltmaier 17y ago
      Um hm, and in a vacuum or some alternate reality where your favorite paradigm won out, that would be practical for companies. But at the moment, the ecosystem consists of millions of C++ beasts, with a few exotic animals grazing among them. All the herd owners will be hiring cowboys for what they have; most of the cowboys will know how to handle C++. I'm on your side somewhat; pity the poor big company that needs not just a few good developers, but hundreds, and has to write a position description that has a chance of netting those hundreds.
    • tedunangst 17y ago
      I'm not sure how a type system can protect against accounting errors, and I'm even less sure how the type system would know what accounting rules to apply without human input.
      • eru 17y ago
        You can model a surprising amount of rules with a good type system. Though not all.
        • tedunangst 17y ago
          Does catching a $0.0001 accounting error fall into the "surprising amount" or "not all" bucket? Because that's the example at hand. I'm not surprised at all by what you can do with a type system. But type system fanboys (yes, I have to use the word) always have the same arguments. "You can do lots of stuff with types. Oh, except maybe for your actual example." It's not convincing, it's just noise that shows up whenever somebody is using the "wrong" language.
          • eru 17y ago
            If you could flesh out your example, I could try to answer whether the $0.0001 accounting error might be catchable. Thanks! A type system like Haskell's can guide your programming in general and leave more of your mental resources to solve the problem at hand. As an anecdote: I have found, that with some QuickCheck tests/rules and some hard thinking about the right types, I can extend my programs even when I can't concentrate 100%. (A situation that usually just gives me Segmentation Faults in C.)
            • tedunangst 17y ago
              if (customer_should_get_charged_00001()) { account += 0.00001; } It wasn't my example to start, but I'll roll with it. The bug, of course, is that we're adding and not subtracting. The more obvious example where somebody has 0.01 dollars and it gets put in a cents variable, turning into 0.0001 dollars, is also easily solvable with the C++ type system.