I've written maybe a couple thousand lines of TypeScript. I'm an utter neophyte there. I didn't hate the experience, though.
I've written maybe a few hundred thousand lines of Python. I didn't use type annotations until recently because they didn't exist. My first forays into playing with them were painful: it revealed a whole lot of unfound bugs in my code. In most cases they were minor and probably wouldn't have caused a real-life problem. Fixing them was often challenging because changing a function frequently meant breaking an internal API and having to also tweak every bit of code that called it. And yet, I powered through it because typing found bugs that none of my tests had.
I'm not going to say that everyone who dislikes type annotations in Python (or TypeScript) writes crummy code. I will suggest that at least some of the people who complain that types make it harder to write a program are actually annoyed that it makes them write more-correct code.
> I will suggest that at least some of the people who complain that types make it harder to write a program are actually annoyed that it makes them write more-correct code.
I can relate to this when it comes to Python. Type annotations & mypy have undeniably caught bugs and forced me to write better & more correct Python. However, it's also true that I've felt a lot of frustration with them at times when I was nagged about something that was impossible, and fixing the mypy error felt like makework that didn't actually improve anything. I'd argue the result in those cases was worse.
So is it worth it in the end? Probably, and I'd use them in personal projects and run mypy as well, but I feel that the Python community could be taking it too far. Type annotations were supposed to be gradual opt in (and they still can be), but nowadays it doesn't feel that way, and while I appreciate the benefits brought by using them, I can't help lamenting what I see as a reduction of what I saw as the beauty of Python. Perhaps switching to a statically typed language is preferable to bolting on types to a dynamic language.
That’s valid. I’m pretty rigorous about typing new code, but don’t make any heroic efforts to go back and retrofit old, well-tested code. `mypy --check-untyped-defs` gives a lot of bang for the buck for checking existing code without going all-in.
I’m also OK with liberal use of Any for things like returning JSON fetched from an API. How should I know what it’s going to return this time? I’ll deal with that mess in the function that parses those results, not the one fetching them.
One way I think typing has made my code better is that I tend to use more dataclasses and namedtuples now. It’s easier to say List[Person] than List[dict[str,Union[str,float,int,Email]] etc. That also makes IDEs a lot happier because now I can say Person.bir and tab-complete it to .birthday. It’s a little more effort to set up, but a lot nicer in the long run.
But again, I find that fun and productive on new code. Darned if I wanna jump through those hoops on stuff that’s been running in production for a decade. I’m more of a fan of “type it as you touch it”.
I've written maybe a few hundred thousand lines of Python. I didn't use type annotations until recently because they didn't exist. My first forays into playing with them were painful: it revealed a whole lot of unfound bugs in my code. In most cases they were minor and probably wouldn't have caused a real-life problem. Fixing them was often challenging because changing a function frequently meant breaking an internal API and having to also tweak every bit of code that called it. And yet, I powered through it because typing found bugs that none of my tests had.
I'm not going to say that everyone who dislikes type annotations in Python (or TypeScript) writes crummy code. I will suggest that at least some of the people who complain that types make it harder to write a program are actually annoyed that it makes them write more-correct code.