News for hackers. Stuff that matters.
Re:Reasons to avoid static type checking by treflop on Sunday January 28, 2024 @02:08AM (#39163216)
Personal opinion here but I’d put TypeScript in the S-tier for “static typing overall enjoyable-ness,” Java in D-tier and it pains me to say Python in F-tier.
Re:Reasons to avoid static type checking by MrJohz on Sunday January 28, 2024 @02:44AM (#39163374)
Yeah, I've recently removed type checking in a Python project because it was causing more false positives than true positives, and working around the type checker's complaints was just getting too tedious.

I'm a big fan of type checking in general, and Typescript is a great example of a type checker that allows you to statically define all the dynamic idioms that you'd normally use. But for various reasons, that just doesn't seem to have happened in the Python ecosystem. Instead, you can either write normal dynamic Python without types, or you can restrict yourself to a vaguely Java-like subset of Python with hard-to-use generics and confusing rules about forward references.

I wonder if it would have been better to have taken the Typescript approach and have Mypy and all its annotations developed as a separate language, rather than as part of the Python language, with the expectation that they could eventually be merged at some point. As it is, it feels like both sides have been very constrained: Mypy has struggled to innovate on expressive type-level syntax because it only operates on standard Python code, and Python has struggled with balancing the various goals that different groups have for youry annotations.

The result is a kind of mess where it's still painful to type basic things like generics (yes, that's changing, but not if you need to support older Python versions), but you also have weird syntax that requires type annotations, even if they're meaningless (like with dataclasses).

Re:Reasons to avoid static type checking by jowf8fa9sdf on Sunday January 28, 2024 @09:00AM (#39165814)
Have you tried pyright? I find it way better than mypy.
Re:Reasons to avoid static type checking by MrJohz on Monday January 29, 2024 @01:28AM (#39173357)
When I removed the type checking stage, that was with Pyright, which I'd used because of these sorts of recommendations. It has some advantages over Mypy, sure, but it still ended up being more hindrance than help. Particularly with things being of type `Unknown`, which produced all sorts of errors that I could never properly disable.
Re:Reasons to avoid static type checking by th0ma5 on Sunday January 28, 2024 @02:11AM (#39163227)
Are those tiers good or bad? What is the order?
Re:Reasons to avoid static type checking by treflop on Sunday January 28, 2024 @02:13AM (#39163235)
Re:Reasons to avoid static type checking by bmacho on Sunday January 28, 2024 @04:03AM (#39163761)
SABCDEF descending
Re:Reasons to avoid static type checking by th0ma5 on Sunday January 28, 2024 @12:05PM (#39167600)
Why not different letters this seems to go unanswered
Re:Reasons to avoid static type checking by BigJono on Sunday January 28, 2024 @03:10AM (#39163486)
I don't know how you can put TS in the S-tier when the community is hell bent on making every codebase as unreadable and complicated as possible.
Re:Reasons to avoid static type checking by petesergeant on Sunday January 28, 2024 @03:56AM (#39163726)
> when the community is hell bent on making every codebase as unreadable and complicated as possible

I don’t understand what you’re getting at, but clearly you’re expressing some pain here: what are some examples?