[winter_blue]

> be able to actually figure out what data to send libraries without actually reading their source code

Just reading this sent a chill down my spine. I have horrible memories of having to read the code to figure out what something was doing (in JavaScript, Python, Ruby, etc), due to the disaster of an anti-feature called dynamic typing having been used.

[shrimpx]

> disaster of an anti-feature

Untyped languages tend to be at the forefront of paradigms, and typed languages come in toward the end when reliability and need for tooling are more important than innovation/discovery.

In the 90s a bunch of kids were building websites with LAMP stacks while serious engineers were building aging/about-to-be-irrelevant desktop software in serious, typed languages.

[blacklight]

I love Python, but I also love the ability to tell what is what.

I kickstarted a project in Python a decade ago that was wild on dynamic typing. As it passed a critical threshold of ~10k LoC, it became nearly ummaintainable.

What's that `response` passed here? A verbatim response object from `requests`? A proxy mapping? Bytes? A JSON string? If so, a list or a dict? And what fields are inside?

Multiply it by tens or hundreds of methods and classes, and it's easy to see why projects based on purely dynamic patterns fail to scale.

By now I have almost completely rewritten that project to use type hints everywhere I could. And guess what? In 95% of the cases I knew exactly what was being passed - or the choice was about 2-3 types at most, so a Union sufficed.

Yes, there's a 5% of cases where Python's dynamic typing features are a blessing. The power of meta programming in Python is often underestimated. Reflection is amazingly intuitive compared to the patchwork mess of Java, Kotlin and friends. Everything can be mocked without hassle and boilerplate. And duck typing can really be useful sometimes.

But, again, in an average project I wouldn't expect code that benefits from these features to make up more than 5-10% of the codebase.

For everything else, just do yourself, your future self and anyone who will work on your code a favour, and use type hints.

[shrimpx]

I agree. And what makes python a nice choice for this is that you can go wild in the beginning and then gradually add type hints as your project takes shape.

[winter_blue]

Statically typed languages in the 90s had a reputation for being verbose (like Java’s Cat = new Cat()), or difficult to work with (like C’s manual memory management). Haskell and other ML family languages hadn’t quite gotten that popular. Type inference wasn’t a feature in many popular statically typed languages until recently. And type inference makes static typing significantly easier.

The P in the LAMP stack is still a bit of a mystery to me. It could (one could wish) have been Haskell instead, but oh well.

[wiseowise]

Guess on VM written in which language those LAMP stacks run on?

[shrimpx]

Sure. The “serious” stuff is written in more serious languages and the rapidly changing experimental stuff in more lenient and expressive languages.

[goatlover]

It's not an anti-feature. Those languages gained popularity in part because they were dynamically typed. But this debate is decades old and people always dogmatically choose one side, so not really any point in trying to convince you. Alan Kay made the argument back in the 1970s that type systems were always too limiting, therefore classes and late binding were the answer for him.

[winter_blue]

I’m speaking from my real-life lived experience with dynamic typing. I feel that dynamic typing is truly harmful for any project that involves involving complex logic, needs collaboration / where there’s more than 1 person working on it, or even for any large project (even if only 1 person is working on it).

It was a massive waste of time to have to read piles of code code, use a debugger and inspect object structure, to understand how some parts of certain large codebases worked.

In my experience, dynamic typing has simply been horrible for team collaboration, code readability (and ease of understanding), and it results in a large number of bugs that could easily have been eliminated with static type checking.

> But this debate is decades old and people always dogmatically choose one side, so not really any point in trying to convince you.

You’re right about that. I am indeed very dogmatic and take a hard-line on this. I take a stronger position on this than most things (for example: something very subjective like curly braces versus white space indentation), to the point that I’ll say this: dynamic typing is simply a wrong and bad engineering decision.

Another example of a bad language design decision is allowing null to be a part of every type instead of requiring an explicit ? in the type, or the use of an Optional wrapper. This has been recognized as an ill, andis something many modern languages (to name a few: Rust, Kotlin, etc) fixes.

But that isn’t meant to level a personal attack against the languages designers of the past (or to say that they were stupid). Allowing every type to be Union[T, null] was a simply a language design mistake (that potentially cost wasted billions of dollars), but it's been recognized as a mistake today that we need to rectify and move forward from (as is reflected by decision made by more recent languages).

However, imo, in comparison, dynamic typing is a 100 times worse than not having null safety (or not having memory safety like C or C++). I can work with a C or C++ without much trouble, but not with dynamic typing. Dynamic typing makes it difficult and unpleasant to work with a large codebase, to an inexcusable degree.

[schrodingerscow]

Ha you sound exactly like my own consciousness. There are few things in life I feel as resolute about than this one. Dynamic types were a mistake. Let’s learn and move on. I often joke that if null pointer references were the billion dollar mistake (or whatever it’s called), dynamic typing was the 100 billion dollar mistake. And we’re still living with it but thank god for typescript etc for saving us finally

[winter_blue]

Thanks. Yeah, I agree.

[seunosewa]

But third party code in Python was easy to read.