[Info-vax] Programming languages on VMS

[Stephen Hoffman]

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.






-- 
Pure Personal Opinion | HoffmanLabs LLC