Yep. Everything comes in cycles, old becomes new again, etc. This is particularly true in the software industry. We're very fad-driven.

Is this the case here too though? My impression was that dynamic languages grew popular because of deficiencies in static type systems, making it hard to express things while requiring a lot of boilerplate and not providing enough runtime safety (e.g. NullPointerException), and a faster feedback cycle, as you need a compile step and need the entire program to be free of type errors. For the first point, type systems have been improving in these regards, and for the second you get instant feedback in statically typed languages without needing to even run anything. Some languages like Roc even let you run code while there are type errors in other code paths.

> Is this the case here too though?

I have no working crystal ball, so I don't know. But I don't see any obvious reason to think it isn't.

If history is any guide, then this is just the latest cycle, and the new hotness will become dynamic again.

Your list of improvements is correct, but I'll just point out that with every cycle, a similar list of improvements is cited as the reason why whatever the fashion of the day is will become The One True Way. So far, such expectations have never been fulfilled.

Counterexamples: structured programming, version control, null safety, unicode. I don't think we're going backwards on those.

Regardless of the cycles in the computer industry, I would never consider a dynamically typed language for large projects ever again.

I’ve been there, done that, and worked most of my career in dynamic languages. There’s just better tools available today. There’s no going back for me.

Python with types or TypeScript is as dynamic as I’m willing to go now, and only as a last resort.

I've personally found that Python with types is just not quite enough if I have to work with other people.

I’ve also found it insufficient. I’d much rather have a stronger type system.

Yup, it can really suck, this working other people thing.

But can you elaborate or provide some examples, please? I'd like to know more about this angle.

My guess is he’s referring to the way that types are fundamentally optional no-op statements in python, and therefore the level of “typing” in a given project is necessarily opinion-driven and can only be enforced through building up a lot of tooling, like making sure a type checker passes or fails all code going into deployment or CI. And even in the best case, types are duct-taped on, so there is no such thing as “perfectly type-safe”

So as soon as you have two developers on one project, you have two different opinions about it.

I think eventually students will be taught the "classics".

Today's best practice is tomorrow's worst practice.

I think the article argues for "gradual typing" being somewhere in between but being strictly superior to dynamic typing, to the extent that we may never see the pendulum swing back to purely dynamic typing again. (It is my view that obviously static types aren't going anywhere, and that obviously the pendulum will continue to swing back and forth there; I don't think the article contradicts that either.)

is there a correlation to "the economy" and the trend du jour?

seems "safe" would go over better in recession times, while "productivity" is just a nicer way of saying "move fast"