[SystemSafety] A small taste of what we're up against

[Coq, Thierry]

I'd say "support programming languges with unambiguous and easy-to-read semantics"

The C language has neither, and whenever I asked for a rationale for using the language or a subset, it came down to "habit", "free or available compiler/tools", "availability of trained personnel" or "consistency of the source base".  The cost of using it was never invoked, particularly the cost of the 3- or 5- year warranty. The fact that many other languages with much better properties than C/C++ have most of the above but are not even considered. The "consistency of the source base" is in fact a very difficult argument to crack.

I request the "easy-to-read" semantics for four reasons:
- it increases the productivity and reduces the introduction of defects in the sources. I read somewhere that 90% of the developer's time was spent reading source, and only 10% writing sources, but I cannot find the reference,
- it adds a lot of value and there is a big reduction in defects when the customer is able to read the sources, and make comments,
- peer reviews and inspections within the team also provide a great value in reducing defects that cannot be found otherwise, and easy-to-read languages have a great advantage in that area.
- the systems we build are long lived and the original developers have gone long ago, when maintenance/upgrades have to be performed. Again, easy-to-read languages provide a great advantage.

I would define "easy-to-read" as "as close to unambiguous English as possible".

Thierry

-----Original Message-----
From: systemsafety <systemsafety-bounces at lists.techfak.uni-bielefeld.de> On Behalf Of Martyn Thomas
Sent: Wednesday, October 24, 2018 11:26 AM
To: systemsafety at lists.techfak.uni-bielefeld.de
Subject: Re: [SystemSafety] A small taste of what we're up against

"Support destructive testing of software ! " ??   I'd say "Support programming languages with unambiguous semantics. "

I'd like to see an ALARP argument for software written in C. Does anyone have one to share?

Martyn


On 24/10/2018 08:13, Olwen Morgan wrote:
>
> Just a quickie:
>
> if, in the code below, you replace:
>
>
>     PrintEvalOrder((a[0]=++i), (a[1]=++i), (a[2]=++i));
>
> with:
>
>
>     PrintEvalOrder((++i), (++i), (++i));
>
> both clang and tcc tell you the order of evaluation is p1, p2, p3
> whereas gcc says it's p3, p3, p3. ... WTF?
>
> Presumably, this is due to over-zealous optimisation,
>
>
> Support destructive testing of software !



**************************************************************************************
This e-mail and any attachments thereto may contain confidential information and/or information protected by intellectual property rights for the exclusive attention of the intended addressees named above. If you have received this transmission in error, please immediately notify the sender by return e-mail and delete this message and its attachments. Unauthorized use, copying or further full or partial distribution of this e-mail or its contents is prohibited.
**************************************************************************************