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

[David Froble]

johnwallace4 at yahoo.co.uk wrote:
> On Thursday, 22 January 2015 00:04:13 UTC, David Froble wrote:
>> John Reagan wrote:
>>> On Wednesday, January 21, 2015 at 3:21:36 PM UTC-5, Chris Scheers wrote:
>>>> John Reagan wrote:
>>>>> On Monday, January 19, 2015 at 3:40:48 PM UTC-5, Simon Clubley wrote:
>>>>>
>>>>>> You would keep f$parse for compatibility with existing DCL code and
>>>>>> it would continue to return individual strings, but you could also
>>>>>> have a (say) sys package with a differently named f$parse returning an
>>>>>> object containing all the parsed fields in one go.
>>>>> You mean like SYS$FILESCAN?  What's your issue with multiple calls to F$PARSE?  The overhead?  You are writing in DCL after all...
>>>>>
>>>>> And you want the lexical to populate all the fields even if you aren't going to use them?  Isn't that more expensive?  Imagine the overhead  of collecting ALL the GETJPI fields or ALL the GETQUI fields?  Ugh.
>>>> That doesn't follow.  One of the advantages of OO is that the 
>>>> implementation is hidden.
>>>>
>>>> There is no requirement to collect the values before they are used.
>>>>
>>>> Some values may be collected when they are returned, some when the 
>>>> object is created, some may even be collected before the object is created.
>>> Absolutely, that is why I objected (pardon the pun) to the use of the word
>>> 'object' in the original discussion.  For the DCL extension, it felt more
>>> like a structured return.  Not smart at all.  Quite different from the
>>> Python/Perl examples provided later in the thread.
>>>
>>> And I'm certainly not going to add real objects & methods to DCL.  You'll
>>> see object oriented COBOL before that. (and yes, the COBOL standard
>>> did add object-oriented).  And to be clear, you won't see OO COBOL either.
>>> I wouldn't mind some things beyond COBOL85 but that isn't one.  [I just spent
>>> the last 1.5 years working on NonStop COBOL among other things.]
>> When does a module of code that performs a task stop being a module and 
>> becomes an object?
> 
> Simple question, potentially complex answer (as frequently happens).
> 
> Try, for example, 
> http://programmers.stackexchange.com/questions/34584/how-to-explain-oop-concepts-to-a-non-technical-person
> (from the stackfamily of websites that Hoff mentioned earlier, which are
> frequently used either instead of manuals or instead of reading the
> manuals).
> 
> Beyond that, there's an Object Oriented Programming for Dummies, if that's
> your kind of thing.
> 
> Or lots of stuff in between. Have a wander round the web, see what you find, if/when the weather's not aircraft-compatible.
> 
> Or maybe just think of an object as an aggregration of data items and
> routines to access the items. Some of the data and routines are visible
> to the world at large, some routines and data may be considered private
> (so that the internal implentation details of an object can be kept
> hidden, visible only to Those Who Need to Know, whilst the outside
> visible stuff interfaces in a known and controlled way).

Would not that description fit things such as the VMS system services?

> Objects are commonly spoken about in the same sentence as classes.

Maybe that explains it.  I've never under "classes" either.

> Together they provide useful features like inheritance (of code and
> data). An American Longhair is a kind of Cat which is a kind of Quadruped.
> American Longhair inherits the core characteristics of cat and has its own
> specific distinguishing features. A Cat inherits the core
> characteristics of Quadruped. And so on.
> 
> That's probably a rubbish definition as it was made up as I typed it. But
> it may give you a flavoUr.
> 
> Have a lot of fun.