[rurban]

Nonsense. You get the simplification and faster development times of knowing some variable types statically, plus the performance improvements for the compiler which can move the type checks from runtime to compile-time. Plus all the new optimization possibilities.

Common Lisp showed you the way. But almost none looked at it. Only PHP did.

[ReflectedImage]

Absolutely not. Duck type based development results in working code out of the door 3x faster than static type based development. It always has since ancient times.

If performance wasn't an issue, then the static type based developers would all be fired. Either directly or by the businesses who relied on them getting driven into bankruptcy by their competitors. You would still get some niche jobs in it where they like to do formal verification of the code.

Your problem is just that your development skills from static type based development don't transfer to duck type based development. Different style of codebases needs to be handed completely differently.

[rurban]

I am talking about gradual typing here. Types are optional, if not given or implied they default to any. No need to annotate anything. If given they are enforced, and lead to optimized op codes and errors if violated. Some at compile-time, some at run-time. If fully typed, all errors are caught at compile-time already.

Duck typing as done with python is the worst of both worlds. No optimizations, no enforcement. Just optional external typechecks.

Of course untyped code (ie runtime types in each var) is to write faster. You only need to add types to some vars or args, and gradually improve from there. Eg ints only, because they are optimized the easiest. No need to check for strings, bigint, floats,.... Or arrays to check for overflows at compile-time and restrict to ints or strings. Massive improvements possible, in size and runtime.

Or object fields. Hash lookups vs static offsets.

[ReflectedImage]

If JITs hadn't been invented you would be completely right but JITs have been invented.

There are deeper optimizations that JITs can do such as knowing at runtime that the value of a variable is always 2 that typing information simply can't express.

Duck typed Python is optimal for development speeds, the only thing that matters in startup environments. It has it's niche.

You aren't gradually improving, you are gradually deteriorating the codebase to make it look more familar to you.

[dajonker]

At least CPython and CRuby (MRI), the most common implementations of each language, ignore all type hints and they are not able to use them for anything during compile or runtime. So the performance argument is complete nonsense for at least these two languages.

Both Python and Ruby (the languages themselves) only specify the type hint syntax, but neither specifies anything about checking the actual types. That exercise is left for the implementations of third party type checkers.

[rurban]

Because the anti-types crew showed up and sabotaged it. Similar with perl and lua.

But languages with stronger and more intelligent leadership showed what's possible.

You cannot implement all the compiler optimizations for const and types in extensions. You need to fork it.

[ReflectedImage]

The problem is there are a lot of developers who have only coded with static typing and have no idea about the terrible drawbacks of static typing.

They don't understand what static typing does to code verbosity and development times.

Take Turborepo going from Go's typing light system (designed to emulate duck typing) to Rust's heavy typing system (true static typing). Originally the code was 20,000 lines and was coded by 1 developer in 3 months. When moved into the typing style you like so much, the same code is now 80,000 lines and was coded by a team of developers in 14 months.