Discussion:
Greg Kroah-Hartman on backwards compatibility
(too old to reply)
Arne Vajhøj
2020-11-30 15:24:18 UTC
Permalink
https://thenewstack.io/greg-kroah-hartman-lessons-for-developers-from-20-years-of-linux-kernel-work

He talks about Linux, but I think we could do s/Linux/VMS/w
without anyone noticing.

Arne
Simon Clubley
2020-11-30 18:27:36 UTC
Permalink
Post by Arne Vajhøj
https://thenewstack.io/greg-kroah-hartman-lessons-for-developers-from-20-years-of-linux-kernel-work
He talks about Linux, but I think we could do s/Linux/VMS/w
without anyone noticing.
For some reason, I don't think of systemd as an example of things
done perfectly.

Simon.
--
Simon Clubley, ***@remove_me.eisner.decus.org-Earth.UFP
Walking destinations on a map are further away than they appear.
geze...@rlgsc.com
2020-12-01 13:15:51 UTC
Permalink
Post by Arne Vajhøj
https://thenewstack.io/greg-kroah-hartman-lessons-for-developers-from-20-years-of-linux-kernel-work
He talks about Linux, but I think we could do s/Linux/VMS/w
without anyone noticing.
Arne
Arne,

I am not sure about the systemd comments, but I will beg to differ on the API comments.

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.

I spoke about this years ago at several conferences in a session entitled "Forethought: The Unspoken Foundation of Evolution", the slides can be found at: http://www.rlgsc.com/iasa/nyc/2009/forethought-unspoken-foundation.html. I also spoke several times specifically on API architecture.

- Bob Gezelter, http://www.rlgsc.com
Stephen Hoffman
2020-12-01 15:03:13 UTC
Permalink
Post by ***@rlgsc.com
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.
Post by ***@rlgsc.com
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.
Post by ***@rlgsc.com
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
geze...@rlgsc.com
2020-12-01 15:11:58 UTC
Permalink
Post by Stephen Hoffman
Post by ***@rlgsc.com
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.
Post by ***@rlgsc.com
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.
Post by ***@rlgsc.com
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
Arne Vajhøj
2020-12-01 15:50:53 UTC
Permalink
Post by ***@rlgsc.com
Post by Stephen Hoffman
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
Dave Froble
2020-12-01 17:59:53 UTC
Permalink
Post by Arne Vajhøj
Post by ***@rlgsc.com
Post by Stephen Hoffman
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
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2020-12-01 18:27:36 UTC
Permalink
Post by Dave Froble
Post by Arne Vajhøj
Post by ***@rlgsc.com
Post by Stephen Hoffman
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
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.
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?
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.
I am not quite sure that I understand your point.

The point is that having a large important code base that
nobody knows is a risk.

It will take a long time to fix if an upgrade break it. And
it will take a long time to implement changes to business rules.
Simply because whoever get the task will have to spend significant
time figuring out how the code works.

The discussion whether the solution is to have somebody learn
the existing code base or do a major update in technology is
something that follows if management realize the risk and
decide to do something about it.

Factors that will influence the decision include: is it
easy to hire or train people in the current technology,
is the current technology still supported, could a technology
change reduce code base dramatically by switching from
custom code to standard library, could a technology
switch enable new features that business want.

Complex evaluation. But the companies I was talking
about are not there (yet).

Arne
Stephen Hoffman
2020-12-01 18:39:00 UTC
Permalink
Post by Dave Froble
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?
If you're doing a wholesale port, or doing a wholesale rewrite, sure.
Those tend to be wasteful.

All of the (successful) rewrites and overhauls I've been involved with
have been incremental.

Usually by identifying the most problematic areas, and by identifying
the areas where better and faster product differentiation can be
maintained, or new features or new differentiations can be gained.

The best of those efforts further preserved and isolated the core of
the working code too, though that's not always feasible. Sometimes
bigger hunks necessarily get replaced.
Post by Dave Froble
Go ahead and answer that.
I've been doing incremental re-work for years.
Post by Dave Froble
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.
Incrementally, there is no particular advantage. Longer-term, it's how
an existing package suddenly finds itself becomes uninteresting.
Post by Dave Froble
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.
The business risk is of a customer deciding that an environment is no
longer suitable, and porting the data to a different platform.
Post by Dave Froble
Maybe the best solution is to ignore the idiots that want to re-write
all the apps every year or two.
Remaining static, and not integrating changes and improvements works
for a while. But competitors have a habit of adapting and adopting and
evolving, as do customer expectations.

