4 ms·

I chose to build in Perl because of its ubiquity and committment to backwards compatibility. I was extremely frustrated with existing projects having dependenc

I chose to build in Perl because of its ubiquity and committment to backwards compatibility. I was extremely frustrated with existing projects having dependency issues and frequent breakage and wanted to avoid that at all costs. Perl's flexibility has allowed me to develop my own coding style, which is basically Java-like, and I rarely have trouble figuring out what something does, even months later. I think Perl is vastly underrated as a language, and its suffers from repeat-speak of people who have only seen poorly written Perl or have never seen a well-managed Perl project. One of my favorite things about Perl is that there are 20 years of code samples on the Web for it and they ALL WORK because Perl has not introduced breaking changes since 5.000.

xupybd 4y ago
I found Perl suffered from dependency issues as well. Not the language but the modules you tend to want to use. Especially when they're underpinned by c libraries. I'd preference operating system libraries then fall back to Cpan. Over time it got harder to maintain older applications as the libraries dropped out of repositories. Have you found anything similar?
- forgotmypw17 4y ago
  You're right, and this is why I don't use third-party modules. If I need something I can't write myself, I use the shell version instead of a module.
  - scoopertrooper 4y ago
    Seems like you're jumping through a like of hoops to write thing in a Java-like fashion when you could be using Java, which has a much healthier ecosystem.
    - forgotmypw17 4y ago
      Java has many other shortcomings which keep me from using it.
- readme 4y ago
  python also has this problem
viraptor 4y ago
> because Perl has not introduced breaking changes since 5.000. I was curious and you made me check. There's a number of releases with incompatible changes listed if you google for it. For example a whole list at https://perldoc.perl.org/5.12.0/perldelta#Other-potentially-incompatible-changes https://perldoc.perl.org/5.12.0/perldelta#Other-potentially-... So no, there's been quite a few.
- forgotmypw17 4y ago
  Yes, and these changes are feature flagged and optional and would not affect existing scripts.
  - MrJohz 4y ago
    No, those are "real" breaking changes in that a script running in one version of the interpreter could break if it runs in a later version, without any modifications to the script itself. But in fairness, they're a very conservative definition of breaking changes - e.g. the output of the `--version` flag changing, or some Unicode characters classes changing.
- doomvox 4y ago
  > no, there's been quite a few. Yes, most of them relatively minor though, which is why the OP has never stumbled across one. (I found one once-- it turned out one coder had invented his own hash slice syntax. It wasn't supposed to work, but it did, until a particular upgrade...). In general, Perl has been traditionally committed to backwards compatibility, but not fanatically so-- there is a deprecation cycle that can be used to remove the more problematic things.
dale_glass 4y ago
Unfortunately most of that doesn't really matter for any non-trivial project, because you'll almost unavoidably need a module for something. A lot of the time you'll find out that it's bit rotted 5 years ago, and the bug tracker has a 7 year old issue nobody seems to have read. It's even worse for anything that interacts with libraries or APIs -- those change over time, and often nobody does the work to repair compatibility. So I think at this point it's fair to say it's dead. Even if the core language is technically functional, the ecosystem is rotting.
- jart 4y ago
  Perl doesn't need an ecosystem any more than the Almquist shell does. It's just a nice tool that's omnipresent on UNIX systems. It's definitely going to be useful for shell scripters for a very long time.
- readme 4y ago
  list of perl modules in cpan sorted by last update time http://www.cpan.org/modules/01modules.mtime.html http://www.cpan.org/modules/01modules.mtime.html
- forgotmypw17 4y ago
  My 5 years and counting project diagrees with you.

xupybd 4y ago

I found Perl suffered from dependency issues as well. Not the language but the modules you tend to want to use. Especially when they're underpinned by c libraries. I'd preference operating system libraries then fall back to Cpan. Over time it got harder to maintain older applications as the libraries dropped out of repositories. Have you found anything similar?

forgotmypw17 4y ago
You're right, and this is why I don't use third-party modules. If I need something I can't write myself, I use the shell version instead of a module.
- scoopertrooper 4y ago
  Seems like you're jumping through a like of hoops to write thing in a Java-like fashion when you could be using Java, which has a much healthier ecosystem.
  - forgotmypw17 4y ago
    Java has many other shortcomings which keep me from using it.
readme 4y ago
python also has this problem

viraptor 4y ago

> because Perl has not introduced breaking changes since 5.000. I was curious and you made me check. There's a number of releases with incompatible changes listed if you google for it. For example a whole list at https://perldoc.perl.org/5.12.0/perldelta#Other-potentially-incompatible-changes https://perldoc.perl.org/5.12.0/perldelta#Other-potentially-... So no, there's been quite a few.

forgotmypw17 4y ago
Yes, and these changes are feature flagged and optional and would not affect existing scripts.
- MrJohz 4y ago
  No, those are "real" breaking changes in that a script running in one version of the interpreter could break if it runs in a later version, without any modifications to the script itself. But in fairness, they're a very conservative definition of breaking changes - e.g. the output of the `--version` flag changing, or some Unicode characters classes changing.
doomvox 4y ago
> no, there's been quite a few. Yes, most of them relatively minor though, which is why the OP has never stumbled across one. (I found one once-- it turned out one coder had invented his own hash slice syntax. It wasn't supposed to work, but it did, until a particular upgrade...). In general, Perl has been traditionally committed to backwards compatibility, but not fanatically so-- there is a deprecation cycle that can be used to remove the more problematic things.

dale_glass 4y ago

Unfortunately most of that doesn't really matter for any non-trivial project, because you'll almost unavoidably need a module for something. A lot of the time you'll find out that it's bit rotted 5 years ago, and the bug tracker has a 7 year old issue nobody seems to have read. It's even worse for anything that interacts with libraries or APIs -- those change over time, and often nobody does the work to repair compatibility. So I think at this point it's fair to say it's dead. Even if the core language is technically functional, the ecosystem is rotting.

jart 4y ago
Perl doesn't need an ecosystem any more than the Almquist shell does. It's just a nice tool that's omnipresent on UNIX systems. It's definitely going to be useful for shell scripters for a very long time.
readme 4y ago
list of perl modules in cpan sorted by last update time http://www.cpan.org/modules/01modules.mtime.html http://www.cpan.org/modules/01modules.mtime.html
forgotmypw17 4y ago
My 5 years and counting project diagrees with you.