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

[Dave Froble]

On 12/1/2020 10:50 AM, Arne Vajhøj wrote:
> 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
>
>

I tried to pass over this nonsense, I really tried, but I failed.

Tell me why it is harder to get into existing code for modifications, 
maintenance, fixes, and such, then it is to explore the original design, 
re-write the code in your language of the week, and then test it to 
insure that you didn't screw things up royally?

Go ahead and answer that.

Then tell me just what advantage there is to the entity that uses the 
applications?  They paid very much for at best a sideways move, at least 
from the user's perspective.

The only "business risk" that I can see is the risk that some programmer 
won't get the opportunity to earn big bucks to re-do something that was 
never broken.

Maybe the best solution is to ignore the idiots that want to re-write 
all the apps every year or two.

-- 
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