Let's all commit ourselves to boldly go where no MV software has gone before.
The future is here! So how do we future-proof?
To get all this started, here are a few modest suggestions.
Case in point, why are we still using the CRT statement in MV Basic, but failing to support LCD statements and LED statements? We need to catch up with current technology.
Case in point, we need to get out in front of the Y10K bug, by defaulting all output date conversions to displaying 5 digit years . . . or maybe 6 digits would be better, to deal with the Y100K bug.
Case in point, we need to give software engineers and managers the ability to regulate the use of spaghetti code. Give them a tunable SPAGHETTI_LEVEL parameter:
SPAGHETTI_LEVEL 0 *** GO and GOTO and RETURN TO statements are disallowed
SPAGHETTI_LEVEL 1 *** GO and GOTO are allowed, but RETURN TO is disallowed
SPAGHETTI_LEVEL 2 *** GO and GOTO are disallowed, but RETURN TO is allowed
SPAGHETTI_LEVEL 3 *** (sadly this is the default level) GO, GOTO, RETURN TO all allowed
SPAGHETTI_LEVEL 10 *** (maximum spaghetti) like level 3, but all statement labels must be numeric
SPAGHETTI_LEVEL 11 *** (beyond maximum) GOTO and RETURN TO statements are replaced by COME FROM statements, which work the same way but backwards
Well, okay, some of these spaghetti levels arguably go against the spirit of future-proofing our software but maybe we can future-proof our jobs by confusing those up-and-coming young engineers and AI bots.