[gyulai]

But that's precisely the point: Python 2.5 realized that something was fundamentally broken and the community went through a painful transition process. Transitioning to Python 3 meant getting your house in order where string encodings were concerned.

Any python programmer would tell you: Starting a new project in 2022 in Python 2.5 is professional malpractice.

But that's what the original post seems to be saying: That Perl 5 has somehow managed to fix any of what was fundamentally wrong with it. ...and that couldn't be further from the truth. And people in this thread are saying that maybe they should have another look into Perl 5 as a serious option for starting out a new codebase in 2022. ...and that's a very bad idea.

Sure: If you started out a new codebase in Perl 5 in 2022, there are coding standards you could adopt to avoid getting yourself into a pickle where string encodings are concerned. But without the interpreter helping you out on that front, it'll produce ugly code, and take mental discipline and disciplined code reviewing practices on a team. It's solving a problem that Python solves for you so much more easily and effectively. You could go with Perl 6 / Raku, but why would you? What does it have to recommend it over Python or Ruby, other than a Perl programmer's nostalgia for being a little Perl-like?

You could say the transition from Perl 5 to Perl 6 is just like the transition from Python 2 to Python 3. The difference is: Perl is simply late by at least a decade.

The point that the article is trying to refute, namely that Perl is for dinosaurs, in my mind just absolutely stands.

[wazoox]

> But that's precisely the point: Python 2.5 realized that something was fundamentally broken and the community went through a painful transition process.

It's still not done for many, many projects. "python2" is still installed on 99% of systems I touch. Off the top of my head, the only machine missing it is my laptop, actually.

So your last perl codebase had the choice of not going through this painful transition process. Maybe it's what makes the best sense from a business point-of-view? "Worse is Better", remember, that's why we're running this sloppy Linux everywhere and not the almost-perfect OpenVMS or Genera.

>But without the interpreter helping you out on that front, it'll produce ugly code, and take mental discipline and disciplined code reviewing practices on a team.

"Ugly code" is in the eye of the beholder. For many a python project I'll have to add long series of elif or try/catch to check for the type of some incoming data returned from some API, where it could have been easily managed through duck typing in python 2.7 or Perl. Most programmers won't catch it until the error occurs in production, if the value returned switches types infrequently enough.

> The point that the article is trying to refute, namely that Perl is for dinosaurs, in my mind just absolutely stands.

Try C someday :)

[forgotmypw17]

To me, having to get my "house in order" without asking for it is basically non-consensual changes by the developer, and I think that is abusive.

With humans, my response to abuse is distancing myself from the source of the abuse, and with technologies it is no different.

Python is very popular, and I'm actually learning it right now, but I would not write anything important in it for another 20 years, since they just did ANOTHER breaking change in a minor version release.

[gyulai]

> To me, having to get my "house in order" without asking for it is basically non-consensual changes by the developer, and I think that is abusive.

If you used Python 2 in a way where encoding errors wouldn't be an issue, and if you used the Python 2 to 3 conversion tool that they made when they released Python 3, then in most cases you didn't have to do any work beyond that. ...if however you used the tool and suddenly your code threw exceptions then, more often than not, the errors were errors you needed to fix anyway, even if converting to Python 3 wasn't something you wanted to do. And they gave you 11 years for making the transition between the release of Python 3.0 and the last release of Python 2.7.

I don't agree with that analogy about an abusive relationship. It's more like a five-star restaurant asking you to please put on a shirt if you show up there in a bathing suit. It's just a norm, in this case cultural, that comes with five-star restaurants. If you don't want to follow it, you're free to go find a beach cafe somewhere.

[forgotmypw17]

> It's more like a five-star restaurant asking you to please put on a shirt if you show up there in a bathing suit.

But in this case, the restaurant had previously told me that a bathing suit is OK, and I've been showing up in a bathing suit for years.

They don't owe it to me to accommodate me, but they have just proved themselves unreliable, and I won't be going to that restaurant again, since they ruined my plans for the night.

[otabdeveloper4]

> Transitioning to Python 3 meant getting your house in order where string encodings were concerned.

They renamed "string" to "bytes" and "unicode" to "string".

(And still managed to make file and path encoding broken, and added a few bugs in the process.)

No, nothing about Python 3 is "in order". That was just your Stockholm Syndrome speaking.

[gyulai]

> Renamed "string" to "bytes" and "unicode" to "string".

Either this is hyperbole, or you're quite mistaken on the particulars there.

[otabdeveloper4]

The particulars don't matter here.

P.S. Programming Python since Python 1.3

[gyulai]

...I agree, it's pretty obvious that this thread has gotten to the point where particulars don't matter any more.

As I recall, "bytes" didn't exist in Python 2.5 but were brought in in later versions of Python 2.6 and Python 2.7 when Python 3 already existed to provide a more continuous upgrade path for those still on version 2. You could get in the habit of using "unicode" and "bytes" and then the switch to Python 3 would be this "just renaming" thing. ...but that was the end point of the process, not the starting point.

I'm not an unreflected Python fanboy. I don't like many of the new developments since version 3.5. But I've spent 2003-2018 with Python as my main language, and 2018-2022 being forced to use Perl 5. And that has left me with the impression that Python fixed pretty much all of what was wrong with Perl 5 in a way that the Perl-community itself never managed and doing Perl 5 instead of Python 3 in 2022 is basically all downside, no upside.

I also admire how well the switch from Python 2 to Python 3 was executed, compared to how poorly Perl is doing in the switch to Perl 6.

I predict that the Python community is going to fall apart over the next 10 years over feature creep and losing its identity, trying to be all things to all people, with people subsetting it in different ways to get to a sane subset of the language, similar to how people are doing with C++.