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

...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.
  • Comment on Re^5: What if Perl had an OO standard library?

Replies are listed 'Best First'.
Re^6: What if Perl had an OO standard library?
by hippo (Archbishop) 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]
      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]

In Section Meditations