3 ms·

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

by ErrantX 17y ago

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)

RiderOfGiraffes 17y ago
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.
- ErrantX 17y ago
  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)
  - RiderOfGiraffes 17y ago
    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.
- gaius 17y ago
  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 ;-)
deleted 17y ago
[deleted]
scscsc 17y ago
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.
- RiderOfGiraffes 17y ago
  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.
  - eru 17y ago
    > 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.
    - geocar 17y ago
      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.
    - RiderOfGiraffes 17y ago
      >> 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. I can't tell if you're misunderstanding things deliberately - certainly your profile and history suggest that you're not a troll. 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.
RiderOfGiraffes 17y ago
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.
- ErrantX 17y ago
  > 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
  - 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 ago
      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?
ygd_coder 17y ago
I thought they used Ada?
- RiderOfGiraffes 17y ago
  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.

by ErrantX 17y ago

RiderOfGiraffes 17y ago

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.

ErrantX 17y ago
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)
- RiderOfGiraffes 17y ago
  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.
gaius 17y ago
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 ;-)

deleted 17y ago

[deleted]

scscsc 17y ago

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.

RiderOfGiraffes 17y ago
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.
- eru 17y ago
  > 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.
  - geocar 17y ago
    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.
  - RiderOfGiraffes 17y ago
    >> 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. I can't tell if you're misunderstanding things deliberately - certainly your profile and history suggest that you're not a troll. 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.

RiderOfGiraffes 17y ago

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.

ErrantX 17y ago
> 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
- 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 ago
    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?

ygd_coder 17y ago

I thought they used Ada?

RiderOfGiraffes 17y ago
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.