Hacker News Reader

Comment by forgotmypw17 | Hacker News Reader

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.

View on HN

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.

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.

list of perl modules in cpan sorted by last update time

http://www.cpan.org/modules/01modules.mtime.html

My 5 years and counting project diagrees with you.

> 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-... So no, there's been quite a few.

Yes, and these changes are feature flagged and optional and would not affect existing scripts.

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.

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

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?

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.

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.

Java has many other shortcomings which keep me from using it.

python also has this problem

Reply on news.ycombinator.com