1. 26
  1. 13

    I think the best feedback I’ve heard in these situations (Python, Drupal, Angular, Perl) is that you can go a long way by renaming the project something similar like DrupalNext or whatever, and softly forking the project, leaving the current now-legacy community infrastructure in place. You can make it clear you won’t be investing in the legacy system any more, just let whichever interested parts of the community are there carry the legacy project as far as they want.

    Angular followed this pattern relatively well. There’s a relatively google-friendly split between Angular and AngularJS, all the legacy site and documentation is still there, and there are still occassional maintenance releases.

    1. 3

      Yeah, this is an interesting question. Seems like it’s kinda like the uncanny valley for technologies. That is, if the technology is sufficiently different, people will be okay with it because it’s not a breaking change, it’s simply a different thing.

      For example: Perl 6 seems to have avoided this trap by explicitly stating that backwards compatibility was not a goal, this is something new, etc. In fact apparently the language was renamed to Raku last year to reflect this. And sure enough Perl 5 is still (AFAICT) a thriving community.

      Contrast that with a Python 3: long, drawn out, with many arguments against it and much dragging of feet. That’s not to say that Python 3 was a bad idea, or not executed well given the constraints (I’m sure there are many arguments that it wasn’t, but that’s beside the point here)… but it does make me wonder.

      1. 11

        The perl5/6 split killed perl. Python got hurt with the python 3 compatibility changes, but it’s come through in the end. Maybe if perl 6 had been raku from the start, perl 5 wouldn’t have hurt as much.

        1. 3

          The perl5/6 split killed perl.

          Citation needed. The way I see it, the Perl community is broadly divided into sysadmin hackers who want to Get Stuff Done(tm) and language hackers that are fascinated by Perl’s intricacies.

          As time passed, other languages surpassed Perl in popularity, including in the domains where Perl was traditionally a strong contender (systems administration, web programming). This is just normal language evolution. Every language is not just the code, it’s also the community, and maybe unfortunately for Perl, both subgroups just loooooved writing code that was close to write-only. This made it easy for other language’s boosters to promote their vision instead.

          For example, comparing Python to Perl:

          • Perl: there’s more than one way to it! - Python: <endless fretting about whether a feature is “idiomatic”>
          • Perl: there’s a module for that! - Python: “batteries included”
          • Perl: diffuse bunch of mailing lists drive development - Python: BDFL, numerous PEPs
          • Perl: freedom to write code your way (C, Lisp, whatever) - Python: bondage & discipline

          Seeing this, the language hackers embarked upon Perl6 (now Raku), and in the tradition of grand promises there was to be a shiny new modern Perl in a couple of years, ready to fulfill both group’s needs and leapfrog the competition. But time passed, Raku got more and more complicated and never really got very fast, and the sysadmins decided to continue to work on Perl 5.

          (The recently announced Perl 7 is Perl 5 but with an explicit focus on not retaining absolute backwards compatibility.)

          Perl is only “dead” if you view current TIOBE popularity rankings as proof of life. But Perl is getting relatively (and maybe absolutely) less popular - however, I’d argue that Raku was an attempt to reverse that course, not the cause of the slide.

          1. 3

            I’d argue that Raku was an attempt to reverse that course, not the cause of the slide.

            I’d agree if you mean that renaming “Perl 6” to “Raku” was an attempt to reverse that course. But I believe the spectre of perl 6 being so radically different than perl 5 was a great accelerant of that slide. As someone who used perl 4 and then perl 5 for big ambitious new things (including web apps written against mod_perl because cgi was too slow) the announcement of perl 6 put the brakes on my use of perl starting around 2000 or 2001. I still continued to use it as a nicer shell scripting language after that (and still do today) but I resisted starting anything new in perl 5 that I thought would be large and need maintenance around the time they announced the direction of perl 6.

            I think that split was even worse than python3 because it took so long to take shape.

            1. 2

              Thanks for expanding. I’ve only used Perl 5 for personal projects so don’t really have any insight on how Perl 6 impacted larger projects.

            2. 2

              People stopped writing new code in Perl 5 because it was neither improved nor promoted, and they did not write new code in Perl 6 because it was not ready or usable.

              Therefore “The perl5/6 split killed perl”.

              Renaming Perl 6 to something else came long after this effect had locked in. Sure, no-one is going around erasing old Perl code off of distro CDs. But very few people are writing new Perl code, or replacing old Perl code with new Perl code. If we’re going to argue the semantics then we have to admit that at the very lest Perl smells funny.

              Perl 7 is the right move. It was the right move twenty years ago, it’s the right move now. Hopefully it can be a less painful upgrade than Python 3, which has delivered no benefits to users but created a lot of work for maintainers. Python burnt a lot of goodwill with the upgrade. Perl doesn’t have any to spare after the Perl 6 fiasco.

            3. 1

              Interesting, okay. I’m not at all a Perl person so I didn’t know this (hence “AFAICT” in my parent comment). Thanks for the correction!

              1. 1

                Note that Perl5 itself wasn’t compatible with Perl4. Thus, Perl went through at least one “Python3” moment when people had to adjust their code from 4 to 5 and survived that, presumably because required changes were not that big, and the language still had a momentum.

                1. 1

                  Perl 5.000 was released on October 17, 1994

                  That’s why I don’t buy that comparison. This is not ancient history, but compare the amount of users writing “applications” in Perl 4 in 1994 (deliberately ignoring sysadmins with scripts for now) with the amount of people writing Python 2 code (of all variety, because small scripts were really easy to port from 2 to 3) when Python 3 came out. I have no numbers but I’d be willing to bet it’s orders of magnitude in users, number of projects, and LOC.

                  1. 1

                    But wasn’t the Perl language backwards compatible? I.e. you could keep updating to the latest version of Perl 5, but your ancient Perl 4 scripts still ran.

                    An approach like this really leads to cruft in a language, though.

                    1. 2

                      Not completely compatible, AFAIR. Larry Wall said somewhere that he was happy that the “Black Perl” poem was no longer a valid Perl program, even.

              2. 1

                I would agree but there is not always enough resources to work on the new and the old version simultaneously. I think it’s what’s happened to Perl but Python has managed to avoid.

              3. 8

                It’s very surprising to me that a project would do something like this between versions 7 and 8. Surely they would have built up the muscle memory of “minimize pain in upgrading”.

                Django is my absolute favorite in this space, with a consistent, reasonable strategy that you have almost no excuse not to follow:

                • feature F (in version X) wants to be removed
                • version X+1 marks F as deprecated (and there’s a warning you can enable/cause to error out to catch this in code)
                • version X+2 removes F

                (with even bigger removals happening at X+3 when it seems hard to get the community to fix up everything in time)

                On top of this:

                • deprecations always include documentation saying what your alternatives are
                • in some cases shims are shipped for compatibility (see the Middleware re-architecture) making it easy to port large projects
                • Generally speaking, APIs themselves are still extremely stable. But even for pretty private APIs, Django does this sort of deprecation process because they know some people/plugins will use it for their own reasons

                The biggest difficulty is perhaps when using libraries that aren’t maintained anymore, but porting of those tends to be straightforward.

                1. 3

                  I really appreciate this observation. I’d also add that it feels as if projects that resist big changes build up pressure over time, which leads to a temptation to have the one big release that will “fix all those problems.”

                  A funny thing I noticed on that point: the Yegge post he links to is not quite right about Java. He says that he suspects they only remove APIs that are completely insecure. In fact, there’s been a glacial trickle of removals since Java 9: https://bugs.java.com/bugdatabase/view_bug.do?bug_id=JDK-8204243. However, like Yegge mentioned about his example (Thread.stop()), those APIs have often been deprecated for over a decade.

                  1. 2

                    I like your RPI posts.

                    1. 1


                    2. 1

                      Drupal 8+ feels a bit more of an enterprise framework. That’s great if you are building a big complex monster and have the resources to maintain it. If you don’t have the resources to maintain it and you don’t need the complexity of its architecture/ecosystem then there are other frameworks/cms’s out there that will make your life simpler.

                      1. 0

                        Uh oh… We are doomed with legacy software because we hate when production is down?

                        Let’s embrace (extend extinguish?) the legacy APIs then…