Finding a solid Scala programmer in a pinch is less easy
(we do some work on Bank software and they do the same thing pretty much)
There are essentially two ways we learn to trust stuff. Either (a) we have it (formally) proved (no one reasonable doubts 1 + 1 = 2) or (b) we rely on tons of everyday experience to note that it doesn't fail (we mostly trust our cars).
Scala has neither. I would not be surprised if the compiler contained serious bugs.
Many programmers only have experience of web applications or services, and complain that some dinosaurs insist on 20-year-old languages.
My point is that there are fields in which this convservatism is the correct attitude, and that programmers who point the finger and laugh at such out-dated thinking lack experience.
I work in a field that requires fewer bugs than most (although it's not as severe as ATC), and we don't have much choice about the languages we use.
That would not be so much of a problem. Scheme is certainly older than 20 years, now. Python comes close.
The R3RS that existed in 1989 lacked macros, had t and nil, and even allowed implementations to "call" strings. Even ten years ago, Python, as it existed in 1999 was a very different language than it is today.
Moreover, Python and scheme implementations have code that "worked" only a few years ago that fails to run on the current version of the interpreters, while gcc still happily recompiles my pre-ansi C just fine.
>> that some dinosaurs insist on 20-year-old languages
> That would not be so much of a problem. Scheme is
> certainly older than 20 years, now. Python comes close.
The point isn't about age, it's about the popularity and maturity of the language, and through them, the acceptability.
But I'm pretty sure you knew that, so maybe I'm missing something deeper in your comment.
As you say, it is about the `mainstreamness' of the language.
Insert:
>> That would not be so much of a problem. [But there are other problems.]
(Note: I am the OP - it's my example.)
I think you are supporting the example - the point you make is a large part of the ATC reasoning. Customers demand that their systems are written in a language that they feel confident they can, in a pinch, take over and hire programmers to fix. They believe they can do that for C++, they don't know anything about anything else.
We also have to put code in escrow for this very reasons. We have to provide a package that can be put on a stock piece of hardware and then build the deliverable. Then the auditor checks that the code "looks reasonable," at which point the repository is put on some external device and locked in a safe.
They believe that if it's in a language they've heard of, and have heard is popular, then they can go out and hire programmers to work on the code if they ever have reason to do so.
This is what we do for Bank software; they find a critical flaw that needs fixing and it is our job to hunter-killer for it and work with their team to nail it and integrate the solution.
I agree with the point you were making; just I felt the example was more driven by a different need (one very specific to that piece of software)
(or look at it another way there is much more likely to be a C programmer with experience in ATC software, an important sub-skill in this case, than a Scala one :D)
I have no evidence, the reasoning is outlined in my other comment. I suspect we agree on all major points, and that things should be better than they are.
The last company I worked for did exactly the same thing. Every major release, would would provide a detailed set of instructions, the code, the exact kit list, etc to run up our app and give it to the auditors. Not sure how much use this actually was; our customers already had running systems, and the knowledge of the problem domain was what they were paying us for, not that we were really good at typing into Emacs. And it took us who knew the codebase well 6-12 months to get a programmer to the point at which they could be truly useful with it. But at least, if it had all gone hatstand, someone might have had a fighting chance. Or one of our customers could have just hired us directly and we'd have kept working on it ;-)
It's a fallacy that one can simply go out and grab any one of a bazillion very good C++ programmers whenever you like/need, because we know that hiring good programmers is hard.
It's even harder to hire good programmers who can pick up a large chunk of code they've never seen and make expert changes to fix subtle errors.
I would claim that C++ is exactly the wrong choice, because any Scala (say) programmer already has to be above average in interest and ability, and the code probably won't be subtle or "clever" (in the worst sense).
But that's another rant ...
EDIT: Speeling.
Agreed; however your still missing the focus of the example. With a critical super urgent bug in a piece of ATC software it is MUCH easier to track down a competent C++ programmer within the hour (at any time of the day) than a Scala one - simply on the statistics of it :D
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.
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.
Also, its not clear that C++ is absolutely the wrong choice. You must also consider the fact that our field has its share of brilliant butterflies that are "above average in interest" for sure, but not necessarily in "ability".
b. ATC systems often use languages that pre-date Ada.
c. The point remains - often the technical people don't get the choice of language. This is the most relevant point when you put this in the context of the discussion from which it branched.