[Info-vax] VMS Features I Wish Linux Had

[johnwallace4 at yahoo.co.uk]

On Tuesday, 14 June 2016 01:27:15 UTC+1, lawren... at gmail.com  wrote:
> On Tuesday, June 14, 2016 at 9:20:59 AM UTC+12, VAXman- wrote:
> > Huh?  You thought LIB$TPARSE was simpler than CLI/CLD?  I've done some
> > extensive programming around LIB$T(ABLE_)PARSE (thousands of $STATEs/$TRANs
> > statements) but I can tell you that when it comes to a having VMS command
> > syntax in a program, it is CLI/CLD for me.  
> 
> TPARSE was quite versatile, and could be used for other things besides command-line parsing. Whereas CLD was only good for one thing.
> 
> So when it came to deciding where to spend precious brain cells (which are likely still dormant and might not need much to wake them up), the decision was easy.
> 
> I even wrote VAX PASCAL routines to generate TPARSE tables at run-time. (Why? Because it was nicer than MACRO assembler.) As I recall, there were two separate tables: I think the state definitions went in one, and the strings in the other. Everything was referred to via relative offsets, so the structures were entirely relocatable.
> 
> See, those brain cells are starting to wake up already...

Some of us knew that TPARSE and friends do more than CLI stuff. 

I once inherited a cross assembler based on TPARSE. The original
developer, a very bright chap, had thought it was a bright idea but
changed his mind later based on maintainability and user feedback.

The users and management didn't think it was much of an
improvement on its predecessor once they found that its only real
error message was no more specific than "syntax error on line %d"
and (according to the original developer) there seemed little
chance of improving things while still using TPARSE.

Scrapped and rewritten from scratch, still using a table-driven
approach, but not TPARSE, and not just states and transitions. 
Maybe TPARSE works better without potentially erroneous input
from users who want to be told *what exactly* the assembler
doesn't like. 

AFAIK the front end is still in use three decades later (the
back end has changed long ago due to changing the object
output format to be compatible with VAX/VMS tools).

gcc/gas is great (considering), but why would anyone move
to a swiss penknife like gcc if their own tool for the
safety-critical job is relatively simple maintainable
helpful and proven? And when gcc/gas, even if it offers
support for the chip in question, uses different syntax
from the chip vendor's standards  already used in the
company's existing collection of assembler source (9900,
Z8K, 68K, DIY RISC, etc).

Any tool's usefulness may depend on the particular
application. The good craftsman chooses the right tool for
the job. Or in some cases always uses a hammer because it's
all that's permitted.

Occasionally it can be helpful to pay attention to users' (and
even maybe management's) requirements as well as developers'
requirements.