Live data from Hacker News

Perl's decline was cultural

beatworm.co.uk

401–410 of 472 posts

Re: Perl's decline was cultural

#401
post #382
post #126

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…

For me it's not so much that Python was more "readable" than Perl. I've found pretty much any language other than XSLT more readable than Perl.

Re: Perl's decline was cultural

#402

Earlier 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.

What are you trying to say? It is defined that way. And the example I provided above makes that completely explicit.

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

#403
post #64

Earlier 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…

> Compared to Python's deliberate policy, which is they won't guarantee your code will still run after two minor releases

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

#404
> Any requirements for more modern application patterns that are emerging in the broader web development environment, like idk.... asynchronous I/O,

A 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

#405
Perl was a bad language, line noise. It was better than using bash and awk for complex scripting, and better than using C for CGI pages. But Python and PHP were better and more readable for those use cases, and killed Perl.

Re: 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?

It is possible to do so, but it stands out in a way such that most people aren't doing it using direct language features unless necessary. If you have `strict` and `warnings` enabled, which is recommended, then the interpreter can give runtime warnings or compile-time errors if you try to manipulate the symbol table or redefine a function. If you still want to use those on a case-by-case basis, you have to turn off those pragmas within a scope. So there are built-in ways the language discourages using them arbitrarily.

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

#407

Earlier 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…

Morphy, who is probably the greatest chess player to ever live, would probably know.

Re: Perl's decline was cultural

#408

This 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 Perl programmers as being weird but nice enough. It's Lisp programmers who were impossible to talk to and mostly responded to any questions by telling you to kill yourself.

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

#409

Of 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!)

I feel like I grokked Perl enough and I still write Perl code, but I also think that there are some technical reasons why it declined in popularity in the 2000s and 2010s. All those differences between $ % @, the idea of scalar or list context, overuse of globals, and references. These features can all make sense if you spend enough time in Perl, and can even be defended, but it creates a never-ending stream of code that looks right but is wrong, and it all seems to create a lot of complexity with very little benefit.

Re: Perl's decline was cultural

#410
Perl's decline was cultural in the same way VMS's decline was. A fantastic approach and ecosystem—just one overtaken by a world that was moving on to a different set of desires and values.

PHP 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.

Post reply on HN