[Info-vax] Greg Kroah-Hartman on backwards compatibility

[Dave Froble]

On 12/1/2020 11:41 AM, Stephen Hoffman wrote:
> On 2020-12-01 15:11:58 +0000, geze... at rlgsc.com said:
>
>> I do not disagree that the mechanics of QIO are dated. However,
>> focusing on the mechanics of itemlists, etc. is missing the primary
>> point of my comment. Syntax changes are indeed vexing, but they are
>> just that, syntax.
>
> I find $qio archaic and itemlists archaic, and the stability of $qio
> arguably has as much to do with the longstanding allergy to even making
> any changes as with any API stability or its (in)elegance.

My perspective is that the problems, and flexibility, of QIO is that it 
is a "one size fits all".

QIO is used to access devices, files within a file system, data within a 
file, terminals, and just about everything else in VMS.  It might be 
much easier to do all the things QIO is used for if more specific 
capabilities existed.  But then also what if a new capability is 
required which QIO could have handled?

Item lists are rather generic, and thus capable of many things.  Item 
lists are generic, and thus harder to use than a construct designed for 
a particular job.

> And it's all syntax sugar, all the way down to the machine code. A
> Simple Matter Of Programming. Of development by first principles. Of the
> wars among those working with compilers and those using assemblers, in
> decades past. But I digress.

Programming languages, above the level of assembler, could implement 
easier to use constructs.  That's what's happened in some "language of 
the week" products.  I guess some of the OO stuff Steve likes would be 
useful.  However, at the language level is NOT the place for such, at 
the OS level, available to all languages is the proper place.

>> When I referred to QIO, I was referring to the semantic definition.
>
> Add an obscure literary reference or a TikTok link, and my bafflement
> and befuddlement would be complete.

Yeah, went way over my head also ...

:-)

>> Generally speaking, syntax issues are local. Semantic changes are far
>> more global and have a larger impact. IMO.
>
> Or as I put it, fixing $qio and tweaking the design limits piecemeal got
> us into this mess (e.g. 64-bit APIs, etc), and OO is one potential fix.

I believe that to be true to some extent.  After all, what is OO but 
good design and programming practices, taken to an extreme?


-- 
David Froble                       Tel: 724-529-0450
Dave Froble Enterprises, Inc.      E-Mail: davef at tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA  15486