Paranoid bullshit. Maybe see a shrink before you go on a killing-spree?

Are these people all terminally stupid and really did not know that Dropbox scans all files and delivers everything interesting to the feds?

No. The missing one is that a top-notch coder will not be cheap.

There are always a few crackpots around that do not get it. Mathematics does not apply to reality. It cannot even be done in physical reality. The only place it can be done in is human imagination.

You just failed "Scientific Theory 101".

Your point 4 is really complete bullshit and you either have no clue what you are talking about or are lying directly. In any case you are full of shit. Simple proof: Just obfuscate the Ada code and not the C code. And you want to include a _runtime_ environment with a library? Do you even know what a library is and what a catastrophe that would be? Apparently not. The rest of your "insights" is of equally low quality.

Or rather not applicable. Physics is not accessible to mathematics, Mathematics is just a tool physics uses on formalized abstractions of physics. These abstractions _always_ introduce inaccuracies, and hence no mathematical proof can ever apply to physics directly or absolutely. Mathematics can just not bridge these transformation steps. That is the tasks of Physics.

OpenSSL would be meaningless and not in use if it had been written in ADA. Also, ADA is not at all the "magic bullet" some people make it out to be. In fact, it suffers from unreadable code even more than clean C code. Also remember that this is a library. Unless ADA allows creating libraries with "C" bindings in ADA, it is not even usable for the task. And if you invest the same time on the C side, you get a similar level of quality. Hell, this bug would have been found with some halfway competent fuzzing or completely avoided with mandatory time-of-use checking of all bounds. Which secure coding guidelines can make mandatory, unless you explicitly explain in each instance where you omit it why this is ok.

Sure, languages play an important role, but it always falls back to Assembler-level (or C if you want to be somewhat portable) and there competent people can do all things that imperative languages can do. The problem with most languages is that they restrict too much what you can do and/or foster bloat and/or have intransparent behavior.

I have done Eiffel, Sather, Python, Lua, Pascal, Modula, Haskell, Gofer, Prolog, Lisp, C++, several assembler variants, Basic, Java, JavaScript, Pizza, and some more things. I am back to doing all "library" level things in C and the glue in Python or Lua (or C where that is not an option). Basically all OO languages suck badly, except Eiffel, which unfortunately it too exotic to be useful. Functional languages are nice and compact for some things, but suffer from interfacing problems. (Will have a look at Erlang though, that may be better.) Logical languages have some value in some specific situations, but do not even approach "general purpose". C++ and Java are bloated, intransparent, non-orthogonal atrocities made by people that do not understand OO. These languages typically make things worse unless you have really experienced and capable people. The typical mediocre-to-bad coders just throw the features of these languages around indiscriminately, resulting in an awful mess. IDEs make that worse as suddenly it becomes easy to write more code and distribute it into even more files.

Yes, you need discipline, experience and insight to do things well in C. The current OpenSSL disaster shows all three are missing in the OpenSSL team. Yes, many C programmers suffer from a terminal desire to place efficiency above everything else. But that problem is with the programmer, not the language. And you get just the same stupid mistakes in other languages and they add their own problems.

That is not to say C is a good language. It is (besides assembler) just the only language where code quality rests completely with the coder and that does not stand in the way of the coder. It is the only "native" language if you do not want to do assembler and that gives it a special place and all that cannot work competently with it a clear limitation. At the same time, all approaches to force people to write "good code" by language features and restrictions that force them to do so have failed. There is even bloated, unreadable, unreliable code in Python or Eiffel, and you have to really work at that in these languages.

After being in this for 30 years and having seen and reviewed countless pieces of code by others, I am convinced that language selection is mostly irrelevant. The only thing language can give you is problems in the form of restrictions. If the coder is not top-notch, the code will suck and be insecure, slow, unreliable and unmaintainable, regardless of the language used. If the coder is top-notch, the code will be secure, fast, reliable and easy to maintain, mostly regardless of language used (within the restrictions the language comes with). However a top-notch coder will know or be able to figure out fast what a specific language can do and what its restrictions are and know early whether it is suitable for a specific project or not.

Of course, that said, you are right that people that want to do everything in one specific language (often Java these days, and unfortunately often C historically) are typically 1-trick ponies that do not even know what it means to code, and typically can manage barely in that one language. They will of course always argue that their one language is best because they do not really know any other and deep down know they are grossly incompetent.

Indeed. And even worse: How do you explain a buffer-overflow or Heartbleed to a Java programmer? They do not even understand what you are talking about!

C++ allows you do make an even less transparent mess. That language is a violation of almost any principle of language design in itself. Defensively coded C would be perfectly fine. As in using all the things on how to do secure software engineering that have been known for decades.

Indeed. While both this person and the reviewer messed up badly and their competence is rightfully in question, they were also set-up by omission of basically everything you need to do to produce secure code in OpenSSL and by sabotage (likely due to terminal stupidity) of safeguards that _were_ available.

To produce a catastrophe, several people have to screw up spectacularly. This is what happened here. Quite often, when you dig down, you find a combination of big egos and small skills.

Indeed. This was not just one screw-up, it is the end-result of quite a chain of them. You can optimize for speed, but it is an expert's game. Far to many coders believe they are experts when they do not even come close.

This is BS. You can screw up just as badly in any other language. It will just be less obvious. Of course, the combination of an incompetent code writer and an incompetent reviewer will quite often have spectacularly bad results.

This is not the US. There will be no lawsuits. "No warranty" actually has meaning here.