Horizon

[MikeSh]

This sort of thing certainly seemed possible but I'd hoped it wasn't so:
Post Office plan to sack Horizon IT reviewer kept secret, documents reveal
Another Victor Meldrew moment
I hope the police have the resources to put those involved where the sun doesn't shine much.

 

[EEPhil]

I hope the police have the resources to put those involved where the sun doesn't shine much.

Normally, the expression "putting something where the sun doesn't shine" means up the bum! I assume you're using it to mean chokey. If so, it's a meaning of that expression that I've not heard before.
I agree with the sentiment. The more I hear about the PO/Fujitsu/Government behaviour and cover-up the less faith I have in "the system".

 

[EEPhil]

The Horizon scandal has made it to "comp.os.vms" aka "info-vax". It was pointed out there that some of the code was ropey and written in BASIC. See https://www.postofficehorizoninquiry.org.uk/evidence/fuj00080690-report-eposs-pinicl-task-force page 17 of the attachment, section 7.3.

The code is VB6.

But none of the problems are Basic specific. It is possible
to write the same bad code in C or Fortran or whatever.

So it just shows that there are some really really bad programmers out
there.

 

[MikeSh]

So it just shows that there are some really really bad programmers out
there.
There are people who are really bad at their job in every profession. It's up to management to put the processes in place to find the mistakes made before they do harm (like Boeing didn't). For software that means adequate testing but that's heavy on manpower, time and cost, so it's almost always pared back to minimum.

 

[MikeSh]

written in BASIC

As the quote says there's nothing wrong with that per se. The different languages are generally optimised for particular platforms (hardware) and function (eg. crunching climate models, doing accounts, real time controls, etc).
The biggest (or at least a very significant) catch with basic is that it's interpretive so has to be read and converted every time it's used. That needs extra work by the processor. Most professional code is compiled (into the machine's language) before being loaded into the system to minimise system resources use and run faster. So a little bit of basic here and there probably isn't going to be a problem and might be a nut-cracker to solve a particular issue without spending a lot of effort getting a sledge hammer on the job.
If it does the job as needed it's fine.

 

[EEPhil]

Nothing against BASIC. I once wrote multiuser database system in MBasic (similar to, if not the same as, GWBasic shipped with early versions of Windows). Of course, that wasn't tested to destruction before it went live. As luck would have it, it went wrong 4am one morning. Once that bug was fixed it did the job.

The biggest (or at least a very significant) catch with basic is that it's interpretive so has to be read and converted every time it's used.

Back in 1982, the database I referred to was written and debugged in the interpreter but compiled for actual use. So, no catch there then!

 

[Black Hole]

The drawback I can think of (and I'm not a programmer) is that the code might be OK but the compiler/interpreter not so OK. It's not generally the code which causes (eg) memory leaks, it's how well/badly the compiler puts in the background infrastructure to cause the memory leak. Sometimes coding becomes about work-arounds to avoid compiler inadequacies.

Then, if there is a mixture of languages, how well do they interoperate? If they have to communicate, how compatible is (eg) the string passing (delimiters, terminators, special characters, escape sequences)?

It's a minefield.

adequate testing but that's heavy on manpower, time and cost

Yes, testing is invariably should be the biggest slice of the budget, but it takes very enlightened management to see that and not cut corners. Neither should testing be in the hands of the programmers, you need a specialist team with a specific remit to find problems, rather than let the programmers test it themselves (who are not motivated to find anything wrong).

That's what a QA department did in my day, and they were not very popular with the engineers (but should have been).

 

[EEPhil]

Then, if there is a mixture of languages, how well do they interoperate? If they have to communicate, how compatible is (eg) the string passing (delimiters, terminators, special characters, escape sequences)?

This is what I liked about DEC's VAX/VMS. As far as I remember (not far these days) mixed language was (is) relatively straightforward. However, not something I did. FORTRAN or Pascal or C for the number-crunching earth-shattering research, but never a mix. Although a call to a system library function might have been included when the equivalent FORTRAN language function gave the wrong answer (arctan iirc).

Neither should testing be in the hands of the programmers,

That was the problem with the 1982 database. I was subcontracted to a one man outfit that had a contract to produce the software. Said man was too busy, which was why I was there. Who tests? Muggins, of course.

 

[antipodean]

The biggest (or at least a very significant) catch with basic is that it's interpretive so has to be read and converted every time it's used.

Not the VB code mentioned above. IIRC it gets compiled to tokens or links to .NET DLLs. But where were they using VB? was it code for the terminals? That is about the only bit I could envisage running Windows.

Then, if there is a mixture of languages, how well do they interoperate? If they have to communicate, how compatible is (eg) the string passing (delimiters, terminators, special characters, escape sequences)?

This will depend on the language suites used. If using the Microsoft Visual Languages they all call the same .NET DLL modules to achieve a lot of the operations. The Borland suites (Pascal and C) did a similar thing by using the same runtime code modules behind the scenes, and later on conformed to the MS way and used .NET as well.

But on a mainframe things will be different. I don't know what the current programming languages are likely to be, but quite possibly Cobol still.