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

Simon Clubley clubley at remove_me.eisner.decus.org-Earth.UFP
Mon Jan 19 16:52:09 EST 2015


On 2015-01-19, John Reagan <xyzzy1959 at gmail.com> 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...
>

Using the traditional approach, the code is not nearly as concise is it
could be. There's also the overhead of calling the lexical multiple
times instead of just calling it once and returning an object containing
all the parsed fields.

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

As computers have become faster and cheaper, the tradeoffs between
program development time and code execution time have changed.

I see Jan-Erik has also posted a queue example in Python which does
pretty much the same thing. If I read that code correctly, it appears
to populate an object in a similar way to the one I am suggesting.

Simon.

-- 
Simon Clubley, clubley at remove_me.eisner.decus.org-Earth.UFP
Microsoft: Bringing you 1980s technology to a 21st century world



More information about the Info-vax mailing list