Perl's decline was cultural

I never interacted with the "Perl community" described here. When I used Perl in a past job it was in the "just google for how to do things" era.

The syntax, full of @ and %, was convoluted and made you have to think about more things compared to Ruby or Python without giving you that much apparent power or benefit (as opposed to when you'd need to think about types more in Java or a C-family language).

Neither Ruby, Python, nor Perl were in my first three languages (Pascal, C/C++, Java were those). Ruby, Python, Matlab, R, and Perl all came later for me, within a few years of each other. Perl did not have anything like the approachability of Ruby and Python coming from that Pascal/C/Java background.

(IMO Python is losing some of that now, especially like in the last project I encountered in a professional capacity in Python where optional type hinting was used but wasn't always accurate which was a special sort of hell.)

EDIT: the article even touches on this some in its description of Ruby: "Ruby is a language for programmers, and is at this point an sensible candidate for building something like Rails with - a relatively blank canvas for dynamic programming, with many of the same qualities as Perl, with less legacy cruft, and more modern niceties, like an integrated object system, exceptions, straightforward data structures." Ruby was newer, and wasn't something that grew out of sysadmin tools, but was always a full fledged OO application programming language first. So my disagreement with the article is that the culture then doesn't matter because no perl culture changes would've been able to reinvent the language as a nicer, newer language like Ruby because it never would've been perl anymore at that point.

> the last project I encountered in a professional capacity in Python where optional type hinting was used but wasn't always accurate which was a special sort of hell.

But that's the entire purpose of optional type hinting. If the hints had to be accurate, you'd have mandatory typing, not optional hinting.

I think the purpose of optional type hinting is that you don't have to add it everywhere all at once, not that it doesn't have to be accurate. I guess you could split hairs and say "hint" doesn't imply perfect accuracy, but... adding a language feature that can lie really seems to have a lot of downsides vs upsides; whereas at least optional has obvious migration benefits.

You could have optional type hints where the runtime would still yell at you - maybe even from just an optional flag - if you returned a string out of a function that should return an int.

Because as-is, once you have those function that says it returns an int but returns a string instead, etc, in a big codebase, your editor tooling gets really confused and it's way worse to work through than if the hints weren't there at all.

(And there are tools in Python that you can use to inspect and verify the accuracy. But those tools are also... optional... And if you start to apply them to a codebase where they weren't used, it can be very time-consuming to fix everything...)

> And there are tools in Python that you can use to inspect and verify the accuracy. But those tools are also... optional... And if you start to apply them to a codebase where they weren't used, it can be very time-consuming to fix everything...

How is that "bad" solution different from this "good" one?

> You could have optional type hints where the runtime would still yell at you - maybe even from just an optional flag - if you returned a string out of a function that should return an int.

No, optional type hinting means there's sometimes not a hint. Having a hint and then passing some type that's not that is wrong and hell.

You are talking about misleading type hints, not optional ones. Optional means they don’t have to be added. Wrong typehints are so much worse than missing ones.

If it's built in to the runtime you get a lot of potential benefits:

- you don't need to install additional packages

- you could have (because you don't want to hurt prod perf by checking all the time) dev-mode with warnings by default on execution and a prod-mode where they're ignored

- you can then have people in the dev environment catching things as they write/run/test their code vs only whenever they run the third party tool (which it seems a lot of people don't set up for even run-on-every-commit)

Let's flip the question around! What do you think are the benefits to making it easy to add misleading incorrect type hints?

Python's type hinting is horrible.

It's not checked, it's not required, and the bolted on syntax is ugly.

Even if the types were checked, they'd still fail at runtime and some code paths wouldn't get exercised.

We need a family of "near-scripting" languages like Go that check everything AOT, but that can be interpreted.

> It's not checked, it's not required,

It is both of those if you use a typechecker, which is the whole reason it exists (in fact, the first popular typechecker existed before the annotation syntax using type comments; type annotations were developed specifically so that it could be accommodated in the language rather than becoming its own separate language.)

That's the problem! The code should not run if the types are wrong. Having an external tool is an antipattern.

Having to rely on process for validity is a recipe for bad. We already know how the greater python community has been with requirements.txt and dependencies. I've spent days fixing this garbage.

It's a tooling problem. Good tools make good habits part of the automation and stop you from having to think about it.