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

[johnwallace4 at yahoo.co.uk]

On Monday, 19 January 2015 21:52:41 UTC, Simon Clubley  wrote:
> 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

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

Back in 1980 or so I remember telling my boss that when the 11/40 was  
replaced with an 11/70, it would probably be sensible to consider
whether MACRO11 (with no debugger other than ODT) was actually the
right development tool to use for almost everything we developed. The
boss was actually very understanding (he was a Fortran man anyway).
As F77 hadn't arrived onsite at that point, DECUS RATFOR on top of
RSX/IAS Fortran4Plus filled in, till Whitesmiths C eventually arrived. 

So here we are thirty odd years later having a remarkably similar
discussion, albeit with different hardware and software.

This time round I'd perhaps be happy with Python and GNV as major 
pieces of the way forward, whilst hoping VSI could do a reasonable
job of not breaking the existing stuff for the next few years, and
maybe making point changes where important (e.g. disk volume sizes?).

Others may have other opinions, which is why the suggestion of
consulting the userbase outside this little enclave (current users?
potential?) is an interesting one. 

Have a lot of fun
John