[Info-vax] 64 bit DCL ?

[David Froble]

Stephen Hoffman wrote:
> On 2015-01-18 14:50:13 +0000,   VAXman-  @SendSpamHere.ORG said:
> 
>> Fuck that.  If you want Linux, get linux.
> 
> Running Unix is easier in many ways, as that's where the more powerful 
> tools are.   That's also what VMS is competing with.

Not here ....

>> Python?  Gack!  Unnecessary Ubersuperbloatwarez for the task(s) that 
>> DCL should be used to solve.
>>
>> DCL is perfect for what it does and what it should be used for.  
>> Trying to write programs, any programs, that would be better served by 
>> writing them in any compiled language using DCL is, IMNSHO, stupid.  
>> Besides, you can't execute a command in Python such as "$ SHOW 
>> PROCESS" without going through hurdles because that command (or any 
>> for that matter) is issued via a sub-process.
> 
> If DCL is forever going to be the answer, then I don't want to know the 
> question.

That's just it.  DCL (Digital Command Language) is not always the 
answer.  It is called a "Command Language", right there in the name. 
Maybe some don't see the difference, but I for one do not consider it a 
"Programming Language".  After all, it's DCL, not DPL.

> There is a whole lot that DCL is just not very good at, whether it's the 
> perpetual confusion around how many single and double-quotes and 
> ampersands are needed that confuse new users and trip experienced users, 
> on up to the problems with binary data, as well as its inability to deal 
> with UTF-8 and objects and a number of more recent constructs.  DCL has 
> not advanced significantly from its days as a replacement for MCR, and 
> it really shows.

Agreed.

> Then there's that DCL has historically allowed some rather questionable 
> code to more or less work, and that can complicate run-time error 
> detection, the ability to maintain application compatibility, and 
> upward-compatible changes.  It's just not tightly specified, and if 
> those errors were clamped down — DCL will execute certain commented-out 
> code, and how that ability had to be re-added when it was "erroneously" 
> fixed? — would cause some of the existing procedures to break.

Yeah, that execution of comments really got to me.  I'm not sure there 
are words to describe my reaction to that.

"When I say don't do that, then dammit DON'T DO THAT!"

> Look at that debugger you wrote for DCL, and then ask yourself whether 
> that was something that most folks would have already expected to be 
> available.  Look around at the various requires for DCL speed-ups, 
> either via JIT or compilation, too.  DCL is bad at debugging and 
> compilation because the design never had those in mind.  Look at whether 
> it'd be handy to be able to compile in DCL, too — chugging along in 
> whatever language, and then be able to invoke a DCL subroutine to go do 
> something, and not have to deal with the care and feeding of a subprocess.