undefined | Better HN

0 pointspansa25y ago0 comments

> Statically typed languages create a lot of complexity from being entirely dependent on types being correct in a static sense rather than at runtime.

Python’s type annotations aren’t checked at runtime, though - they’re also entirely static. So you either have to:

- Write code that’s as pedantically correct as in a traditional statically-typed language (e.g. by using `mypy —-strict`), in which case you’d be better off using a language that supports AOT-compilation, or

- Be prepared for cases where the runtime type doesn’t match the annotation. This is unacceptable - I hate the idea of code that tells lies.

0 comments

3 comments · 1 top-level

gypsyharlot5y ago· 2 in thread

You're entirely forgetting the benefits.

1) Scientists, hobbyists etc. can be super productive with Python while disregarding types.

2) Software developers can write serious applications with type checking.

Statically typed languages exclude group that benefit from 1).

pansa2OP5y ago

A language that tries to satisfy both of these groups won’t be ideal for either of them.

Python should aim to be perfect for group 1. There are many other languages that will always be a better choice for group 2.

gypsyharlot5y ago

I disagree. You can spend 90% of your time doing e.g. data science, and then one day you need to integrate with a DB or make a cross-platform desktop GUI application, as an example. Should you learn C++ (it takes a decade to become a very mediocre C++-developer), or Java to write a desktop GUI application?

No, there isn't "always" a better choice for group 2.

- Most software isn't CPU bound, so that defies "always" in your argument

- You need libraries get things done

What language would you always pick for group 2? Or would you pick a different one for each task, spending an order of magnitude more time learning them?

j / k navigate · click thread line to collapse