in reply to Re^2: What if Perl had an OO standard library?
in thread What if Perl had an OO standard library?

With all due respect, that's a distinction without a difference.

"I am inevitable." - Thanos
  • Comment on Re^3: What if Perl had an OO standard library?

Replies are listed 'Best First'.
Re^4: What if Perl had an OO standard library?
by dsheroh (Monsignor) on Aug 24, 2022 at 12:20 UTC
    ...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.

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


        🦛

        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.