Re: Not to incite a language war but apparently the Corona lockdown was based on 13 year old undocumented C-Code

[Niklas Holsti <niklas.holsti@tidorum.invalid>]

On 2020-05-11 21:49, Rick Newbie wrote:
> This link is probably not reported in the MSM very much but I think it's 
> relevant. Not that I believe that Ada would have magically made 
> everything better,

Who knows... but certainly not "magically", rather by design and technology.

> but to base the decision to destroy the Western economies on code
> written in the C language that isn't even commented is somewhat out
> of dystopian fantasy.
The absence of comments does not make the code automatically incorrect.

I've seen people who are smart and good scientists, but amateur 
programmers, make quite complex and demanding programs which work, 
although the programs are ugly and clumsy by the standards of 
professional programming. These programs are often very scantily commented.

Professional programming gives great weight to code qualities that 
assist and support correctness and maintainability. But these qualities 
are not sine qua non for correctness. Amateur programmers do not 
understand that up-front investment in such qualities pays off in the 
longer run, but scientists can be very careful and meticulous in their 
coding -- they are used to taking such care in their other scientific work.

> There's a reason C is not used in safety critical applications.
Oh, it is used. Lots. What's more, some nuclear installations use Forth, 
I kid you not. With "sufficient" process controls and validations, it 
can work.

> I want to share this article here before it gets buried in the memory hole
> 
> 
> https://chrisvoncsefalvay.com/2020/05/09/imperial-covid-model/

I've seen a somewhat longer and better review of this code, but I didn't 
save the link (sorry). The following points were criticized IIRC:

- The original code was a single file, some 15 000 lines. This is not a 
problem in itself -- a good IDE can easily handle and navigate such a 
file -- but the possible poor modularization of the code, and the 
possible prevalence of global variables, could be. Nothing was said in 
the review about modularization or global variables. Note that even a 
single large source-code file can be well modularized.

- The code contains very few comments and lots of complex expressions 
with non-obvious meaning. As I said above, this does not mean it is 
incorrect, only that it is hard to review and maintain (which are real 
problems, sure).

- If the code is executed using multiple cores, the results are not 
deterministic, apparently because the code uses random numbers to drive 
a simulation with many parallel but interacting "actors", distributed 
over the cores, without global synchronization. The reviewer considered 
this to be a grave fault and indicative of poor programming and design. 
It seems to me that even professional programmers would be hard put to 
ensure deterministic results in multi-core execution of such a 
simulation. Moreover, the code is deterministic if executed on a single 
core (after some errors were corrected which seemed not to be unusually 
alarming).

- The authors of the code defended the non-determinism by saying that 
the simulation is statistical, anyway, and that all simulations should 
be repeated several times to get an ensemble of possible behaviour. The 
reviewer did not accept this defense, but insisted on determinism. 
However, I know of at least one example where non-determinism is 
accepted and used in this way: simulations of many-body gravitational 
systems, such as planetary systems, where it is very common to compute 
thousands or millions of simulations and then estimate the likelihood of 
particular final outcomes (say, the ejection of one planet from the 
system) from the ensemble of simulations.

Notably, the reviewer did not claim any errors resulting from the use of 
C instead of other languages. Of course, that may have been the ordinary 
myopia of seeing C as the "normal" choice :-)

-- 
Niklas Holsti
niklas holsti tidorum fi
       .      @       .