[Info-vax] Programming languages on VMS

[DaveFroble]

Stephen Hoffman wrote:
> On 2018-02-01 17:29:24 +0000, DaveFroble said:
> 
>> Stephen Hoffman wrote:
>>> TL;DR: RMS file versions are a pain to use, require the user or the 
>>> system manager explicitly manage them, and don't particularly solve 
>>> the problems that we even say that RMS version files solve.   Not 
>>> well.  If at all.
>>
>> Maybe I'm just too old school, but, I understand versions, and I 
>> understand what they can do for me.  And so, I use them.
> 
> There's no reason not to use them.  They are, however, a complete pain 
> in the rump, and don't really solve the problems we use them for.   
> Combining versions and backups, and direct integration with source code 
> control tools for developers really makes this clear, too.

It really depends on how such is used.  Most definitely not for backup and such.

I've seen systems where an inadvertent PURGE would be a disaster.  Blamy that on 
people, not versions.

Anything I might want to save will NEVER be a prior version.

>> As for some tool or utility, that I don't understand, saying "trust 
>> your edits and such to me, don't worry about them", well, I don't 
>> trust, and I do worry.
> 
> You have learned to trust other tools, not the least of which are BACKUP 
> and RMS.

BACKUP and RMS do have a track record.  However, except for text files, I rarely 
use RMS.  I use a 3rd party database product, for which I do have the sources, 
and incidentally is written mostly in Macro-32.

>> Logging.  I can have unique log files, easily selected by date and 
>> name and such.  Easy to access, easy to read.  I don't have to depend 
>> on some utility or tool to find and view logs.
> 
> Harder to automate, though.  Requires local clean-up, too.

Extremely easy to automate.  With PURGE/KEEP or DELETE/BEFORE automated 
procedures can easily keep the logs directories rather clean.

>> The "old ways", they just work, and I understand them.  Do I really 
>> need more, or is it actually less?
> 
> So you'll be back-porting your code to Macro32 assembler?

No, don't think so.

>  Since that's 
> The Old Way, and not these fancy 3GL compiler thingies.  Assembler code 
> is far more efficient and better.  BETTER!  Or so I was told, by the 
> folks that preferred assembler to 3GLs.  Or that were on a tear about 
> memory usage in new apps, when the available memory hardware and 
> addressing was increasing.  Etc.

Could go back to jumpers on boards.  No, not that either.

But I will say, if my options were Macro-32 or PHP, it might be a tough choice.

>> Building an application.  I've developed the methods for easily 
>> building applications.  I understand the methods.  Others use them, 
>> and seem to be happy with them.  Why do I need to change what works?
> 
> You don't.   But ponder what you go through when you start up a wholly 
> new application.  Not that Cmake and the other tools and autoconf are a 
> salient example nor even remotely a panacea.  They aren't.

No, I'd use exactly the same methods that have worked for the last 30 years.  I 
would include improvements, if that was reasonable.  I happen to think that I 
have some great methods and procedures, and every other programmer who has been 
introduced to them seems to concur.

> Yeah, none of us like to learn new tools.  But that's the business we're 
> in.

ALEXA does seem to provide some new things ....

-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486