Does this mean rewriting it all in Rust? Absolutely not. But does this
mean more work on maintenance and refactoring than many legacy sites
might want to expend? Yes.

Trade-offs. Trade-offs everywhere.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2020-12-01 18:39:00 UTC
Permalink
Post by Dave Froble
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?
And the most common "modern" languages are not that new.

The big ones are typical 20-30 years old:

C++ 1985
Python 1991
Java 1995
PHP 1995
Ruby 1995
JavaScript 1995
C# 2000
VB.NET 2001

And even the smaller "up and coming" languages are typical 10-15 years old:

Groovy 2003
Scala 2004
F# 2005
Go 2009
Rust 2010
Kotlin 2011
Swift 2014

Arne
Stephen Hoffman
2020-12-01 16:41:35 UTC
Permalink
Post by ***@rlgsc.com
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.

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.
Post by ***@rlgsc.com
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.
Post by ***@rlgsc.com
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've previously commented that Microsoft .NET looks like the OpenVMS
calling standard, a couple of decades on.

Though OO is not a small effort for VSI and for existing tooling and
for existing and future developers, and an effort where acceptance can
and would only be measured in decades.

As lauded and sought after as endemic and perpetual compatibility might
be, and as necessary as compatibility is for everybody particularly
short-to-mid-term, endemic upward compatibility is fundamentally
disastrous for the vendor long-term, and is more subtly problematic
for the end-users longer-term.

Our ability to predict the appropriate hardware and software trade-offs
a decade or two out is poor. And more recently we've been operating
with retrofit fixes for VAX-era 16- and 32-bit designs for a couple of
decades. Which is where that and similar articles get into trouble.
Sooner or later, every environment collapses under the weight of its
compromises, whether semantic or syntax or API or otherwise. Or it
changes.
--
Pure Personal Opinion | HoffmanLabs LLC
Dave Froble
2020-12-01 18:16:55 UTC
Permalink
Post by Stephen Hoffman
Post by ***@rlgsc.com
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.
Post by Stephen Hoffman
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.
Post by Stephen Hoffman
Post by ***@rlgsc.com
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 ...

:-)
Post by Stephen Hoffman
Post by ***@rlgsc.com
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: ***@tsoft-inc.com
DFE Ultralights, Inc.
170 Grimplin Road
Vanderbilt, PA 15486
Arne Vajhøj
2020-12-01 18:55:43 UTC
Permalink
Post by Dave Froble
Post by Stephen Hoffman
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.
Luckily the *nix/early Win philosophy of tying API's to
one language are generally considered obsolete today.

MSVC++, VB6, VBS etc. share common COM API's.

Java, Scala, Kotlin, Groovy and various script languages share common
Java API's.

C#, VB.NET, F#, C++/CLR etc. share various .NET API's.

C++, Rust, JavaScript, TypeScript and even C# and VB.NET share common
WinRT API's.

TypeScript and Dart can get transpiled to
JavaScript and together with JavaScript use JavaScript API's.

Arne
Arne Vajhøj
2020-12-01 15:39:17 UTC
Permalink
Post by Stephen Hoffman
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.
That is definitely the way to go for future API's.
Post by Stephen Hoffman
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.
Shouldn't you be using Swift instead of Objective-C?

:-)
Post by Stephen Hoffman
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.
Yes.

It will take a lot of man years to create a complete new sets of API's.
Post by Stephen Hoffman
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.
Basic and Pascal are obvious languages to utilize higher level API's.

I do not see C in that role.

