zlacker

[return to "What Killed Perl?"]
1. orev+kg1[view] [source] 2025-11-19 18:08:42
>>speckx+(OP)
The backwards incompatibility of Perl 6 absolutely killed Perl.

There are many languages still in use today that have all kinds of warts and ugliness, but they remain in use because they still have momentum and lots of legacy things built in them. So being ugly or old isn’t enough of a factor for people to abandon something in droves.

Once you need to rewrite everything, there’s no reason to stay with something you know since you need to fully retool anyway.

As a Perl programmer since v5 was released, the confusion around 6 completely destroyed almost everyone’s enthusiasm, and immediately caused all new projects to avoid Perl. It seemed like 5 had reached the end of the line, and 6 was nowhere to be found. Nobody wants to gamble so many hours of their lives, and the future of their business, on such an uncertain environment.

If Perl 6 had any visible movement within the first few years, it might have survived, but it was a good decade before they even admitted Perl 6 might take longer than expected, and then more time after that before they admitted it should have been a new language. 6 was interesting for language geeks, and they probably did some cool things, but you can’t run a large popular project like it’s a small research project. That completely destroyed all momentum in the community. Perl 5 development only resumed far too late, after the writing was already on the wall.

Both Bill Gates and Linus understand backwards compatibility as a sacrosanct principle. Python only just barely survived the jump from 2 to 3. JavaScript can only survive this because there’s no other option in a browser.

◧◩
2. kaashi+5o1[view] [source] 2025-11-19 18:37:30
>>orev+kg1
> Python only just barely survived the jump from 2 to 3.

I really don't think this is true at all.

Python 2 to 3 took a really long time, it was a real struggle, lots of people stayed on 2 for a really long time.

But I really don't think Python was close to dying the same way Perl has/is. There was no risk of Python not "surviving" in my opinion.

There was always a clear way forward and people were actually moving. The mass migration of millions or billions of lines of code from 2 to 3 actually happened and has many high profile million+ line migrations, like Yelp or Dropbox.

There was never anything similar for Perl 5 to 6, totally different situation.

◧◩◪
3. foofoo+Dw1[view] [source] 2025-11-19 19:16:21
>>kaashi+5o1
> I really don't think Python was close to dying

It absolutely was. What saved it was:

1. The data science / AI crowd that was gathering momentum any many only used Python 3.

2. No popular alternative. Perl got python as an alternative.

Python was also a good, simple language and had a good healthy culture. But it's nothing sort of a miracle that it survived that biblical software calamity.

◧◩◪◨
4. matthe+lK1[view] [source] 2025-11-19 20:23:11
>>foofoo+Dw1
You forgot perhaps the most important one:

3. six

`six` was instrumental in repairing the Python schism by giving people a way to incrementally move their 2.7 code to Python 3, and write code that was compatible in both. The six project didn't exist at first and the path to Python 3 was too painful without it. Six solved all that by smoothing over built-in libraries with different casing between versions, incompatible core libraries, the addition of unicode strings, print changing to a function, etc, etc. Perl 5 to Perl 6 (aka Raku) never got that.

◧◩◪◨⬒
5. maskli+dU1[view] [source] 2025-11-19 21:10:01
>>matthe+lK1
Six was one component but not the only one. Python 2.7 also backported a number of early Python 3 features, Python 2 features were reintroduced in basically every P3 version until at least 3.5 (although after 3.3 they were pretty minor), and a lot of extensive migration guides were written (my main bible was eevee's).

In my experience, six was a relatively minor part, and you could get by with your own little compat file for just the stuff you needed, even on relatively big projects. I even found it beneficial to do so because instead of just slapping six.moves everywhere you'd have to re-evaluate some of the old decisions (e.g. at $dayjob at the time we were using all of urllib, urllib2, and requests for HTTP calls, not using six provided strong motivation to just move everything to requests). This also made for a lot less churn when removing Python 2 compatibility.

[go to top]