Earlier quoted context omitted.
It’s interesting to me how brains work. Perl has always “flowed” for me and made mostly intuitive sense. Every other language I’ve had to hack on to get something done is a struggle for me to fit into some rigid-feeling mental box. I understand I’m the weird one, but man I miss Perl being an acceptable language to pound out a quick program in between “bash script” and “real developer”.
I wrote a ton of Perl 5 and also found it very intuitive and powerful. I think the notion that Python is "more readable" is true, but also less useful of a metric than it would seem. Python is still gibberish to a new coder and requires training and experience to master. Perl requires somewhat more effort to acclimate to, but ultimately is much more expressive and much closer to real-world software engineering proble…
Perl's decline was cultural
401–410 of 472 posts
Re: Perl's decline was cultural
#402Earlier quoted context omitted.
> what does "else: do after a while loop in python? Only people who know python know what it does (and I suspect most don't). OK, I had never heard of the syntax, but in its own defense it does exactly what you'd guess, the same thing it does after an "if". These are equivalent statements: preloop: if condition: do_more_stuff() goto preloop while condition: do_more_stuff() and these are also equivalent: preloop: if c…
It could've easily been defined that the else branch runs if the while condition never had a true value at all. In fact, I think that's more intuitive.
But here, from the official documentation:
> if the expression is false (which may be the first time it is tested) the suite of the else clause, if present, is executed and the loop terminates.
https://docs.python.org/3/reference/compound_stmts.html#the-...
Re: Perl's decline was cultural
#403Earlier quoted context omitted.
> By comparison, Python can barely go one version without both introducing new things and removing old things from the language Overwhelmingly, what gets removed is from the standard library, and it's extremely old stuff. As recently as 3.11 you could use `distutils` (the predecessor to Setuptools). And in 3.12 you could still use `pipes` (a predecessor to `subprocess` that nobody ever talked about even when `subproc…
> Can you show me a real-world package that was held back because the code needed a feature or semantics from the interpreter That is not what I was getting at. What I was saying is that, if you write code for perl 5.20 and mark it "use 5.20.0;", then that's it, you're done, code never needs to change again. You can bring in newer perl interpreters, you can upgrade, it's almost certainly not going to break. You can e…
They don't guarantee that the entire standard library will be available to you two minor releases hence. Your code will still run if you just vendor those pieces (and thanks to how `sys.path` works, and the fact that the standard library was never namespaced, shadowing the standard library is trivial). And they tell you up front what will be removed. It is not because of a runtime change that anything breaks here.
Python 3 has essentially prevented any risk of semantic changes or syntax errors in older but 3.x-compatible code. That's what the `__future__` system is about. The only future feature that has become mandatory is `generator_stop` since 3.7 (see https://peps.python.org/pep-0479/), which is very much a corner case anyway. In particular, the 3.7-onward annotations system will not become mandatory, because it's being replaced by the 3.14-onward system (https://peps.python.org/pep-0649/). And aside from that again the only issue I'm aware of (or at least can think of at the moment) is the async-keyword one.
> And you don't know what they're going to deprecate or remove until they do it
This is simply untrue. Deprecation plans are discussed in public and now that they've been burned a few times, removal is scheduled up front (although it can happen that someone gives a compelling reason to undo the deprecation).
It's true that you can't make your own code, using the standard library (which is practically impossible to avoid), forwards-compatible to future standard libraries indefinitely. But that's just a matter of what other code you're pulling in, when you didn't write it in the first place. Vendoring is always an option. So are compatibility "forward-ports" like https://github.com/youknowone/python-deadlib. And in practice your users are expecting you to put out updates anyway.
And most of them are expecting to update their local Python installations eventually, because the core Python team won't support those forever, either. If you want to use old FOSS you'll have to accept that support resources are limited. (Not to mention all the other bitrot issues.)
Re: Perl's decline was cultural
#404A good article, but there is nothing new about asynchronous I/O
This is a good article, but Golly, that was a faux pas!
Re: Perl's decline was cultural
#405Re: Perl's decline was cultural
#406> [TIMTOWTDI] literally means 'there is more than one way to do it in Perl' - and you can perhaps infer from that that there's little to no reason to do it using anything else Not my experience at all, FWIW. For me, and the vast majority of Perl devs I’ve worked with over the past 30 years, TIMTOWTDI absolutely means some of the “ways to do it” don’t involve Perl, and that’s not only OK but expected. Of course Perl i…
How popular was/is monkeypatching in Perl?
In tests, you can use monkeypatching as a quick way to mock, but typically, you use modules that wrap up the functionality and make it cleaner. The mocks get cleaned up on scope exit.
There are also more principled ways of having composable behavior, such as https://metacpan.org/pod/Class::Method::Modifiers> (advice/method combination).
There is another approach that takes advantage of the variety of scoping approaches Perl has. If one uses `local`, it indicates the use of dynamic scope rather than the standard `my` lexical scope. This can be used for things like setting an environment variable temporarily and automatically reverting it when leaving the scope. But this is not common.
Re: Perl's decline was cultural
#407Earlier quoted context omitted.
> some kind of inferiority complex meant to preserve the self image Or, as the kids say, a flex, but without the sexy connotations. (Incidentally, I am also reminded of a great quote attributed to Morphy: "The ability to play chess is the sign of a gentleman. The ability to play chess well is the sign of a wasted life.")
That quote is not very convincing to me. Both parts of it are questionable. Just being able to play chess is not a very high bar at all. Most 6-year-olds can learn it in an hour. Are the Chess hustlers at Washington Square Park all Gentlemen? I don't see being able to play Chess well as any kind of deficiency. It could be that it's just someone's hobby. It doesn't have to mean they spiraled into madness, Bobby Fisher…
Re: Perl's decline was cultural
#408This theory may only sound convincing if you ignore parts of history which don't fit. Which is pretty much all of them. RTFM-culture was the norm for all online computer-related communities until 00s. Nothing of this phenomenon is Perl-specific. In late 80s and early 90s professional knowledge was way harder to get. Learning required significant devotion, and often was obtainable through experience only, and at the s…
I remember reading those BOFH stories because I thought it was how you became a cool technical person at the time, but never figured out why he was so angry. Eventually I realized it's because he was Gen X and in academia, so they probably had no money and all had lead poisoning.
Re: Perl's decline was cultural
#409Of course it was cultural. This article covers it all in more detail, but I was coding a lot in this period of Perl's decline, and in hindsight it was all so obvious. I wrote a lot of Perl 3 and Perl 4 to date my experience. Rails was designed to be a luxury hand-holding experience using a language that was intended - as a design goal - to make programming fun. There was even for a while in the late 2000s the culture…
But could a different culture have actually changed Perl to be friendly and fun like Ruby? Without completely torpedoing compatibility with existing code and essentially creating a whole new language anyway? Or did the language itself just get outdated and replaced? (there's nothing wrong with that! most things don't last forever!)
Re: Perl's decline was cultural
#410PHP emerged as a separate language and community and "ate Perl's lunch" when it came to the dominant growing app style of the Aughties... web pages and apps. Had PHP instead been a Rails-like extension of Perl for the web, sigils would have reigned for many years more. But there was never a WordPress, Drupal, or similar in Perl, and no reason for anyone who wasn't already highly connected to the Unix / sysadmin community to really give Perl another look.
By 2005 if you weren't already deep into Perl, you were likely being pulled away to other communities. If you were into Perl, you were constantly lamenting why newbies and web devs weren't using your language, just like the DECUS and VMS crowd did a decade earlier as Unix and Windows consumed all the oxygen and growth opportunities in the room.