Today github broke a large amount of the internet's github centric
build chains by upgrading git. (See "Stability of git-archive,
breaking (?) the Github universe, and a possible solution" (message id
<a812a664-67ea-c0ba-599f-cb79e2d96694@gmail.com> on the git list)
In the ensuing discussion there were repeated mentions of "Hyrums
law"[1]. I hadnt heard the term so I went to read up on it at
https://www.hyrumslaw.com/
It turns out this law can be summed up as:
"With a sufficient number of users of an API, it does not matter what
you promise in the contract: all observable behaviors of your system
will be depended on by somebody."
This is pretty much the same conversation about PERL_USE_VOLATILE_API
that we are having in https://github.com/Perl/perl5/pull/20744 and the
same problem we have had with warnings categories, with experimental
features, etc.
One of the corroloraries of this law is that if an API is sufficiently
stable, no matter how it is marked or documented, it will be treated
as stable regardless.
The only way to prevent this from happening is to make the API
actually unstable. For instance, I have seen Perl classes choose
randomly from one of three different internal representations (hash,
array, and scalar reference based objects) at random at startup to
prevent users from exploiting "unwarranted chumminess" with the
internals of the objects it produces. Anyone dumb enough to pierce the
veil of the object would find their next run failed with a fatal
error.
I have been thinking that maybe we should do something similar for
PERL_USE_VOLATILE_API, and maybe also with experimental apis. For
instance we could specify a PERL_USE_VOLATILE_API key for each
(major?) release. Anything using the API's would have to specify the
correct key in the define for each version of perl. This would ensure
that people understand that if they are to use the volatile API they
will have to update their code *each* *release*. Similarly we could do
the same with experimental features. Each release we could specify a
string that must be provided to these features (or maybe set in the
environment or something), so that they continue to work.
This would ensure that people understand that if they use these
volatile or experimental things there will be a permanent maintenance
burden from doing so, and that they will have to deal with breakage
every release.
Of course this would strongly dissuade people from using experimental
features in production, and it would impose a maint burden on XS
authors using these volatile API's but it would free us from having to
deal with the fallout when we actually do change these things and it
causes gnashing of teeth because people have been fooled into thinking
it was stable. After all, if you use something that says on the box
"this will change every release" and it does so consistently then you
can hardly complain when it changes in a more substantial way.
I dunno if this is really a good idea, but I thought we should at
least talk about it a bit. I know some folks will hate it for sure,
but I wonder if it would make maintaining the internals and
experiments easier and maybe drive adoption of experimental features
more quickly. If there is no disadvantage of using an experimental or
volatile API then there is no reason not to use it without feeding
back that the experimental status should be removed. But if you know
it *will* break every release you might give feedback more quickly so
the experimental feature will be converted to "stable" status. For
PERL_USE_VOLATILE_API it would send the message that using something
marked volatile will necessitate a long term investment, and maybe
encourage people to think carefully about what expectations they have
from of the API.
Maybe it's crazy tho. I can argue it both ways.
Thoughts?
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"
build chains by upgrading git. (See "Stability of git-archive,
breaking (?) the Github universe, and a possible solution" (message id
<a812a664-67ea-c0ba-599f-cb79e2d96694@gmail.com> on the git list)
In the ensuing discussion there were repeated mentions of "Hyrums
law"[1]. I hadnt heard the term so I went to read up on it at
https://www.hyrumslaw.com/
It turns out this law can be summed up as:
"With a sufficient number of users of an API, it does not matter what
you promise in the contract: all observable behaviors of your system
will be depended on by somebody."
This is pretty much the same conversation about PERL_USE_VOLATILE_API
that we are having in https://github.com/Perl/perl5/pull/20744 and the
same problem we have had with warnings categories, with experimental
features, etc.
One of the corroloraries of this law is that if an API is sufficiently
stable, no matter how it is marked or documented, it will be treated
as stable regardless.
The only way to prevent this from happening is to make the API
actually unstable. For instance, I have seen Perl classes choose
randomly from one of three different internal representations (hash,
array, and scalar reference based objects) at random at startup to
prevent users from exploiting "unwarranted chumminess" with the
internals of the objects it produces. Anyone dumb enough to pierce the
veil of the object would find their next run failed with a fatal
error.
I have been thinking that maybe we should do something similar for
PERL_USE_VOLATILE_API, and maybe also with experimental apis. For
instance we could specify a PERL_USE_VOLATILE_API key for each
(major?) release. Anything using the API's would have to specify the
correct key in the define for each version of perl. This would ensure
that people understand that if they are to use the volatile API they
will have to update their code *each* *release*. Similarly we could do
the same with experimental features. Each release we could specify a
string that must be provided to these features (or maybe set in the
environment or something), so that they continue to work.
This would ensure that people understand that if they use these
volatile or experimental things there will be a permanent maintenance
burden from doing so, and that they will have to deal with breakage
every release.
Of course this would strongly dissuade people from using experimental
features in production, and it would impose a maint burden on XS
authors using these volatile API's but it would free us from having to
deal with the fallout when we actually do change these things and it
causes gnashing of teeth because people have been fooled into thinking
it was stable. After all, if you use something that says on the box
"this will change every release" and it does so consistently then you
can hardly complain when it changes in a more substantial way.
I dunno if this is really a good idea, but I thought we should at
least talk about it a bit. I know some folks will hate it for sure,
but I wonder if it would make maintaining the internals and
experiments easier and maybe drive adoption of experimental features
more quickly. If there is no disadvantage of using an experimental or
volatile API then there is no reason not to use it without feeding
back that the experimental status should be removed. But if you know
it *will* break every release you might give feedback more quickly so
the experimental feature will be converted to "stable" status. For
PERL_USE_VOLATILE_API it would send the message that using something
marked volatile will necessitate a long term investment, and maybe
encourage people to think carefully about what expectations they have
from of the API.
Maybe it's crazy tho. I can argue it both ways.
Thoughts?
cheers,
Yves
--
perl -Mre=debug -e "/just|another|perl|hacker/"