It would appear to me if you ever hit the failure mode of needing a C++ programmer within the hour, to fix a completely unknown codebase. It very much seems to me like you have already lost.
As far as I have seen the verification and testing process before deployment, takes on the order of a months. Let alone how long it takes to really understand a codebase, and the potential ramifications of a change. Also it is not like you can hire any C++ programmer, you need someone versed in the subset and style that is used in these safety critical areas.
Seems like you are optimizing for something that isn't really an issue, and if it ever becomes an issue you are likely to have much bigger problems. If you lose the people with all your domain knowledge, and understanding of how it is build and why. I would argue that language is the least of your issues.
Not every problem requires a super-latented programmer. Need a product rebuilt with a hard-coded parameter change ? Your marketing guy won't be able to do it; most any C++ programmer can fumble thru.
Turn it on its head: how many times have you been bitten by wanting to change a subsystem slightly, that you are NOT familiar with? In a hurry? Wishing all the time it had written in YOUR favorite paradigm instead of the foolish choice of whomever authored it?
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 :)
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.
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.
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.
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.
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.)
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.
For a serious accounting package, I would wrap up all money calculations, in such a way that you can't get away from double ledger accounting. So no money would ever be lost or created and all the flows are traceable.
Again, I don't see how that's anywhere near difficult in C++. This discussion doesn't seem to be going anywhere, especially since there was never a real bug to start with. I'm just annoyed that every time someone even mentions a (fictional!) bug, the problem is "using C++".
Oh, sorry. I just replied to your comment doubting the use of type systems. I did not want to make a statement about C++. I guess you could make C++ dance, if you tried and were smart enough.
As far as I have seen the verification and testing process before deployment, takes on the order of a months. Let alone how long it takes to really understand a codebase, and the potential ramifications of a change. Also it is not like you can hire any C++ programmer, you need someone versed in the subset and style that is used in these safety critical areas.
Seems like you are optimizing for something that isn't really an issue, and if it ever becomes an issue you are likely to have much bigger problems. If you lose the people with all your domain knowledge, and understanding of how it is build and why. I would argue that language is the least of your issues.