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

[Stephen Hoffman]

On 2015-01-20 03:06:47 +0000, David Froble said:

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

A descriptor is a very old and very limited and very primitive version 
of an object, yes.  But with objects — and this is one of the details — 
you're never looking at a descriptor, you're always looking at a 
transparent wad of data.  And of code.  It's an abstraction, but a 
useful one.

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

Yes, but can you store code in one, too?   If you worked at it, sure, 
you could create a way to collect the data and the code together.

(*ponders what OOBASIC would look like and work like*)

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

The nice part is that you can avoid spreading knowledge of what's in 
the object — private data, private routines, public routines, public 
data — around throughout the application code.  Objects are an 
abstraction that cleanly and clearly enforces modularity.

>> 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 ....
> 
> :-)

In BASIC, it would be a sorted array of structures.   Yeah, not really 
hugely new, but a whole lot easier to use and to work with than the old 
ways, and less code to write and to maintain.   Working on VMS now 
reminds me of PDP-11, back when I started on VMS.   The old stuff 
worked, but was just harder to deal with, harder to work with, and much 
more limited.   With a dictionary, the access mechanisms, memory 
management and the rest are all typically baked into the language 
and/or the run-time.

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

So you're maintaining code to do that?  OK.  Your call.  As has 
happened, some old concepts get updated, and the applications can get 
larger and more complex, because tasks that we all used to deal with — 
control sequences and related processing — have gotten pushed down into 
frameworks or into objects.

Those aren't objects.

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

A JIT is an interpreter that can detect and compile and execute the 
busiest of the interpreted code.  It's a technique that can boost 
performance.  Because compilation is more expensive, it's not something 
the interpreter necessarily wants to do for the entire code.  But for 
the busiest part of the code, it works well.

> 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?
> 
> :-)

Given that I can generate and execute machine code from with a BASIC 
program or given I can generate machine code from within DCL, and — 
given sufficient privileges or a security vulnerability — that machine 
code can then do anything I want.  In short, both languages are Turing 
complete.   It's that DCL is clunky, slow, complex, difficult to use 
and requires a whole lot of work to do what can now be simpler tasks.  
Having used both DCL and BASIC for many years, both require more than a 
little coding for what they deliver, and both have no shortage of 
limitations.    If you want new users, the folks are going to want 
newer tools and higher-level abstractions.  Could I write a web browser 
in BASIC?  Sure.  But on some other platforms, the end user need write 
a whole lot fewer lines of code to get to the target solution.   Could 
I write a web browser in BP2 on a PDP-11/RSX-11M box?  Sure.  That's 
how I find using DCL and BASIC on VMS now.  Workable, but a whole lot 
of work.


-- 
Pure Personal Opinion | HoffmanLabs LLC