[Info-vax] Programming languages on VMS

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Fri Feb 9 11:17:56 EST 2018


On 2018-02-09 14:42:03 +0000, DaveFroble said:

> Bob Koehler wrote:
>> In article <p5k3ou$t41$1 at Iltempo.Update.UU.SE>, Johnny Billquist 
>> <bqt at softjar.se> writes:
>>> Isn't it good to be on a system where this need was covered already at 
>>> the OS, and not becomes a specific functionality located just inside 
>>> each tool?

Sure.  If it were done well.  Which it is not.  Versions are utter 
dreck to deal with.  They were a great idea in the 1980s.  Now?  Not so 
much.  For all the reasons previously cited.

>> The functionality f a good CM tool and the functionality of versions 
>> are different.  The implementaions are different.  What jobs they are 
>> good for are different.
>> 
>> I want both.
>> 
> 
> Yeah, what he wrote ..

Source code control should be integrated into OpenVMS development 
tools, and the development tools hauled forward a decade or three.   
Some competitors have this source code control integration and this 
automatic rollbacks support already, and better backup integration, and 
they provide their tools for somewhere between small change and free.   
  As should a replacement for versions that allows apps to roll back 
and roll forward among groups of related files, and integrates with 
system backups, because we're not in a world were developers are 
working with just one file.  Not in many years.   Not with the current 
OpenVMS compilers and tools and programming languages.  But that's a 
different discussion.

Or just ponder why features like logical names and file versions 
haven't become endemic across systems.   Yes, versions were a great 
idea.  Integration of versions into the file system is... nice... but 
is that really the right place for this, or was that integration really 
more of a compromise around what apps didn't and don't do, and around 
what frameworks are available for the apps to incorporate for managing 
changes?  Now roll forward and think of where OpenVMS needs to be.   
Versions aren't easy to deal with, backups aren't easy to deal with, 
source code control and change management isn't easy to deal with, 
online backups don't work reliably, rolling back after a security 
breach is... interesting.   Now ponder where OpenVMS needs to be.   If 
it's more of the same, if it's file versions and the absurd hackery of 
logical names as control knobs, we're not going to get better apps and 
newer apps and newer ISVs, and the existing apps are going to 
increasingly be at a competitive disadvantage.

File versions aren't a selling point to any folks used to integrated 
frameworks for managing change, and for managing backups and 
recoveries.   Which is pretty clearly not very many folks around here, 
but maybe ask some of those youngsters — you know, the folks that keep 
getting slagged by a few folks around here — what tools and frameworks 
they're using and fond of and want to see.   Of what user interfaces 
and what operating system features they've encountered.

Or sure, go compare what is an increasingly problematic design against 
other bad designs and find some other yet-worse designs, and declare 
victory.    Alas, that's not how you build a product that folks really 
want to learn and use.



-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list