;) 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 software we are discussing.
I agree with what your saying, just don't know how applicable it is to the class of software we are discussing.
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 :)
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.
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.)
if (customer_should_get_charged_00001()) {
account += 0.00001;
}
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.