Re^4: What if Perl had an OO standard library?

...until Mars is updated and the Venus dev(s) choose to either copy the updates (difference: additional work for the dev(s), potential to introduce errors if it's not used verbatim) or to leave Venus using the OldMars code (difference: Venus and Mars no longer behave the same way in some cases).

Or, even better:

...until an exploit is found in Mars. and then users have to find every copy of both Mars and Venus on their systems to apply the security update. Which they might not know they need to do if they're not aware that Venus uses its own independent copy of the Mars code.

The latter case came up a few months ago with zlib. Since it's FOSS and fairly simple, many developers chose to include their own copy of the zlib source instead of being dependent on the system having a working zlib installed. Then a major zlib exploit was found, and I had to spend a day or two tracking down everything that used zlib code on any of the machines I'm responsible for, checking if each one had an update available, and then either installing the updates or figuring out how to mitigate the vulnerability where updates weren't available. If they had all just used the system zlib, then I could have updated that and been done with it. That's only "a distinction without a difference" if you're not the poor schmuck who has to admin systems which use the code.

Comment on Re^4: What if Perl had an OO standard library?

Replies are listed 'Best First'.
Re^5: What if Perl had an OO standard library? by Anonymous Monk on Aug 24, 2022 at 14:02 UTC
...until Mars is updated and the Venus dev(s) choose to either copy the updates They're the same person. You're losing folks because they know that Mars and Venus are both being developed by one person. Mars isn't a c+p knockoff of Venus in danger of not staying in sync.	[reply]
Re^6: What if Perl had an OO standard library? by hippo (Bishop) on Aug 24, 2022 at 15:41 UTC
They're the same person. They're the same person today. When either is forked that creates a(nother) problem. Honestly, one dev or a team of thousands doesn't matter: just don't duplicate code. 🦛	[reply]
Re^6: What if Perl had an OO standard library? by dsheroh (Monsignor) on Aug 25, 2022 at 12:31 UTC
They're the same person. And that's a distinction without a difference. Even if they stay perfectly in sync at all times, that does nothing to alleviate the security exploit scenario. The duplication of code still means that admins have to separately identify and update every one of the duplicate instances of that code when the patch is released, regardless of whether all the duplicates are coming from a single source or not. This also applies to routine feature or bugfix updates, but those can be safely skipped and it's no big deal if you miss them because you don't know about the code duplication. But security updates are rather more critical to apply in a timely and reliable fashion, and you shouldn't use a development model which actively makes it harder to stay on top of that unless you have a damn good reason to impose that risk on the users of your code.	[reply]
Re^7: What if Perl had an OO standard library? by Anonymous Monk on Aug 25, 2022 at 16:30 UTC
Then choose one and stick with it. Or don't use either. In fact, maybe your team should hold a series of meetings about whether or not you should use any 3rd party, non-core modules that weren't designed and maintained in house if the expectation of every project is that it needs to be a thin layer over yet another piece of code rather than it being optimized specifically for its use and follow its own development path. Look at the current versions of Mars and Venus on cpan and it's clear that Mars is closer to a low level testbed and benchmarking system. Mars::Meta and Venus::Meta are the closest to actually duplicating code but Venus looks to be optimized to resolve internal config data that doesn't even exist or apply in Mars. Venus is documented for end users. Venus is being promoted to end users. Venus has had a major point oh release and has seen updates since January. Mars didn't even exist until July of this year which begs the question: How could Venus be based on a package that didn't exist for another six months? Anyway, I'm left wondering why Al (or anyone) should be expected to maintain two different projects just to satisfy a need that doesn't exist. If they choose to do so, fine but having the guts in one codebase that only exists to be the sole prerequisite for the wrapper in a totally different codebase seems silly and over complicated.	[reply]


"be consistent"
	PerlMonks