Programming language choice - sometimes there is none.
3 comments
The ATC example is probably fairly bad one - because the real reason they would want it in C++ is that there are a bazillion very good C++ programmers they can grab to fix stuff in emergencies.
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)
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)
With all due respect to/admiration for Scala, I would not want it anywhere near safety critical systems, simply because there has not been a lot of code written in it.
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.
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.
You make my point.
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.
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 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.
That would not be so much of a problem. Scheme is certainly older than 20 years, now. Python comes close.
Not exactly the same thing.
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.
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.
Sorry, I was being too laconic for my own good. I meant, the age isn't the problem. (Even if Scheme and Python aren't old enough, Common Lisp and some version of ML might be.)
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.]
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.]
Summary: The point stands - the customer sometimes demands C++.
(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.
(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.
No my point was that if a critical bug appears in the system and you, the original contractor, has dropped off the radar (or whatever) they stand a much higher chance of finding someone to fix it.
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)
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 suspect we are in "Violent Agreement". I also believe the chances of finding, say, a good enough Scala programmer to fix this software that has a problem are actually higher than the chances of finding a good enough C++ programmer to fix this other software that has a problem.
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.
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.
I am sure some HR department somewhere has quantified this. If x Lisp programmers can do the work of y Blub programmers where x << y, and the difficulty of hiring one Blub programmer is p, and the salary of a Blub programmer s, what value of z in (pz, sz)makes it worthwhile changing languages?
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 ;-)
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 ;-)
Sorry, adding a second comment rather than editing the first ...
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.
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.
> 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, becuase we know that hiring good programmers is hard.
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
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
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.
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?
;) 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.
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 :)
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.
You can model a surprising amount of rules with a good type system. Though not all.
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.
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.)
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.)
I think filtering the candidates for a C++ position by their knowledge of non-mainstream languages would probably result in a much better candidates set.
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".
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".
[deleted]
I thought they used Ada?
a. You're discussing the color of the bikeshed
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.
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.
I'm just going to repeat it until every programmer in the world gets it: context is everything.
In truth, most of this conservatism is cultural rather than driven by any cost or fundamental technical issue.
Though heavy exceptions do apply when dealing with system call interfaces to hard real-time kernels used in avionics software and medical applications such as heart pacemakers.
Though heavy exceptions do apply when dealing with system call interfaces to hard real-time kernels used in avionics software and medical applications such as heart pacemakers.
people were talking about how useful it is for programmers to know non-mainstream languages.
jlgosse said:
In the reply, dschobel said:
This is absolutely true, but there are two main points I'd like to make.
Firstly, the real benefits in having knowledge of (but preferrably experience and skill in) other languages, is not getting a job using them. The real benefit is to you, the programmer, having more ideas, knowledge, tools and skills under you belt. Even if you only ever program in C++ or Java or PHP, learning Lisp or Haskell or Prolog or Lucid will make you a better programmer. No longer will every problem look like a nail, because no longer will you only have a hammer.
Along with that, though, is the questionof experience. Reading about these techniques and ideas doesn't really help, you have to use them for real to get the benefit.
In medicine there is the mantra "See one, do one, teach one." It applies equally in programming.
Secondly, a point about companies employing programmers. When tendering for a contract in my field, it is often required that the bidder attest to the fact that the system is written in ...
They then usually add a phrase that makes it clear that they mean C++, and if your system isn't written in C++ then you won't pass the first phase of reviews.
You, as I do, may howl and rage at such short-sightedness, but there are industries where such things are stated in contracts.
For example (and this is not my area) can you imagine supplying an Air Traffic Control system written entirely in Scala? Technically it may be a brilliant choice, but in the ultra-conservative world of ATC (and other safety-critical fields), systems written in what they will see as an untried, untested language, by programmers who by necessity only have a year of experience in that language, are a dangerous experiment.
"Nobody ever got fired for buying IBM" is still a prevailing mantra, only now it's about langauges, as well as hardware. You can't supply anything other than COTS (Commercial off-the-shelf) hardware, by which they mean PCs.
In the fast-paced, nothing is the same week-to-week world of web development and web-based applications it doesn't matter, but in my world it does.
I just thought it might be interesting for some of you to hear about a different context.