Re: OpenSSL development (Heartbleed)

[Georg Bauhaus <rm-host.bauhaus@maps.futureapps.de>]

On 19/04/14 22:53, Alan Browne wrote:
> Now, do you really think the industry will change to something more formalized and requirements driven?  Use Ada as a fundamental building block of it?

Where C (or no S/E) is being used, directly, or indirectly by using
libraries written in C, the industry seems stuck in a loop of at least

(1) self-referential confirmation,
(2) insufficient irritation caused by C (or lack of S/E), and
(3) sufficient competitive equality.

One faint hope that I currently maintain is that some BigCo, not the
industry, might produce a change to using C. The change might be like
the ones just now performed in the case of hugely popular languages:
PHP might become Hack everywhere because Facebook has produced Hack by
"enhancing" PHP; Microsoft has already produced C#, VB#, etc., by
"enhancing" each of the respective assimilated languages; Apple's
"enhanced" C in Objective-C is already far above what the C standard
requires of an implementation if seen through the lenses of their
static analyzer. Google makes their talented staff spend some "free"
time on "enhancing" the special qualities of JavaScript.

And the results are all free, working, and ubiquitous.

Suppose something similar happens in the C world.

Apparently, all it takes is hiring a few smart compiler writers
and have them "enhance" the popular language C in such a way
that C programmers can simply enjoy the new features whenever they wish.
(Intel?, Freescale?)


To elaborate, for the sake of completeness only, the claims of
(1), (2), and (3),

(1) As long as the company does not go bankrupt, and the project's
goal was not entirely missed, choosing C is justified. So, project
management can confirm that it was the right choice, obviously.
So does everyone.

(2) It is well known that: "Software has bugs." "Tom De Marco says
that the effect of language is <= 5%, so why bother." Studies
comparing the effects of languages or methods are rare. They seem to
be interpreted by shooting from the hip or in other surprising
ways[*]. If effects of bugs can be handled by customer care, then C's
features may be seen as causing costly bugs, however the pressure
isn't high enough.  Internally, excuses are at hand. (Not the least
of which is "A..... 5!")

(3) By simple arithmetic, if all the competition is using C (or no S/E),
everyone incurs the same cost, yet there is return on investment.
Consequently, then, using C (or no S/E) does not cause any
relative economic disadvantage. Whereas investing in different
technology is associated with risk, education, and other cost factors.
Who is going to start an initiative, then, and why?

__
[*] One anecdote I heard was about two teams, one using C++, the
other using SPARK, programming to the same specification for one
year. Either team could use a simulator. The teams were tasked with
producing programs for driving a test device. The C++ team
debugged their software into existence, frequently testing in the
simulator. The SPARK team first found a bug in the specification,
then went on to prove software into existence, hardly if ever using
the simulator. Finally, the C++ team had implemented 80% of the features.
Some bugs were found in the final product. The SPARK team had
implemented 100% of the features (close to closing time). No bugs
were found in the final product.
   Interpretation of the result: Use of the approach of C++ is
preferable since project management then does not suffer a heart
attack because they have no facts to report while the project
is underway.