[Info-vax] Access to _all_ VMS system services and library functions from DCL ?

[Stephen Hoffman]

On 2017-07-10 08:26:00 +0000, mcleanjoh at gmail.com said:

> I'm sure we've been around this block on other occasions but given how 
> memory has expanded enormously since VMS v1.0, why not simply return 
> ALL the relavent data in one large data structure and let the users 
> deal with whatever fields they want to use?
> I'm sure there's some smarts in the processing of what might be 
> multiple item codes but simply copying all the relevant data into a 
> single data structure for the user has to surely be the simplest.

Ayup.  Traditional DCL is not the path forward.   Sure, access to 
system services is nice, but that's just not competitive.   Easier 
access to system services looks wonderful in comparison to where we are 
now, certainly.

But then we start looking at dealing with modern text encodings, with 
the minutia of the system service APIs, and the rest of the knock-off 
effects — well, why not integrate and use Python.   Maybe Lua or some 
other choice, if there's some problem perceived with Python or some 
benefit to offering an alternative.

This whole approach — accessing system services — utterly stinks of 
decades-old thinking, decades-old designs, decades-old processing.   
Which works great if you're (only) solving the sorts of problems that 
OpenVMS has always dealt with, but DCL and the system service 
abstractions are a huge code slog, and code slogs are expensive and 
tedious and lots of user-written code to debug and maintain.

If VSI decides to fund more than some nibble around the edges of the 
existing command interface, and to overhaul the text handling and 
traditional APIs. then a shell that's more competitive PowerShell is a 
much better target than an increasingly-encumbered DCL shell.  Passing 
around entire (opaque) objects, and not atoms of data and fields 
embedded in fixed-format seas of characters.  Much nicer abstractions, 
and easier for VSI to adjust and extend going forward.   We've long ago 
found better ways of dealing with password fields than fixed-format 
records and fixed-length system service itemcodes for the password 
hashes, for instance.   Give folks a reason to move forward.  Leave DCL 
to do what it has always done, and to slowly and further fade from 
relevance.

Beyond PowerShell, some other discussions...
https://unix.stackexchange.com/questions/4495/object-oriented-shell-for-nix
http://ipython.org

This same approach is just all over the place in existing DCL code, too:
https://unix.stackexchange.com/questions/169716/why-is-using-a-shell-loop-to-process-text-considered-bad-practice 


We can either get DCL dragged forward kicking and screaming into the 
early part of this millennium and with a near-inevitable morass of 
UTF-8 hackery and the requisite technical debt inevitable with 
upward-compatibility, or we can get something better aimed at what 
we're going to be doing in 2027, and leaving DCL to quietly graze out 
in some code-pasture out behind BoltonHQ.   Well, that for those of us 
that aren't already or aren't planning to retire in place, and with 
apps that are similarly retired.

TL;DR: DCL and traditional system services APIs just aren't going to be 
interesting for folks looking for platforms for new apps.


-- 
Pure Personal Opinion | HoffmanLabs LLC