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

[Stephen Hoffman]

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