Clickable:

http://news.ycombinator.com/item?id=901101

http://rapidred.com/blog/seven_languages

http://news.ycombinator.com/item?id=901335

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)

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.

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.

> 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.

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.

  >> 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.

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.]

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.

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)

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 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 ;-)

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, 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

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?

;) 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.

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.

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.

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.

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".

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.

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.