5 ms·
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
by yrb 17y ago
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.
- JoeAltmaier 17y agoNot 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?
- yrb 17y ago;) 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.
- ErrantX 17y agovery. 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 agoWhat 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 agoUm 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 agoI'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 agoYou can model a surprising amount of rules with a good type system. Though not all.
- tedunangst 17y agoDoes 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.