Perl: 37 years old
Python: 34 years old
@siracusa While this is true, Python as it exists today is newer, and most developers are using packages and constructs that are a lot newer than 34 years old (numpy, pandas, pytorch). Perl wasted a lot of time inventing a completely different language, which was a dead end. Perl was great for writing quick and dirty scripts for simple text processing tasks, but horrible and unmaintainable for anything large.
@not2b As someone who spent 25 years writing large, maintainable things in Perl, I have to disagree.
@siracusa You must have more discipline than I did; reading and understanding Perl code was always much more difficult for me than Python, even though I learned Perl first (including earlier versions; I first downloaded Perl from Usenet back in the 80s).

@not2b @siracusa I wrote Perl for 13 years. I learned discipline. If you treated your code as more than a disposable one-off, you made it readable, converted the punctuation salad into verbose equivalents. By the time I stopped using Perl, I had a toolchain and project initiation process that was easy to set up and made testing and packaging effortless.

Trying to do the same in Python has basically been a nightmare. Just a swirling vortex of endless infrastructure, churn for the sake of churn.

@arclight @not2b @siracusa

Churn for the sake of churn has been my impression of Python as well, although I haven't used it as much recently. The new versions seem to break old libraries, and the libraries are a big part of why people chose to use Python in the first place.

For new scripts I'm planning to stick to using Rust, it's not *that* different from Python, even if its more wordy, but it is much faster and the compiler is very friendly when reporting issues. Plus the skills are transferable and the language is backwards compatible. I've had some success with this policy and I plan to keep pursuing it.

@not2b @siracusa "You must have more discipline than I did"

In the end, #Perl turned out to make it easier to identify developers that don't bother with good programming discipline!

#toolblamer 😆

@not2b @siracusa

Python as it exists today is newer, and most developers are using packages and constructs that are a lot newer than 34 years old (numpy, pandas, pytorch).

I'll give you PyTorch (9 years old), but Pandas is 17 years old and NumPy 19 (or 30 if you count its predecessor, Numeric). If "a lot newer" means "created within the last 20 years", then I could make a similar argument for Perl.

Today's Perl developers use newer packages (Moose is 19 years old, Moo 15, Mojolicious also 15, Path::Tiny 12) and constructs (state is 18 years old, /r 14, lexical subroutines 12, function signatures 11, class 2 years, etc).

The difference is that (unlike Python) a lot of that 30 year old code still works unchanged with current Perl.

Perl wasted a lot of time inventing a completely different language, which was a dead end.

Not sure what you're referring to here. If you mean Raku, that's still a thing: https://raku.org/

Raku®

The Raku® programming language.

@barubary @not2b @siracusa

Python got dataclass quite recently for features that were previously available in the attrs library

https://blog.glyph.im/2016/08/attrs.html

...

But both of those still pale in comparison to Moose ... and even then, the Python versions feel bolted on because of Python's inflexibility. It's hard to convey when just programming-in-the-small.

The One Python Library Everyone Needs

Use attrs. Use it. Use it for everything.