NEVER TRUST THE “EXPERTS”

[txradioguy]

Everyone now knows that Neil Ferguson of England’s Imperial College is one of the villains of the coronavirus disaster of 2020. He produced an epidemiological model that was absurdly off the mark, predicting 500,000 deaths from the virus in the U.K., and more than 2 million in the U.S. Unfortunately, Ferguson’s model was the basis for harsh shutdowns in the U.K. and other countries, probably including the U.S. Most people also know that Ferguson is a world-class hypocrite, as he violated his own social distancing rules to engage in illicit trysts with his married lover, a left-wing political activist.

But that’s not the worst of it. In the Telegraph, two software executives write that Ferguson’s model was, on its face, incompetent and would not have been accepted by anyone well-versed in computer technology. (“Neil Ferguson’s Imperial model could be the most devastating software mistake of all time.”) The article is beyond a paywall, so I will excerpt liberally:

Imperial’s model appears to be based on a programming language called Fortran, which was old news 20 years ago and, guess what, was the code used for Mariner 1. This outdated language contains inherent problems with its grammar and the way it assigns values, which can give way to multiple design flaws and numerical inaccuracies. One file alone in the Imperial model contained 15,000 lines of code.

<snip>

The approach ignores widely accepted computer science principles known as “separation of concerns”, which date back to the early 70s and are essential to the design and architecture of successful software systems. The principles guard against what developers call CACE: Changing Anything Changes Everything.

Without this separation, it is impossible to carry out rigorous testing of individual parts to ensure full working order of the whole. Testing allows for guarantees. It is what you do on a conveyer belt in a car factory. Each and every component is tested for integrity in order to pass strict quality controls.

<snip>

Imperial’s model is vulnerable to producing wildly different and conflicting outputs based on the same initial set of parameters. Run it on different computers and you would likely get different results. In other words, it is non-deterministic.

As such, it is fundamentally unreliable. It screams the question as to why our Government did not get a second opinion before swallowing Imperial’s prescription.

Whatever you think of the Wuhan virus, it is certainly no more severe, and probably less severe, than the epidemics of 1957-58, which killed around 1.1 million in a much less populated world, and 1968-69, which killed 1 million worldwide and around 100,000 in the U.S. (the equivalent of 160,000 today). Those epidemics were bad. They killed people, mostly the elderly and the infirm. But the damage was not compounded by irrational government actions that devastated far more lives than were impacted by the diseases. It adds insult to injury that those government actions have been based, in large part, on incompetent work by “experts.”

https://www.powerlineblog.com/archives/2020/05/never-trust-the-experts.php

[Slide Rule]

60 Year Old Programming Language


In pre-Excel days, I wrote software for my department budget in Fortran.

A bit less than a 1,000 lines with heavy use of subroutines. Subroutines could be
confirmed to the degree that I was interested in.

Also incorporated were partial differential equations on the main cost features to
determine dollar fluctuations related to changes in every parameter.

Still, Fortran was a useful language for the time. But time had passed by the time I
wrote the code. It was a useful product and led to our company writing a budget
program for our companies managers. Saving about 10% of their available time.
It had taken me about 200 hours minimum each previous year to do budgeting and
that was all quite medial.


Years before this, I needed to develop code for my master's thesis. My thesis was
dependent on code I wrote in machine language, on the state of the art, at that old
date, on a DEC PDP. About 5,000 lines.

I can tell you that errors are a large issue. I did have tape transports that helped then
like mass memory units do today.


The larger the program, the more testing is required, and the more breaking down
aspects of the program into more manageable and testable units.


Today, 15,000 lines of code in Fortran would be an overwhelming problem and result
in outcomes of dubious value. They would require massive testing and long intervals
to perform them.

You would have to find some old dudes versed in Fortran as it hasn't been part of
any well-meaning college curriculum. Well maybe someone in the history department
would be interested or maybe an old-timer like myself.


The obstacles presented by obsolete language are formidable. Not so formidable
that they could not be overcome by very bright and capable people. Still.  Why limit
your product with the limitations of a 60-year-old programming language.

[Bigun]

60 Year Old Programming Language


In pre-Excel days, I wrote software for my department budget in Fortran.

A bit less than a 1,000 lines with heavy use of subroutines. Subroutines could be
confirmed to the degree that I was interested in.

Also incorporated were partial differential equations on the main cost features to
determine dollar fluctuations related to changes in every parameter.

Still, Fortran was a useful language for the time. But time had passed by the time I
wrote the code. It was a useful product and led to our company writing a budget
program for our companies managers. Saving about 10% of their available time.
It had taken me about 200 hours minimum each previous year to do budgeting and
that was all quite medial.


Years before this, I needed to develop code for my master's thesis. My thesis was
dependent on code I wrote in machine language, on the state of the art, at that old
date, on a DEC PDP. About 5,000 lines.

I can tell you that errors are a large issue. I did have tape transports that helped then
like mass memory units do today.


The larger the program, the more testing is required, and the more breaking down
aspects of the program into more manageable and testable units.


Today, 15,000 lines of code in Fortran would be an overwhelming problem and result
in outcomes of dubious value. They would require massive testing and long intervals
to perform them.

You would have to find some old dudes versed in Fortran as it hasn't been part of
any well-meaning college curriculum. Well maybe someone in the history department
would be interested or maybe an old-timer like myself.


The obstacles presented by obsolete language are formidable. Not so formidable
that they could not be overcome by very bright and capable people. Still.  Why limit
your product with the limitations of a 60-year-old programming language.

Unless you want to make absolutely sure the model produces the exact result you are after.

[Slide Rule]

Unless you want to make absolutely sure the model produces the exact result you are after.

Well. There is that.