Re: F-22 ADA Programming

[Maciej Sobczak <see.my.homepage@gmail.com>]

> > That C++ bugs have more severe consequences than Ada bugs? :-)
> 
> Are you kidding me?
> 
> Are you not aware that buffer overflows are a major

Yes, I am. And the recent Heartbleed mess is a very good example of why you are both right and wrong at the same time.
The problem is - most of the buffer overflows that we had to deal with were related to foundation infrastructure, which has long historic links. Nobody is going to replace those foundations without taking those historic links into account - and choosing Ada at the top level does not help much if foundations are not replaced. In the context of Heartbleed this means that your Ada-based web service (like with AWS) would be compromised anyway, because it would use the foundations that are broken, but which you would not be willing to reimplement yourself. And if you attempt to do it, you will take the risk of introducing new bugs, perhaps not buffer overflows, but maybe more subtle (and not less dangerous), like related to the cryptographic correctness of your new foundations. This is a huge economic question mark. It is not obvious (and has no existing data to back up) that replacing the software world with Ada would be automatically beneficial.

Which brings us to another question: what "switching to Ada" is supposed to mean, anyway? That we will take literally billions of lines of C code and put our several thousands of Ada on top of it and call it a success? This is pointless, the impact on overall quality would be exactly zero (think Heartbleed). Or maybe that we will replace the billions of LOC in C with new and untested billions of LOC in Ada? We both know it's not going to happen, and it would not even be necessarily good.

Things look different in those deployments where you can control the whole stack, like in embedded systems. There, "switching to Ada" is actually meaningful and I fully applaud it. Which is actually very relevant and viable with most safety critical systems.

> C and C++ pointers are another area where wild storage references are
> common and have the same damaging effects as buffer overflows. Things like
> that just don't happen in Ada and other safe languages.

They also don't happen with appropriate language subsetting, which is a valid and widely used strategy in safety critical systems. There is no need to abandon the whole language just because you want to get rid of one language feature.

> There's no excuse
> for using C or C++ in safety or even business-critical applications.

The excuse is economy of replacing billions of lines in foundation layers. And, let's be a bit objective, statistically it looks like both safety and business are doing fine. Fuckups get more media attention for obvious reasons (media have their economy, too), but from what I see more banks are thriving thanks to well working systems than falling due to buffer overflows. These are the excuses you are looking for and these are the reasons why future banking systems will be written in C++ and Java, too.

> Nonsense. Most people are not even qualified to choose the tools they use

And who is going to forbid them?

> > If I understand things correctly, lack of due diligence has to be proven
> >in court. 
> 
> That depends. In criminal cases in America they are supposed to have to
> prove guilt. But in civil cases and that's where the money is, accused
> parties have to prove their innocence.

OK, easy. There is a concept of widely accepted practice (also known as "nobody was ever fired for buying IBM"). If all universities teach that Java is the best technology and if all companies use it, then it must be an accepted practice. Then, just as "nobody was ever fired for buying IBM", nobody will be ever sued for writing business systems in Java.

On the contrary - choosing niche technologies might look like taking unnecessary risks and this is certainly a question mark in court. Ada is a niche technology and its technical properties might not be obvious to the judge.

> You continue to try to twist the discussion into the framework of avoiding
> liability and who to collect money from, where I am coming from the angle of
> wanting people to be aware of the issues and do the right thing, because
> it's the right thing to do.

Right. So for most people the right thing to do is not to take risks and do what everybody else does and write in C. Or in Java. Sorry. If all this seems twisted to you, it was not me who has twisted the world.

-- 
Maciej Sobczak * http://www.inspirel.com