5 ms·

> I can be confident that a Perl script I write today will run unaltered 10 years from now, modulo external collaborators. Yeah, because the ecosystem is dead.

> I can be confident that a Perl script I write today will run unaltered 10 years from now, modulo external collaborators. Yeah, because the ecosystem is dead. The flipside is that the bulk of Perl modules available are stale and don't receive any security updates or bug fixes. If I had a pound for every time I've seen a 10+ year old bug with no comments in the CPAN issue tracker... > Perl has a small set of core syntax and is very extensible and flexible in adopting new paradigms. Depends what you call "core syntax". The syntax available to you with a stock Perl install is certainly not small compared to other languages. > With a great amount of discipline, Perl scripts can be successfully scaled up into large, complex systems. If you're disciplined, you can write complex systems pretty much as well as you could in Python or any other dynamically-typed language. However, it requires a lot of discipline and experience, and with other languages you at least have good formatters and LSPs to help with that. Perl sorely lacks this kind of infrastructure. I also think the lack of static types makes writing complex systems massively harder, but that's not a criticism of Perl in particular.

superkuh 3y ago
Perl was lucky that the Perl 6 diversion happened. If it had stayed the course and popularity it would no longer be perl like python is no longer python (such bad version dependency hell there's actually a layer of package manager hell). Now well after the perl 6 diversion Perl 5 activity has come back and there are new features. But most perl devs and the culture still has the habit of writing for portability and stability instead of using incompatible features a month after the compiler/interpreter/etc adds them.
ilyt 3y ago
I dunno, even for maintained ones I've seen far les breakage, whether now or decade ago. It always seemed like default choice for Perl was getting a warning this way of calling something is depreacated, while in Ruby/Python it was "well, we changed our mind on that API, fuck you and your code". The way Py2to3 migration was handled was also some abomination. Meanwhile if I need my Perl code to work like old Perl I just write use v5.10 in header...
- formerly_proven 3y ago
  Had a moment a few days ago with a certain distro not packaging latexmk. Turns out it's a one-file Perl script. It... just works. No dependencies, packaging, deploy process, automation, package hubs, no container with an entire OS, no private runtime, no binaries. Just half a meg of Perl. And it just works, and exactly like it did in the 90s. No fuzz, no bloat. We are completely lost these days when it comes to software.
  - TylerE 3y ago
    Counter argument: It's apparently half a meg of source code to implement a basic build tool. Not impressed.
    - nequo 3y ago
      The file is 10,284 lines long. Less than half of it is actual code. The rest is comments or empty lines. $ cat =latexmk | wc -l 10284 $ cat =latexmk | grep -v '^ *#' | grep -v '^ *$' | wc -l 5982 $ > to implement a basic build tool This basic build tool comes with a man page that is 26.5 thousand words long. Not your typical basic build tool.
- cesarb 3y ago
  > The way Py2to3 migration was handled was also some abomination. Meanwhile if I need my Perl code to work like old Perl I just write use v5.10 in header... To be fair, the way the Perl 5 to Perl 6 migration was handled was worse. It got so bad that they ended up renaming Perl 6 to something else, after it had already been released under the Perl 6 name.
  - ilyt 3y ago
    There was no migration, it was just unfortunately named language
    - theamk 3y ago
activiation 3y ago
> If I had a pound for every time I've seen a 10+ year old bug with no comments in the CPAN issue tracker... That's common in all large active open source project though.. like Firefox, Android, etc...
glintik 3y ago
> However, it requires a lot of discipline and experience That’s true for any platform - Java or PHP. Perl has less support in modern IDE. Perl 5 to 6 transition failed many times so ecosystem lost many talents. P.S. I wrote and supported large Perl codebases, no rocket science to manage it, if you do it right.
ajsnigrutin 3y ago
> Yeah, because the ecosystem is dead. Some of us would call that "mature" or "stable". You don't have to change the basics of the language every two weeks and have people rewrite everything every three weeks (when the three week old version gets removed from ubuntu). Look at LaTeX for example... ever goddamn academic uses latex, but it hasn't really changed for many years now... is it dead? Of course not.
- arp242 3y ago
  I don't think there's any mainstream language where the basics of the language change every two weeks or people have to rewrite things every three weeks. I realize you're exaggerating and that you don't literally means 2 or 3 weeks, but I have Python programs I haven't touched in about 10 years that I still regularly use and that still work fine. Some of my oldest Go programs from over 7 years ago still work fine, and I'm pretty sure that if I were to try running some of my older Ruby or PHP programs (some of which is >10 years old) today it would still work either out of the box or with a few small changes (IIRC some of the defaults in PHP changed wrt. errors, so that might need a little bit of fiddling). Even JavaScript – the poster child of "rewrite every 2 weeks" – is pretty compatible. You don't need to switch to $new_js_framework and many people use older stuff just fine. The language itself is pretty compatible (almost to a fault, arguably).
  - aragilar 3y ago
    I suspect the issue rarely is the language itself changing, but the tooling around it (in the JS case: bundlers, minifiers, polyfills etc.). I think JS/TS the language is good enough, it's really taking the code that's been written and making it usable on the frontend that breaks.
    - arp242 3y ago
      It's certainly the case in JavaScript that the ecosystem has been changing at a very fast pace (too fast, IMO), but you don't need to buy in to all of that.
- 3y ago
Diederich 3y ago
> Yeah, because the ecosystem is dead. Is it? https://metacpan.org/recent https://metacpan.org/recent
- lenkite 3y ago
  Yep - you supplied evidence that its effectively dead. A few rows per day for all modules in the module registry ? Compare that to any other PL in the top 50 and you will have pages per day. For active PL in the top 10, it would be several dozens of pages per day. (For Javascript, it would be several hundred pages per day - buts..lets not talk about JS). Perl is an old geezer hacking out its dying last breaths. Calling it "stable" is fine. Death is a very stable state.
  - Diederich 3y ago
    I'm not going to necessarily disagree with you. Perl was my professional go-to language for about 20 years, and I moved on to Python for the past eight or so. Back 15+ years ago, you'd see perhaps 2-3x more updates on CPAN recents per day than what's there today. I'll always love Perl, but it's definitely on a long slow popular decline.
kamaal 3y ago
>>If you're disciplined, you can write complex systems pretty much as well as you could in Python or any other dynamically-typed language. Python is today's Perl. It ditched the philosophical sermons of simplicity, minimality and all that, for practicality almost 15 years back. Since then, Python 3, has not shown any reluctance to add new syntactical features and sugar. The ecosystem is large. The language is flexible enough today to give Perl like feels from the 1990s and 2000s. Python is no longer big in web dev thanks to React, and its back to being a backend glue language(Java being a language for serious backend enterprise work) with Perl like philosophical leanings. As of today think of Python as a Perl with mandatory tab based formatting.
parasense 3y ago
> I also think the lack of static types makes writing complex systems massively harder, but that's not a criticism of Perl in particular. I get what you're saying, but also that's kind of BS at the same time. If you're thinking Python type annotations are a great feature, then you're entitled to your opinion. Others might say static typing of a dynamic language is pointless, and yet type analysis does help find bugs in code... to which I would agree. And yet the cost of adding static type annotations, which are not very static, causes the cognitive load to increase, and increases line-noise in a very ironic way given how Python was originally parroted as a less obscure script. To that last point, let's not forget about sigils in Perl, and how they sorta are a form of type indicator. There is not much ambiguity when the script uses a symbol out in front of any given type of variable ref. The topic of tokenizing variables/ constants, lists, arrays, hashes, or whatever... entities in a script is an academic topic, but it's not! Just look at GOlang for example, they made a huge mistake by exporting variables and things by using the First character of the object, upper or lowercase determines if that thing is exported. One does not need to go find the declaration of the object to see if there was an "Exported" key word annotated at the definition, as is the custom in Python. But the problem is now the language relies on latin language concepts of upper/lower case characters... which excludes many large spoken & written languages used around the world. Thing any Asian, or middle eastern typeset. Anyhoo, Python got that right... one could in theory write python in one's own native spoken language, and Perl can be written in Klingon if you want... any arbitrary spoken language. One of the reasons is because the sigil's are separate from the typeset, and can be changed. In this way, and many other ways, the pathological pragmatism of Perl is outstanding, and the lack of weird opinions is both a strength and weakness. One last bit about typing, performance, and correctness.... Perl is very fast. I'm always reading how in Python the `for` loop is preferable to the `while` loop because one is implemented in python itself, and the other is a very optimal C code implementation. Perl is optimised at every corner of the language, except modules, but also modules who choose... Python does that too for modules, like any math or data-science stuff. On that last point, I want to throw a bone, and 100% agree most of the Perl libraries for modern practices are out dated, or non-existent, or security problems. A programming language is only as useful as it could be for any given college student to use for a 1st-year software-engineering program. So if the ecosystem is dead, the language is pretty much dead. That said, I know plenty of neck beards who still use IRC, and bang out Perl for quick prototyping... before moving to GO, C, or whatever...

superkuh 3y ago

Perl was lucky that the Perl 6 diversion happened. If it had stayed the course and popularity it would no longer be perl like python is no longer python (such bad version dependency hell there's actually a layer of package manager hell). Now well after the perl 6 diversion Perl 5 activity has come back and there are new features. But most perl devs and the culture still has the habit of writing for portability and stability instead of using incompatible features a month after the compiler/interpreter/etc adds them.

ilyt 3y ago

I dunno, even for maintained ones I've seen far les breakage, whether now or decade ago. It always seemed like default choice for Perl was getting a warning this way of calling something is depreacated, while in Ruby/Python it was "well, we changed our mind on that API, fuck you and your code". The way Py2to3 migration was handled was also some abomination. Meanwhile if I need my Perl code to work like old Perl I just write use v5.10 in header...

formerly_proven 3y ago
Had a moment a few days ago with a certain distro not packaging latexmk. Turns out it's a one-file Perl script. It... just works. No dependencies, packaging, deploy process, automation, package hubs, no container with an entire OS, no private runtime, no binaries. Just half a meg of Perl. And it just works, and exactly like it did in the 90s. No fuzz, no bloat. We are completely lost these days when it comes to software.
- TylerE 3y ago
  Counter argument: It's apparently half a meg of source code to implement a basic build tool. Not impressed.
  - nequo 3y ago
    The file is 10,284 lines long. Less than half of it is actual code. The rest is comments or empty lines. $ cat =latexmk | wc -l 10284 $ cat =latexmk | grep -v '^ *#' | grep -v '^ *$' | wc -l 5982 $ > to implement a basic build tool This basic build tool comes with a man page that is 26.5 thousand words long. Not your typical basic build tool.
cesarb 3y ago
> The way Py2to3 migration was handled was also some abomination. Meanwhile if I need my Perl code to work like old Perl I just write use v5.10 in header... To be fair, the way the Perl 5 to Perl 6 migration was handled was worse. It got so bad that they ended up renaming Perl 6 to something else, after it had already been released under the Perl 6 name.
- ilyt 3y ago
  There was no migration, it was just unfortunately named language
  - theamk 3y ago

activiation 3y ago

> If I had a pound for every time I've seen a 10+ year old bug with no comments in the CPAN issue tracker... That's common in all large active open source project though.. like Firefox, Android, etc...

glintik 3y ago

> However, it requires a lot of discipline and experience That’s true for any platform - Java or PHP. Perl has less support in modern IDE. Perl 5 to 6 transition failed many times so ecosystem lost many talents. P.S. I wrote and supported large Perl codebases, no rocket science to manage it, if you do it right.

ajsnigrutin 3y ago

> Yeah, because the ecosystem is dead. Some of us would call that "mature" or "stable". You don't have to change the basics of the language every two weeks and have people rewrite everything every three weeks (when the three week old version gets removed from ubuntu). Look at LaTeX for example... ever goddamn academic uses latex, but it hasn't really changed for many years now... is it dead? Of course not.

arp242 3y ago
I don't think there's any mainstream language where the basics of the language change every two weeks or people have to rewrite things every three weeks. I realize you're exaggerating and that you don't literally means 2 or 3 weeks, but I have Python programs I haven't touched in about 10 years that I still regularly use and that still work fine. Some of my oldest Go programs from over 7 years ago still work fine, and I'm pretty sure that if I were to try running some of my older Ruby or PHP programs (some of which is >10 years old) today it would still work either out of the box or with a few small changes (IIRC some of the defaults in PHP changed wrt. errors, so that might need a little bit of fiddling). Even JavaScript – the poster child of "rewrite every 2 weeks" – is pretty compatible. You don't need to switch to $new_js_framework and many people use older stuff just fine. The language itself is pretty compatible (almost to a fault, arguably).
- aragilar 3y ago
  I suspect the issue rarely is the language itself changing, but the tooling around it (in the JS case: bundlers, minifiers, polyfills etc.). I think JS/TS the language is good enough, it's really taking the code that's been written and making it usable on the frontend that breaks.
  - arp242 3y ago
    It's certainly the case in JavaScript that the ecosystem has been changing at a very fast pace (too fast, IMO), but you don't need to buy in to all of that.
3y ago

Diederich 3y ago

> Yeah, because the ecosystem is dead. Is it? https://metacpan.org/recent https://metacpan.org/recent

lenkite 3y ago
Yep - you supplied evidence that its effectively dead. A few rows per day for all modules in the module registry ? Compare that to any other PL in the top 50 and you will have pages per day. For active PL in the top 10, it would be several dozens of pages per day. (For Javascript, it would be several hundred pages per day - buts..lets not talk about JS). Perl is an old geezer hacking out its dying last breaths. Calling it "stable" is fine. Death is a very stable state.
- Diederich 3y ago
  I'm not going to necessarily disagree with you. Perl was my professional go-to language for about 20 years, and I moved on to Python for the past eight or so. Back 15+ years ago, you'd see perhaps 2-3x more updates on CPAN recents per day than what's there today. I'll always love Perl, but it's definitely on a long slow popular decline.

kamaal 3y ago

>>If you're disciplined, you can write complex systems pretty much as well as you could in Python or any other dynamically-typed language. Python is today's Perl. It ditched the philosophical sermons of simplicity, minimality and all that, for practicality almost 15 years back. Since then, Python 3, has not shown any reluctance to add new syntactical features and sugar. The ecosystem is large. The language is flexible enough today to give Perl like feels from the 1990s and 2000s. Python is no longer big in web dev thanks to React, and its back to being a backend glue language(Java being a language for serious backend enterprise work) with Perl like philosophical leanings. As of today think of Python as a Perl with mandatory tab based formatting.

parasense 3y ago

> I also think the lack of static types makes writing complex systems massively harder, but that's not a criticism of Perl in particular. I get what you're saying, but also that's kind of BS at the same time. If you're thinking Python type annotations are a great feature, then you're entitled to your opinion. Others might say static typing of a dynamic language is pointless, and yet type analysis does help find bugs in code... to which I would agree. And yet the cost of adding static type annotations, which are not very static, causes the cognitive load to increase, and increases line-noise in a very ironic way given how Python was originally parroted as a less obscure script. To that last point, let's not forget about sigils in Perl, and how they sorta are a form of type indicator. There is not much ambiguity when the script uses a symbol out in front of any given type of variable ref. The topic of tokenizing variables/ constants, lists, arrays, hashes, or whatever... entities in a script is an academic topic, but it's not! Just look at GOlang for example, they made a huge mistake by exporting variables and things by using the First character of the object, upper or lowercase determines if that thing is exported. One does not need to go find the declaration of the object to see if there was an "Exported" key word annotated at the definition, as is the custom in Python. But the problem is now the language relies on latin language concepts of upper/lower case characters... which excludes many large spoken & written languages used around the world. Thing any Asian, or middle eastern typeset. Anyhoo, Python got that right... one could in theory write python in one's own native spoken language, and Perl can be written in Klingon if you want... any arbitrary spoken language. One of the reasons is because the sigil's are separate from the typeset, and can be changed. In this way, and many other ways, the pathological pragmatism of Perl is outstanding, and the lack of weird opinions is both a strength and weakness. One last bit about typing, performance, and correctness.... Perl is very fast. I'm always reading how in Python the `for` loop is preferable to the `while` loop because one is implemented in python itself, and the other is a very optimal C code implementation. Perl is optimised at every corner of the language, except modules, but also modules who choose... Python does that too for modules, like any math or data-science stuff. On that last point, I want to throw a bone, and 100% agree most of the Perl libraries for modern practices are out dated, or non-existent, or security problems. A programming language is only as useful as it could be for any given college student to use for a 1st-year software-engineering program. So if the ecosystem is dead, the language is pretty much dead. That said, I know plenty of neck beards who still use IRC, and bang out Perl for quick prototyping... before moving to GO, C, or whatever...