[Info-vax] Programming languages on VMS

[DaveFroble]

Stephen Hoffman wrote:
> On 2018-02-01 01:02:11 +0000, seasoned_geek said:
> 
>> On Wednesday, January 31, 2018 at 2:26:38 PM UTC-6, Stephen Hoffman 
>> wrote:
>>> As for file versions, vanishingly few folks uses those outside of> 
>>> OpenVMS, and file versions don't work all that well on OpenVMS, and> 
>>> source control using file versions as implemented on OpenVMS are a> 
>>> trouble flag.
>>
>> While I agree about source control, file versions are growing in use, 
>> not shrinking. Sadly, they are half-assedly done in Linux and 
>> Weeendoze. When you download the same file twice or copy it twice, 
>> depending on the tool, you aren't prompted to rename, instead you see:
> 
> Who cares about bad implementations, except to learn from?   if you want 
> to use a bad implementation, you have your choice of bad candidates 
> here, too.  You can use a bad implementation from Windows, or a bad 
> implementation from Linux, or a bad implementation from OpenVMS.
> 
> Somebody please explain the use case for versions on OpenVMS?
> 
>  From what I can tell of it, it's because there's no log management 
> system for log files and crashes and such, and because the text editors 
> from antiquity were constrained and various of those text editors 
> haven't had anybody even take a serious look at them in most of thirty 
> years.   It was just easier back to centralize versioning in one spot — 
> RMS — and leave dealing with the fallout to the end-user.  But is that 
> what we really want or need?   Seriously, what problems do the RMS 
> versions solve?  Reverting to past revisions when editing files is 
> probably the most common solution cited, yet — outside of trivial cases 
> — you end up with disconnected selections of uncoordinated and 
> poorly-allocated files scattered around, and — if you need to fall back 
> to a previous edit — you need to clean up the mess and figure out which 
> versions of which files are the associated versions yourself.   
> Manually.   How quaint.   Aren't we using computers here, and aren't 
> these computer thingies good at this sort of checkpointing and 
> coordination?   I mean, even various of the old editors have the ability 
> to journal activity.   The just don't journal across exits.  So is it 
> better to journal across exits?   Because what we have means we have to 
> clean up the mess ourselves, even if we never end up rolling back 
> because more than a few editors and more than a few other tools just 
> leave these versions scattered around.   Like the turd files that they 
> so often are.
> 
> This also all without even something as simple as a delta applied to 
> compress the amount of data stored across what are often 
> not-all-that-different versions, but that's fodder for another 
> discussion.  The end-user gets to deal with it, and few tools even 
> bother with a roll-over when the architectural version limit is reached, 
> too.  There's some "fun" here in the RMS parser, but that's fodder for 
> another day.  There's also that more than a few of us deliberately use 
> ;32767 to block creations of new versions of unnecessary files — changes 
> coming from VSI will break that, IIRC — and there's that the whole of 
> the operator and logging and crash-handling support on OpenVMS is 
> positively archaic.
> 
> We use logs and log versions and editor versions because that's what we 
> have.  Not because it's even remotely good.
> 
> So who would design and use OpenVMS-style versions as they are now, and 
> why?   And if you did have your choice here, would you implement 
> versions as was done on OpenVMS, or would you look to have and to use a 
> framework or library to allow the user to roll back coordinated versions 
> within the particular tooling?   Or for other apps that create multiple 
> versions, would you even bother scattering dump files or log files all 
> over the place, or would you prefer to use a competently designed 
> framework that actually solves your problem and doesn't leave you with a 
> completely half-baked screwed up hack job as is the case with OpenVMS?  
> The ability to roll back to a previous version is a great idea.   That 
> there's just one implementation of versions on OpenVMS is wonderful.   
> But tell me what problem does the current implementation solve, and what 
> problems does it introduce?   More importantly, would the existing 
> design be your choice, or — like most of us — do you spend more time 
> dealing with the results?
> 
> Seriously.  Versions as implemented are far inferior to editors or 
> (increasingly common) IDEs that can use — for instance — system 
> frameworks and/or revision-control systems to roll back to previous 
> change sets.  But RMS versions are what we have.  And they're kind of 
> bad at what they're supposed to solve.  Use app-specific revisions based 
> on a common framework — as is implemented on some other platforms — and 
> deal with logging and crashes with a console app and centralized and 
> distributed-capable logging frameworks.
> 
> RMS file versions were great idea and a wonderful implementation in the 
> 1970s and 1980s, but tools and expectations have moved on.   Many of the 
> new developers are smart folks, and they have better tools and 
> frameworks than those available on OpenVMS, too.   Yeah, some of you are 
> fond of text editor that can't track multiple file versions in parallel, 
> but that's a solved problem in many (other) text editors, and some of 
> the available IDEs make this whole application-development and UI 
> development sequence vastly easier, including integrating the editor, 
> the compiler, the "fun" that is the usual build file, the linker, the 
> debugger, the source code control access, and other tools.  It's several 
> decades past time to drag versioning support and the text editors and 
> logging and app orchestration, installation, upgrades, patches, dumps, 
> and related topics forward.  Because what we have now is poor, if we 
> really take a look at RMS file versions and at what problems that solves 
> and what problems that creates and at what alternative approaches are 
> available that might better address those requirements.  But it's what 
> we have.
> 
> Roll OPCOM and auditing and accounting and the rest forward a generation 
> or three, create frameworks that allows tools to manage file versions 
> better whether for logging or for development, get an IDE and updated 
> editors available for developers, and roll the whole of the OpenVMS 
> environment forward a couple of decades.
> 
> 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.

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.

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.

The "old ways", they just work, and I understand them.  Do I really need more, 
or is it actually less?

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?

-- 
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