http://qs321.pair.com?node_id=11119379


in reply to Re^3: Amicable divorce
in thread Amicable divorce

If your latest C compiler cannot compile your old sources, the old binaries still work

That's not always true, especially if they use dynamic linking. Sometimes it's not even true with static linking. (Try to run an old proprietary Linux game from before 2000 on a recent system, for example.)

No, managers do not always see security as "business value", either. There was one system, written in an old PHP4 framework, that kept getting cracked and various bots installed. Management preferred to routinely clean the intrusions off of the server instead of replacing the system with something reasonably secure. Yes, that is insane. No, that was not my call. I no longer work there.

I've seen that too, but you're reading into sundial's comment something he never said. He explicitly argued that there was no business value to moving from PHP 5 to PHP 7 and tried to convince people of that.

That's not an argument I expect to hear from a developer of his purported experience. Running a public-facing project with a dependency that's out of support from its maintainers as well as long-term support from its distribution is ignorant and best and, more likely, malicious malfeasance.

That's why I respond. I am 100% in favor of asking "What's the business value of this technical change?", but anyone who claims to be a senior developer but snidely brushes away the idea of security updates as an annoyance and hindrance is doing something very wrong.

Replies are listed 'Best First'.
Re^5: Amicable divorce
by jcb (Parson) on Jul 16, 2020 at 02:43 UTC
    That's not always true, especially if they use dynamic linking.

    That is a fair caveat after a system upgrade, but I was thinking of a scenario where the compiler has been upgraded specifically.

    argued that there was no business value to moving from PHP 5 to PHP 7

    From the perspective of a manager who is looking only at the feature lists, what is gained by that change? The "after" feature list looks just like the "before" feature list.

    I see his perspective and I have seen managers apparently make decisions with that kind of thought process. I have had to very carefully firewall Windows servers partially from the Internet, so their services were still available, but the wandering malware could not reach the SMB listener. There was no upgrade path because another piece of proprietary software relied on that specific version of Windows and the newer version would have required a large chain-reaction upgrade (including replacing some very expensive long-life-span equipment that was actually still supported by its manufacturer but not by the other vendor) to continue to support a small part of the business that brought in enough revenue to keep operating but not enough to justify that much expense.

    The problem is what PHP did — breaking backwards compatibility and dropping maintenance on the older version. That Perl 5 remained maintained is why the Perl 6 fiasco did not kill all of Perl.

    PHP was able to drag its userbase along because most of them barely understand what they are doing and have no real alternative to PHP. A few well-run projects happen to be in PHP because their early prototypes were made in PHP and incrementally grew complex enough that migration away from PHP is very difficult for them. As an example, last I checked, MediaWiki has an ongoing long-term effort to migrate to Python. The typical small PHP "app" does not have anything close to the level of developers available to MediaWiki. They are stuck with PHP, and the PHP runtime developers learned this after pushing PHP 5 on their community and have continued to abuse this power.

    The perl developers do not have this power — mastering Perl in the first place requires developing a level of skill sufficient to easily branch out into other languages; I actually learned C after learning Perl. Perl developers can jump to other languages much more easily, and breaking backwards compatibility to the point of needing significant rewrites has a much lower threshold for those rewrites to go to some other language if there is the slightest hint that it could happen again. Put simply, Perl is a far better language than PHP, with a far more skilled community that, unlike most PHP developers, can already go elsewhere.

    Accordingly, I argue that backwards compatibility must not be broken without very, very, very good reasons — and the advice in PBP does not meet that threshold for a language that famously touts TIMTOWTDI.

      From the perspective of a manager who is looking only at the feature lists, what is gained by that change? The "after" feature list looks just like the "before" feature list.

      Sure, but why should anyone care what a really bad manager thinks? If we're going to chase the lemon market of terrible management, we're not going to get what we want.

      Perl developers can jump to other languages much more easily, and breaking backwards compatibility to the point of needing significant rewrites has a much lower threshold for those rewrites to go to some other language if there is the slightest hint that it could happen again.

      Ah, but from the perspective of a manager who is looking only at the feature lists, what is gained by that rewrite to some other language? The after feature list looks just like the before feature list!

      I think your argument here wants it both ways.

      Accordingly, I argue that backwards compatibility must not be broken without very, very, very good reasons — and the advice in PBP does not meet that threshold for a language that famously touts TIMTOWTDI.

      There aren't very many people arguing seriously that backwards compatibility should be broken willy-nilly, but there seem to be several people arguing that other people are arguing that. That makes it difficult for me to take this argument seriously.

      My argument is that backwards compatibility is largely a good thing, but it's less important than:

      • Improving the default experience for new programmers
      • Fixing bugs and security flaws
      • Adding long-missing features

      The argument in favor of maintaining strict backwards compatibility has lost (. in @INC by default, hash randomization, do &sub syntax, pseudohashes, unescaped { in regular expressions, mandatory parentheses around quoted lists in iterations), and it's prioritizing use cases that neither contribute to Perl development nor have a coherent use case.

      I'll expand on the latter. What do we know about a project that's still deployed on Perl 5.6.1? We know:

      • They're not using much of the CPAN
      • They're not particularly interested in new Perl language features
      • They don't care about support from p5p or distributions
      • They don't care about security
      • If they're investing in their code, they're not considering any external factors as important

      What benefit is there in releasing a Perl 5.34 designed to support them that they will not update to (which we know because they haven't updated to 5.8.0, 5.8.1, 5.8.2, 5.8.3, et al)?

      They have chosen their support burden—lack of community support, lack of security features, backporting patches they want, dwindling OS and compiler toolchain support—so why put a greater support burden on people who actively do contribute to the language and the language ecosystem?

        lemon market of terrible management

        That is a great way of describing it.

        Ah, but from the perspective of a manager who is looking only at the feature lists, what is gained by that rewrite to some other language? The after feature list looks just like the before feature list!

        These represent different audiences: the manager looking only at feature lists objects to rewriting the code at all, while the programmer considering a rewrite to another language is seeking to make "this" rewrite "the last one" or at least to minimize the chances of having to do this all over again. The typical PHP programmer only knows PHP — programmers who learn other languages tend to move to those other languages. The typical Perl programmer can be expected to already know other languages but has stayed with Perl because of its nice features.

        There aren't very many people arguing seriously that backwards compatibility should be broken willy-nilly, but there seem to be several people arguing that other people are arguing that.

        The problem is that it was reported that the individual leading the push for Perl 7 advocated breaking backwards compatibility not for any of the reasons you listed but for purely stylistic reasons. Removing features from the TIMTOWTDI language because you do not like the syntax is not an acceptable precedent to set because then the next guy has different tastes, so removes other features, and the next-next guy does not like something else, and eventually you have a Fahrenheit 451 language (the mass-banning of books in that story began with a little censorship here and a little there, all from different groups with their own proverbial axes to grind) that makes PHP look good by comparison. Every feature removed makes Perl a little poorer. Sometimes there can be improvements to the interpreter that are worth that cost, making Perl richer somewhere else, but citing PBP does not support such a claim.