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

[David Froble]

Stephen Hoffman wrote:
> On 2015-01-19 01:56:09 +0000, David Froble said:
> 
>> Stephen Hoffman wrote:
>>
>>> asynchronous processing
>>
>> Use Basic and ASTs
> 
> But then BASIC doesn't script DCL commands all that well, either.
> 

Yes, make my point.  When you need more than DCL has, then use something 
that actually provides the requirements.

I'm not going to paste that 20 times, but it is the same statement for 
most of what's below.

>>
>>> floating point
>>
>> Basic has it
> 
> DCL doesn't.

See above  :-)

> 
>>> 64-bit integers
>>
>> Basic has it
> 
> DCL doesn't.
> 
>>> binary data
>>
>> Basic has it
> 
> DCL doesn't.
> 
>>> objects
>>
>> Can you be specific, don't really understand
> 
> Objects are opaque wads of data (and variously also of the application 
> code, too) which can be passed around, and without particular regard for 
> what the object is or contains.  Think of these like a string or an 
> integer variable, but where you don't have to know what the object 
> contains in order to work with it.   With a string or an integer value 
> in BASIC, you have to special-case how you might print that, for 
> instance.  With objects, the run-time takes care of that.  Pass the 
> object to a print routine, and it gets printed.   The metadata necessary 
> for handling binary data or for ASCII or UTF-8 string encoding can be 
> implemented here, too.   There are other uses for objects of course, and 
> the approach is very flexible.  In some environments, objects can 
> contain code, so you can package the code and the related data 
> together.  This similar to how you might package together some BASIC 
> code into a single source file and then build it into a shareable image, 
> but applied at a much more granular level; where the code and the data 
> can be treated as, well, an object.  Like a shareable image, an object 
> has a defined API, and related behaviors.  Which means that the source 
> code doesn't end up all twisted together, just like you would do with 
> source files and libraries and shareable images.  But this where you 
> might have, for instance, an object within your code that contains a 
> UTF-8 string and some code that can find the length of that string for 
> you, or that can dump out the string.  It's really quite handy.  Newer 
> Fortran and COBOL have some support for this, as do Python and C++ and 
> some other languages, but I've not seen anything similar with BASIC.
> 
> I'm here intentionally not using entirely correct terminology, nor am I 
> detailing method invocations and messaging, or whatever a particular 
> language might call it.

Ya know, samantics is an awful thing.  It's confusing for some like me 
when different names are used for the same thing.

A dynamic string descriptor I think would fit your definition of an 
object.  So would variables and such.

Basically (sic) I can store any data in a string descriptor, and pass 
the address of the descriptor to some routine which knows what to do 
with the stuff pointed to by the descriptor.

Now, I cannot imagine why I'd want to pass some code, rather than data, 
to anything, but we all know I don't get out much, so that might not be 
surprising.  But, surprise, I can pass a string of code using a string 
descriptor.

>>
>>> dictionaries
>>
>> Can you be specific, don't really understand
> 
> Key-value stores.  These are a form of an in-memory indexed file.   
> Specify the key, get the value.   BASIC doesn't have anything similar 
> built into the language, though some folks do use RMS indexed files here.

Oh, you mean like a doubly dimensioned array, or other structure, where 
I can load up some key-value pairs, then invoke a routine or code to 
take a key value and return the associated value?

Different name for the same old things that have been done for many 
years.  Perhaps refined, or specialized, but same thing as your 
description.  Maybe for the old way someone actually has to know how to 
design and implement code ....

:-)


>>
>>> arrays
>>
>> Basic has it
> 
> So does DCL, if I wanted to substitute symbols.
> 
> ...
>>
>>> support for menu-based and graphical-based user interfaces
>>
>> Hmmmmm ........  I've got a menu application ...
> 
> And you probably either used a framework (SMG, FMS, etc) to get there, 
> or you wrote and are maintaining a whole lot of code slinging control 
> sequences around.  DCL doesn't have this option, but more than a few 
> folks have written menus in DCL.  Warts and all.  Less application code 
> and more shared code is better.

Well, actually, not SMG, FMS, and such.  I could get cute and call the 
routines that create the control sequences OBJECTs.  In the end, any 
method creates the control sequences, right?  What matter if my OBJECTs 
are in an OLB library?  I could put them in a shared RTL.

>>
>>> JIT
>>
>> Basic has it
> 
> No, BASIC does not have a JIT.

Are we into symantics again?  I bet if e got down to detail 
descriptions, we could call the ".BAC" files in RSTS/E Basic+ a form of 
JIT.  Or, maybe not.

>>
>>> compilation
>>
>> Basic has it
> 
> DCL is interpreted, and also lacking a JIT.
> 
>>> embedding
>>
>> Can you be specific, don't really understand
> 
> There are parts of many applications where you can SPAWN a procedure, or 
> pass DCL commands into a subprocess.  Imagine if that wasn't a SPAWN, 
> but that the same DCL code was compiled and linked directly into the 
> application.

Ya know, that could get rather tricky.  Personally, I have no problem 
with spawning a subprocess when I need to execute some DCL code.  I 
could most likely code the procedure in Basic, but it would re-inventing 
the wheel, and that's just dumb.

>>> debugging
>>
>> Basic has it
> 
> So does DCL, via third-party.
> 
>>> DCL libraries
>>
>> Basic has object and run time libraries
> 
> Those aren't easily callable from DCL, and DCL has no particular 
> subroutine capabilities for itself, which means that folks have a 
> scattering of separate DCL procedures that they locate by logical name 
> or path, or the folks embed copies of that shared DCL in various 
> procedures, or the folks create their own DCL activation logic.  Which 
> gets messy.
> 
>>
>>> More specific error trapping than ON; let me catch specific errors.
>>
>> Basic has it
> 
> But does your DCL?
> 
>>
>> ...
>> Are we having fun yet?
> 
> Having worked a whole lot in DCL and BASIC and other languages over the 
> years, well, not really.  :-)
> 
> 
> 

Well, I'm having fun.  My argument still is, if you need more than what 
DCL will do, there are alternatives in the compiled languages.  Though I 
won't recommend that C thingy ....

Now for the opposite, can anyone name anything that DCL can do that 
cannot be done in Basic?


:-)