Re: The joy of FORTRAN-like languages

On 29/09/2024 07:57, geodandw wrote:

On 9/29/24 02:06, The Natural Philosopher wrote:

On 28/09/2024 22:41, geodandw wrote:

On 9/28/24 17:20, John Levine wrote:

According to The Natural Philosopher  <tnp@invalid.invalid>:

The need to speed up BASIC was why I learnt Assembler...

>
Dartmouth BASIC on the GE 635 compiled your program into machine code
and then ran it, so it was pretty snappy.  The compiler was so fast that
it wasn't worth keeping the objsct code around.  They didn't have a linker
until they added a PL/I compiler that was as slow as PL/I compilers are.
>
All this running 100 users on a machine the size of the KA-10 PDP-10.
>

Then I moved onto C, and that was the best of both worlds really

>
C was in the sweet spot of being not all that great, but better than any of the
plausible alternatives at the time.
>

If you like getting security exploits due to buffer overruns.

When C was developed there was no expectation that whole generation of crap programmers who had simple dome computer science, and therefore didn't know what a CPU actually was, would take over and need to be protected form their own laziness and incompetence.
If there exists a possibility of buffer overrun, check the size of what you are putting into it.
>

And of course careful programmers never make mistakes or overlook anything.

Only once.
And careful programmers test everything with unlikely data too.
I remember code I wrote being passed to a selection of 6th form 'holiday job' nerds to try and break it.
And they did.
But my main point is that code designed to 'protect' crap programmers introduces its own set of vulnerabilities at a different level.
Everyone in major engineering knows that no one ever get  it right all the time and that is why instead of trying, they implement quality procedures.
Test it as far as possible.
If  it's wrong:
- fix it
- document the fix
- document why it went wrong
- document ways to avoid getting it wrong in future.
- implement standards to stop it happening again.
Go back and test it all again,.
That's the heart of ISO 9000
In software terms that means don't try to fix the language*, fix the procedures under which the language is used, and tested...
I love those air accident reports that say instead of 'the pilot was crap '  that
'the procedures and standards for pilot selection, training and certification  failed and need to be modified'.
In other words the system was at fault for  failing to adequately train, hire  or even certify such a crap pilot in the first place.
The system acknowledges that there are people who want to be pilots, who aren't fit to be.
If only we could do the same with coders...
*unless there are important undefined behaviours in it
--
It’s easier to fool people than to convince them that they have been fooled.
Mark Twain