[Info-vax] Programming languages on VMS

Stephen Hoffman seaohveh at hoffmanlabs.invalid
Fri Feb 9 11:40:46 EST 2018


On 2018-02-09 12:10:11 +0000, hb said:

> IDEs like Eclipse have a local history, besides a plugin for the 
> version control system of your choice. The local file versions are 
> identified by the time, when the source was saved, not by a number. You 
> can do= compares within the IDE, local history and/or any revision in 
> your version control system. Just a few mouse clicks. If you want, you 
> can merge the code from the compare window/view, difference by 
> difference with another mouse click. Fits me.

That's available in other current IDEs, too.  The one I'm dealing with 
integrated support for versions and integrated support for mercurial 
and git, on a platform that has integrated and transparent backups.   
For apps that don't use frameworks to manage versions of files, the 
system backups catch hourly updates and automatically cull those over 
longer intervals.  It's very effective, and I don't have cruft file 
versions building up in the file system, and that eventually and 
inevitably have to be manually configured or manually managed.  Those 
frameworks are the modern equivalent of incorporating versions into the 
file system, though the app can tune what's necessary.   Or the 
system-wide backups can capture the files for those that don't 
incorporate the version-related frameworks.  (Rolling files in from the 
system-wide backups is a couple of clicks, whether from today or months 
ago.  Which is also massively easier than what is involved dealing with 
OpenVMS and BACKUP.)

Integration of versions and online backups would be a sweet enhancement 
here, too; where an app can request BACKUP notify the apps to flush 
files and quiesce, and BACKUP can then capture consistent data across 
all of the app-related files.  This could be all files, or a subset of 
files that the app reports to BACKUP — such as an RMU/BACKUP or 
relational database backup that produces a database-specific backup 
file somewhere — that BACKUP could then capture and otherwise ignore 
the active files.  Not that I expect BACKUP to see substantial 
capability or performance improvements, as it already has issues 
inherent in its current design and UI complexity.

It's somewhere between hilarious and sad that vim and pico and zip and 
unzip and git and mercurial other common development tools haven't been 
better integrated into OpenVMS or directly incorporated into the base 
distro, and that effort is a whole lot less work than overhauling file 
versions and BACKUP integration and dragging the IDE support forward.   
 (Not intending vim and pico references as a slight against emacs 
users.  The emacs license likely precludes incorporating that in the 
base OpenVMS distro.)  Development on OpenVMS is a pain in the rump, as 
compared with other platforms.  And file versions don't help with that.


-- 
Pure Personal Opinion | HoffmanLabs LLC 




More information about the Info-vax mailing list