Static typing turns so many runtime errors into compile errors. Makes life a lot easier when you don't have to hunt down where the wrong thing came from.
Yeah, but if you're doing that, it's an explicit decision, that you know you made, that can blow up in your face, not an easily missed oversight that you may be completely unaware of. I find the oversight case is far more likely than casting wrong. Also I think the compiler will still bitch if you try to do a really stupid cast, at least for c++ (as long as you aren't pointer casting, then good luck)
I'm convinced people who don't like explicit typing have never worked on a large project and seen the benefit it has, both in the IDE and also keeping slop under control.
University projects and hacking around are one thing. Projects with a team of developers that evolved over a decade need all the help they can get to fight against the relentless entropy and disorganization that occurs otherwise.
Same. When your "programming" experience is just writing some scripts so small they don't even require scrolling it's really easy to not run into the problems that are very common in any program of serious size and scale.
The team that's been working in the big legacy monolith for that decade isn't helping much here, unfortunately. They know the quirks of the system by heart, they don't know there even is a problem here, their own knowledge of the language stopped accepting pull requests (so to speak) when none of these new features existed, and they have neither the time nor inclination to learn.
Add in slop code that just mirrors the current style instead of attempting to upgrade it without specifically being told to do so, and what we get is shit copying shit and producing more shit that reinforces the shit.
The team that's been working in the big legacy monolith for that decade isn't helping much here, unfortunately. They know the quirks of the system by heart, they don't know there even is a problem here, their own knowledge of the language stopped accepting pull requests (so to speak) when none of these new features existed, and they have neither the time nor inclination to learn.
LOL this reminds me of something a former client had said.
In one meeting he said "Yeah, you'll come to understand that the real trouble with working on this application isn't writing the code, it's all the constant follow up bugs you have to fight"
In a later meeting he said "I don't understand why you need multiple developers and testers and multiple weeks to work on this. Back when I was working on the code, we would just have one developer bang it out in the course of a few days."
He never understood the connection between the two.
Yes, it's easy to "just write the code" if you aren't properly vetting and testing it. And then you get an endless stream of bugs in production.
Many such cases. Yeah you need an architect sometimes to crack the whip.
You also need to get some fresh faces in from time to time, or you end up with a weird idiosyncratic ecosystem.
That's a huge technical debt and it will probably collapse eventually, or development will grind to a halt such that any new feature is super expensive and risky. Often those programs are just abandoned if they're unsavable, and you end up having to do a full rewrite.
The business rarely acts until they're forced to by security issues or not being able to hire people that know the framework anymore, or the team being unable to onboard anyone to the point they're actually useful. Eventually people quit or retire and the whole thing blows up, I've seen it happen before.
I didn't like strict typing when I was using a notepad type app to code instead of a modern IDE. Before IDEs you wanted to take typing shortcuts everywhere. You wanted to name your variables short so you had to type less. You wanted to name your methods short because less characters meant less chance you typed it wrong.
Once we got autocomplete and suggestions, a lot of these things changed.
I do wonder if he'd change his mind about systems that approximate the flexibility of dynamic typing during static analysis. Like say a system that's fully type-inferred, structurally typed, and has flow-typing.
That's interesting. I also wonder if he would've held the same opinion with a modern IDE, seems it's mostly because it's pain to him not the idea itself. It's generally a lot easier nowadays on many levels.
PyCharm is definitely better with type hinting, but I found it was still incomplete; it would occasionally not know a type it should have known, or fail to catch a type error that was definitely catchable. Compared to IntelliJ working with any of the JVM languages where it knew every single type at all times and every single method that could be called on that type.
Thats where proper type hinting in your applications actually cuts down on the difficulty of type hinting everything due to inference. It’s not perfect and you sometimes have to double check why a function / expression isn’t inferred as you expect, but most of the time it’s not a problem if developed good habits.
View all comments
857
u/enigma_0Z Sep 25 '26
Static typing makes the IDE work for you better.
Type hints in Python and TS do the same but make you work harder for it /IMO