[Info-vax] Programming languages on VMS

DaveFroble davef at tsoft-inc.com
Fri Feb 9 15:41:42 EST 2018


Stephen Hoffman wrote:
> 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.

Slow day, so ....

What IDEs are going to help me with Basic?

Versions don't solve everything.  They are a nice feature, if one can use them. 
  Like everything else, a tool can be used for good, or it can be a disaster.

I've been able to find a few places where file versions give me some flexible 
service, and have been able to automate things to where they are helpful.

Not sure about anyone else, but I've never claimed file versions are a selling 
point.  I could do things differently without them.  But I have them, and I find 
them helpful, for some things.

As for the youngsters, perhaps they don't consider file versions, because 
they've never seen them.


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



More information about the Info-vax mailing list