Hacker News new | ask | show | jobs
by shrimpx 993 days ago
> 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.

3 comments

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.

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.
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.

Guess on VM written in which language those LAMP stacks run on?
Sure. The “serious” stuff is written in more serious languages and the rapidly changing experimental stuff in more lenient and expressive languages.