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

[geze...@rlgsc.com]

On Tuesday, December 1, 2020 at 10:03:18 AM UTC-5, Stephen Hoffman wrote:
> On 2020-12-01 13:15:51 +0000, geze... at rlgsc.com said: 
> 
> > I am not sure about the systemd comments, but I will beg to differ on 
> > the API comments.
> systemd has been... controversial. 
> 
> Back when I first met $qio and itemlists and that style of API design 
> and far too many years ago, I thought all that was wonderful... And for 
> that era, it was good. ~Thirty years on, that's becoming a limit and a 
> liability for the apps that I'd like to write; that I write 
> else-platform.
> > It most definitely is possible to architect and implement APIs that 
> > endure for decades, without change. One must specify what must be 
> > specified, and leave undefined what is not necessary. If semantics are 
> > preserved, one of the most common errors is variable range (16 vs. 32 
> > vs. 64 bit), but variable range issues, while challenging, are less 
> > disruptive than semantic changes. OpenVMS QIO is an example of an API 
> > which has been semantically unchanged for close to 50 years, 
> > originating on RSX-11 members in the early 1970s.
> $qio and itemlists and PQLs and other API-related structures also make 
> for convoluted and complex and error-prone calls, and are—as with other 
> parts of the OpenVMS API design—fond of offloading chunks of that API 
> complexity onto the developer-caller. 
> 
> $qio also never managed to transition to 64-bit, though beneficially 
> for the longevity statistics under discussion right here, neither have 
> most apps—so $qio is still the go-to choice for many apps and 
> developers, and $io_perform adoption rather lower.
> > I spoke about this years ago at several conferences in a session
> > entitled "Forethought: The Unspoken Foundation of Evolution", ... I
> > also spoke several times specifically on API architecture.
> I've spoken at conferences discussing the limits of these API designs, 
> and around more modern and more flexible alternatives. For many apps, 
> OO is less code for the caller and less errors, while also providing 
> equal and variously better flexibility and isolation and abstraction. 
> 
> It might be interesting doing a panel on this topic, but that's fodder 
> for the survivors and for a post-pandemic era. 
> 
> This adoption does require updating languages and run-times to allow OO 
> and require developers adopting OO. Having started using Objective C 
> after years of C, and using Cocoa from years of OpenVMS APIs, the 
> transition was striking—how much less code was needed, and how much 
> more flexible and capable the resulting apps were. 
> 
> Do I expect most apps to move from existing designs and 
> implementations? No. Do I expect most OpenVMS developers to move? 
> Slowly, at best. This having just looked at a pile of K&R C. Is 
> breaking existing APIs appropriate? Absent specific requirements or 
> specific limits, and absent a migration path to the new APIs, no. Do I 
> expect VSI to do anything but nibble around the edges of OpenVMS? No. 
> VSI just doesn't have the staff or the budget for that. But pointing to 
> $qio as a laudable design—when less can and less has happened with the 
> underlying platform over the past ~45 years, due to compatibility—is 
> disingenuous at best. If anything, $qio and its baggage is a salient 
> example of the API designs that are holding back app development on 
> OpenVMS. 
> 
> Put differently, BASIC and C and such could be staggeringly better than 
> now, and OpenVMS itself much easier to work with, and so much more than 
> what inflexible APIs including $qio will permit. But if you'll excuse 
> me, I have to deal with Yet Another Itemlist, wrestling with yet 
> another old API scheme which makes fixing under-sized app buffer 
> allocations utterly impossible. q.v. the parallel discussion of 16-bit 
> fields in the mailbox API. And no, I really don't want to have to code 
> an API call to size the buffer to then allocate the buffer to then call 
> the API, but here I am. 
> 
> 
> 
> -- 
> Pure Personal Opinion | HoffmanLabs LLC
Hoff,

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.

When I referred to QIO, I was referring to the semantic definition. Generally speaking, syntax issues are local. Semantic changes are far more global and have a larger impact. IMO.

- Bob Gezelter, http://www.rlgsc.com