Arne
Craig A. Berry
2020-12-01 15:57:41 UTC
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
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.
Basic and Pascal are obvious languages to utilize higher level API's.
I do not see C in that role.
I think he just means you could replace C with Objective C (or C#) and
not have to worry so much about stomping on pointers and explicit memory
handling.
Stephen Hoffman
2020-12-01 17:08:13 UTC
Permalink
Post by Craig A. Berry
Post by Arne Vajhøj
Post by Stephen Hoffman
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.
Basic and Pascal are obvious languages to utilize higher level API's.
I do not see C in that role.
I think he just means you could replace C with Objective C (or C#) and
not have to worry so much about stomping on pointers and explicit
memory handling.
Ayup. Objective C is nice to work with, particularly with all the
frameworks around. And Objective C preserves and maintains the
capabilities of C, if/as/when those are needed.
--
Pure Personal Opinion | HoffmanLabs LLC
Stephen Hoffman
2020-12-01 17:04:48 UTC
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
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.
That is definitely the way to go for future API's.
And of course as a replacement for existing OpenVMS APIs, as those too
will need to transition for this to be useful. But then I don't see an
overhauled OpenVMS calling standard anytime soon.
Post by Arne Vajhøj
Post by Stephen Hoffman
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.
Shouldn't you be using Swift instead of Objective-C?
:-)
Apropos of this very discussion, Swift was making breaking source
changes until version 4 (2017), and was making breaking binary ABI
changes until version 5 (2019). That has all stabilized in more recent
versions.

The volume of existing Objective C code means that language is not
going away soon, allowing for an incremental transition to new work in
Swift (or Rust or others) as appropriate.

I don't foresee Swift (or Rust) becoming hugely popular on OpenVMS, either.
Post by Arne Vajhøj
Post by Stephen Hoffman
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.
Basic and Pascal are obvious languages to utilize higher level API's.
I do not see C in that role.
As C? No. As Objective C? Yes. Objective C allows all the classic and
lower-level C shenanigans (and yes, the downsides of same), while is
also fully OO. Which is really handy.
--
Pure Personal Opinion | HoffmanLabs LLC
Arne Vajhøj
2020-12-01 19:24:36 UTC
Permalink
Post by Arne Vajhøj
Post by Stephen Hoffman
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.
Shouldn't you be using Swift instead of Objective-C?
:-)
The volume of existing Objective C code means that language is not going
away soon, allowing for an incremental transition to new work in Swift
(or Rust or others) as appropriate.
I don't foresee Swift (or Rust) becoming hugely popular on OpenVMS, either.
Among other issues: they are not available on VMS for npw.
Post by Arne Vajhøj
Post by Stephen Hoffman
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.
Basic and Pascal are obvious languages to utilize higher level API's.
I do not see C in that role.
As C? No. As Objective C? Yes. Objective C allows all the classic and
lower-level C shenanigans (and yes, the downsides of same), while is
also fully OO. Which is really handy.
I must admit that I consider the C#/Rust unsafe block approach
much better than C++/Objective-C approach.

Arne

Arne Vajhøj
2020-12-01 16:18:38 UTC
Permalink
Post by ***@rlgsc.com
Post by Arne Vajhøj
https://thenewstack.io/greg-kroah-hartman-lessons-for-developers-from-20-years-of-linux-kernel-work
He talks about Linux, but I think we could do s/Linux/VMS/w
Post by ***@rlgsc.com
Post by Arne Vajhøj
without anyone noticing.
I am not sure about the systemd comments, but I will beg to differ on the API comments.
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.
His point is that there should not be any breaking
changes to API's only pure extensions.

And I think VMS has followed that model.

When going to 64 bit we got a bunch of _64 system
services.

And even though SYS$QIO(W) has not changed much then it did
get supplemented by SYS$IO_PERFORM(W).

Arne
David Jones
2020-12-01 18:22:23 UTC
Permalink
Post by Arne Vajhøj
https://thenewstack.io/greg-kroah-hartman-lessons-for-developers-from-20-years-of-linux-kernel-work
He talks about Linux, but I think we could do s/Linux/VMS/w
without anyone noticing.
"Don't make you users mad."

My observation has been that if your market is quickly growing, you don't care if you
make your old users mad because you have 3 or 4 times as many new users that are
very happy with the cool new stuff.
Stephen Hoffman
2020-12-01 18:40:40 UTC
Permalink
Post by David Jones
https://thenewstack.io/greg-kroah-hartman-lessons-for-developers-from-20-years-of-linux-kernel-work>>
He talks about Linux, but I think we could do s/Linux/VMS/w> without
anyone noticing.>
"Don't make you users mad."
My observation has been that if your market is quickly growing, you
don't care if you make your old users mad because you have 3 or 4 times
as many new users that are very happy with the cool new stuff.
Ayup. And should your market stagnate, you'd better be very well
positioned or it'll get ugly.
--
Pure Personal Opinion | HoffmanLabs LLC
Loading...