More and more I feel that software is something that's inflicted on me rather than something I create or control that serves me.
-
So what am I actually arguing here?
This is not 1995 and the expectations surrounding publicly distributed code are very different now.
Some of those expectations are reasonable. If an author knows their code is dangerously broken, it should be fixed or be pulled from distribution. You need to be better than Matt from Matt's Script Archive. You should not be publishing to npm or PyPi or CRAN or CPAN or any of the public repositories unless you accept the minimal responsibility for fixing or retiring your code.
_RETIRING CODE IS ALWAYS AN OPTION, EVEN IN A PUBLIC REPOSITORY_
But let's take npm as a bad example. What happens when an author decides to retire their code and stops distributing it and pulling it from a public archive breaks other people's applications that rely on code from that public archive? Do we accept the breakage that results from our naïve expectations of the public archive or does the archive continue to distribute the retired code against the author's wishes without forking the code and taking responsibility for it?
I was on call the night of Friday, December 31, 1999. The right answer is that organizationally, you take responsibility for your code _AND ALL ITS DEPENDENCIES_ and you factor in that the public repository is not guaranteed to be there when you need it and that any code you pulled in from the internet is your responsibility. You own those dependencies once you start relying on them. Unless you have an explicit agreement with the original author, they owe you _NOTHING_.
That is apparently not the modern expectation. The modern expectation is that authors who make their code public owe free maintenance, development, and security fixes to corporations for free forever and if you ever try to extract yourself from this implicit serfdom by retiring your code, some asshole organization will keep distributing your retired code under your name and keep you yoked to that millstone.
Am I arguing to have it both ways? No. It's reasonable to distribute code of average quality and maintain it on one's own schedule. It's also reasonable to retire code for any reason but specifically because you no longer have the time or interest to maintain it at an average or (personally) acceptable level of quality. Mark it as archived and unsupported so it's clear to everyone what the project's status is. In an extreme case, stop distributing the code - that's what should have happened with Matt's Script Archive.
@arclight My view is that nobody should use Other Peoples' Code. You write code for yourself, or for your job. If you want to share it, fine, but nobody should use it. You MUST review/rewrite.
But we live in a fallen world, & people are foolish & lazy, so they DO use OPC. That choice is not my problem.
Even an operating system or language, you must be aware that you didn't write this, it's not yours or safe. Only Terry Davis lived free of sin, & he was insane.
Digital Mark λ ☕️ 🚀 🌗 (@mdhughes@appdot.net)
I wrote this as a ha-ha-but-seriously-yes: You should only use software you wrote for yourself, never let anyone else touch it. Other Peoples' Code is the work of the devil.
AppDot.Net (appdot.net)
-
@arclight My view is that nobody should use Other Peoples' Code. You write code for yourself, or for your job. If you want to share it, fine, but nobody should use it. You MUST review/rewrite.
But we live in a fallen world, & people are foolish & lazy, so they DO use OPC. That choice is not my problem.
Even an operating system or language, you must be aware that you didn't write this, it's not yours or safe. Only Terry Davis lived free of sin, & he was insane.
Digital Mark λ ☕️ 🚀 🌗 (@mdhughes@appdot.net)
I wrote this as a ha-ha-but-seriously-yes: You should only use software you wrote for yourself, never let anyone else touch it. Other Peoples' Code is the work of the devil.
AppDot.Net (appdot.net)
That seems overly pessimistic. I can't imagine you grow your own food, built your own house, synthesize your own medicine. For all these things you rely on others, even though the stakes are higher than for most software.
I think the difference is the lack of oversight. There are enforced regulations governing how each of these things are done, so that (at least ideally) you can rely on them being of a certain level of quality. Software is pretty unique in not having that yet, at least at a societal level.
-
@arclight My view is that nobody should use Other Peoples' Code. You write code for yourself, or for your job. If you want to share it, fine, but nobody should use it. You MUST review/rewrite.
But we live in a fallen world, & people are foolish & lazy, so they DO use OPC. That choice is not my problem.
Even an operating system or language, you must be aware that you didn't write this, it's not yours or safe. Only Terry Davis lived free of sin, & he was insane.
Digital Mark λ ☕️ 🚀 🌗 (@mdhughes@appdot.net)
I wrote this as a ha-ha-but-seriously-yes: You should only use software you wrote for yourself, never let anyone else touch it. Other Peoples' Code is the work of the devil.
AppDot.Net (appdot.net)
@mdhughes We've been sold the notion of reusable code for decade. This history of LINPACK/LAPACK is interesting - the motivation in the early 70s was to have quality numerical routines instead of every dingus with a VAX writing their own matrix solvers badly, they modern equivalent of rolling your own crypto. DIY is usually a Really Bad Idea in these cases. On the other extreme is basically every interpreted code calling in an avalanche of nested dependencies because somebody didn't want to write a ten line function and they had DRY beaten into them.
I think what's lost with frictionless dependencies is that devs don't question whether most dependencies are really needed. It seemingly costs nothing to import a dozen packages that rely on two dozen more behind the scenes. They've been taken in by the cult of DRY and velocity and they don't know how to operate in an environment where free fast internet access isn't available. And here the problem isn't lack of connectivity or bandwidth, it's the rapidly decaying trustability of third-party code. Between bad actors and AI(+) we're getting to a point where network doesn't matter because nothing on the network can be trusted.
(+) Cue Pam: "These are the same picture."
-
That seems overly pessimistic. I can't imagine you grow your own food, built your own house, synthesize your own medicine. For all these things you rely on others, even though the stakes are higher than for most software.
I think the difference is the lack of oversight. There are enforced regulations governing how each of these things are done, so that (at least ideally) you can rely on them being of a certain level of quality. Software is pretty unique in not having that yet, at least at a societal level.
-
@mdhughes We've been sold the notion of reusable code for decade. This history of LINPACK/LAPACK is interesting - the motivation in the early 70s was to have quality numerical routines instead of every dingus with a VAX writing their own matrix solvers badly, they modern equivalent of rolling your own crypto. DIY is usually a Really Bad Idea in these cases. On the other extreme is basically every interpreted code calling in an avalanche of nested dependencies because somebody didn't want to write a ten line function and they had DRY beaten into them.
I think what's lost with frictionless dependencies is that devs don't question whether most dependencies are really needed. It seemingly costs nothing to import a dozen packages that rely on two dozen more behind the scenes. They've been taken in by the cult of DRY and velocity and they don't know how to operate in an environment where free fast internet access isn't available. And here the problem isn't lack of connectivity or bandwidth, it's the rapidly decaying trustability of third-party code. Between bad actors and AI(+) we're getting to a point where network doesn't matter because nothing on the network can be trusted.
(+) Cue Pam: "These are the same picture."
@arclight Yes, the "Software Integrated Circuit"/black box idea was a massive failure, it does not work, you get nonsense like npm's left-pad or outright scams.
Software as a library should be used for research only, like a real library. You go there, read what someone did, make notes, do your own thing entirely separate. So LINPACK should be a book; Numerical Recipes is. If someone's determined that it has to be preinstalled, everyone should still review it if they care if it works or not.
-
@arclight Not a joke: I installed WordStar 7 in DOSBox-X today.
Zero JavaScript. It doesn’t download anything. Doesn’t connect to anything. It *can’t* connect to anything.
It’s gonna take a while for the muscle memory to come back, though.
-
R relay@relay.mycrowd.ca shared this topic
