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

[Arne Vajhøj]

On 12/1/2020 10:11 AM, geze... at rlgsc.com wrote:
> On Tuesday, December 1, 2020 at 10:03:18 AM UTC-5, Stephen Hoffman
> wrote:
>> 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.
> 
> 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.

Changes that require real redesign of data structure and/or
logic are obviously much more intrusive.

But even trivial changes like changing the size of
something can be a problem.

Not for code that are being very actively developed.
Then the change can just be rolled into next batch
and everything is fine.

But for the code that nobody touches. The formal "maintainer"
of the code knows that he can go to a certain directory and
do @BUILD, because that was what he was told many years ago when
he took over the responsibility. Nobody that has actually worked
on the code are around any longer.

Code like that is a really a business risk.

But such code exist.

Arne