[Info-vax] Rust as a HS language, was: Re: Quiet?

[chris]

On 04/07/22 03:43, plugh wrote:
> On Wednesday, April 6, 2022 at 5:01:02 PM UTC-7, chris wrote:

<snipped>

>>
>> This sounds like medication to cure everyone from their sloppy
>> programming. The infantilisation of complex subjects, just to give the
>> lazy an easier time, while still getting the product built.
>> The answer to that is not languages that constrain movement, but
>> developing more professional skills and applying due diligence
>> and attention to detail to system design and implementation.
>>
>> I must be getting old, so what happened to pursuit of excellence
>> and more ?...
>>
>> Chris
>
> It's a question of provability. No current C project can implement the kind of toolchain that duplicates the compiler's static analysis proofs. And we haven't gotten to its runtime proofs. When combined with its runtime guarantees, it is a significant step forward.
> The compiler is only one part of Rust's toolchain, but that's another story.
>
> Here's a car analogy: do you want to change a tire using a power tool or good ol' muscles?
>
> If by chance we see this language on VMS within our lifetimes, we should be prepared. We'd be unstoppable.

Many years ago, worked on an avionics project where all the code
was written in micro assembler. That and other products
typically had a set of documents describing every aspect and stage
of the project. The was no concept ef mathematical provability,
and this was a safety critical system. Each module was individually
tested, where every line of the code was exercised to verify what
was in most cases, the obvious, but done anyway. At a higher level,
the whole system was subjected to rigorous testing with valid and
invalid data, stress testing,  to confirm that it was doing as
expected.

What i's saying is that code integrity can be improved by various
means, but the main factor is always the process involved. Full
documentation at every stage of development, audit trail, peer
group code reviews, and a thorough test program to verify operation
to spec and reliability under extreme conditions. Problem is
that such a process is very expensive to do right and most companies
are not prepared to invest in that, especially with short
product lifetimes and pressure to get the product to market.

So the typical process these days is rapid development, which skimps
on process and testing and debugs the product at the customer. I
don't think any language can cure that, as it's the process and
attention to detail that are missing and no fault of the language
involved. To suggest that sort of thing can be fixed by the
current language fashion of the month is fantasy and ignores
the main problem...

Chris