[Info-vax] DCL's flaws (both scripting and UI)

[David Froble]

Stephen Hoffman wrote:
> On 2015-01-21 16:21:33 +0000, John Reagan said:
> 
>> To give some sense of the difficulty in changing DCL...
> 
> Until the Itanium port, DCL had its own home-grown threading, too.
> 
> If VSI does decide to head down the shebang path (and no pun intended), 
> I'd prefer to see it using a different file type.
> 
> Right now, who knows what stuff is on the first line of an existing DCL 
> procedure.

Might I suggest some form of "$ vfy :== f$verify(0)"

> Trying to do this syntax and grammar retrofit compatibly and within the 
> same DCL-ish context through SET PROCESS /PARSE-style syntax mechanisms 
> and shebangs and related does means more work than using entirely 
> separate CLIs, and it means that most sites will probably either stay 
> with DCL as it is, or will end up with a mixture of the two, and the old 
> code — short of a very effective translation tool — won't ever go 
> away.   How much CC /STANDARD=VAXC code is still around, after all?  
> Again, absolute upward compatibility tends to lead to bigger messes and 
> more effort — particularly when the support for the old and deprecated 
> syntax doesn't ever get removed.
> 
> I'd rather see additions and enhancements that pull folks forward, and — 
> if there's a subsequent DCL retirement planned — a schedule for that 
> removal.

I think it's reasonable for "if it ain't broke, don't fix it", and 
breaking someone's (however disgusting) DCL procedures will not leave 
them very happy.

It's a bit like the "bird in the hand vs 2 very pretty birds in the 
bush".  There is never a guarantee you'll ever get any of the birds in 
the bush.  If you never try, then it's sure you won't get them.  But 
releasing the one in hand maybe isn't the best method to try for the 
ones in the bush.

Now I'm wondering if any of that actually makes any sense ...