Static Types Are for Perfectionists
133 comments
·May 17, 2025Jtsummers
sshine
After writing a lot of Nix in the last year, it has opened me to possibly switch to Scheme.
I’ve always been a strong static type guy since 1st year of university, and yes, it ties to perfectionism and even a sense of OCD: if I model the world around me, I can relax.
But here’s a take that I’ve been trying to articulate about Nix: it’s not about the static types. Nix is loosely typed, and if there is a functional language that doubles as coping strategy for recreating a quasi-perfect model of the world, it’s Nix.
So I believe any strong modelling combined with declarative syntax can be argued is a coping strategy for autism. It’s not strictly the types.
It also happens that software made this way is more reliable, breaks less.
Maybe the opposition to its use in businesses is that business needs often change rapidly, and tying yourself to any correct understanding of the world means you’re late to the party.
(I’ll then argue: there are companies that succeed at strong modelling, and companies that succeed at pivoting, and all companies need a bit of both at different times. That’s why huge companies with scaling problems and infinite runway pick Rust, and startups pick JavaScript.)
90s_dev
"If I haven't seen it, it's new to me."
I'm very happy to see the case being made for static typing. Dynamic types should be niche, and eventually they will be. Rails and Python only made them popular out of a reactionary minimalism thanks to types done wrong in C++ and Java ecosystems. New developers should read articles like this very early on. The more often they're written and posted, the sooner we can all move on from unnecessary type errors.
null
wiseowise
> So much for "without judgement".
Previously author felt enlightened by sneering on stupid normies for not understanding beautiful, clean™, statically typed code.
What’s better way to show how better you’re now, that you’ve reached new nirvana, by sneering on ivory tower wizards with their arcane languages that are obviously a sign of autism (because whoever is different from, and possibly smarter than, you is obviously autistic)?
roman-kashitsyn
Author here.
> because whoever is different from, and possibly smarter than, you is obviously autistic
I’m not sure how you came to this conclusion from the text I wrote.
Autism has nothing to do with intelligence level.
BTW, I identify as autistic. And I find Haskell very soothing.
edg5000
I wrote a large enterprise JavaScript application that was behind Apple/Google update approval, was used daily by businesses whose entire operation depended on it.
I will never touch loosely typed stuff again. I want every keystroke checked for errors. I want autocomplete to select from possible members/fields/variables/functions/classes rather than doing constant global find/replace operations and having the customer be the beta tester
rrauenza
I adopted Python type annotations on a new project I was writing. Requirements shifted a lot as well as the implementation.
It was amazing. I could refactor quickly after changing a dataclass, field name, function arguments, type, etc. I just ran mypy and it immediately told me everywhere I needed to update code to reference the new refactored type or data structure.
Then only after it was mypy clean, I ran the unit tests.
NeutralForest
My style has changed over time and part of it is thanks to static type checking in Python. I rarely use dictionaries anymore when what I actually want is a different type that functions will handle down the line. So to transfer data, I usually make frozen dataclasses where I used to use dictionaries. It's more work when you want to add fields on the fly ofc but it pays dividend anytime the logic becomes more complex.
rrauenza
Agreed -- dataclasses over dicts. And for legacy code I try to move them to typed dictionaries.
Pydantic is also helpful to enforce types on json.
I've also stopped passing around argparse namespaces. I immediately push the argparse namespace into a pydantic class (although a dataclass could also be used.)
smitty1e
Yes, but, the longer I use python (for personal and admin tasks mostly), the more the REPL and pytest let me sneak up on the 80% solution to my task at hand and get on with life.
The scope of possibility does not end with a full-on enterprise application, having all of the Bell() and Whistle() classes.
emoII
You do write tests, don’t you?
ninetyninenine
Don't understand why people find tests important but not types.
There's two popular ways to verify your programs. Types and tests. Types are EASIER then tests and types COVER more then tests.
The ideal thing is to use both, but why spend so much time on unit tests over types is beyond me.
Note that integration tests are a different beast. Why? Because you need to test things that aren't covered by either unit tests or types. In unit tests you mock out things that are external like IO, databases, and the like. In integration tests you need to test all of those things.
Integration tests are THE most important thing to use to verify your program because it's an actual test to see if your code works. But unit tests vs. types? Types win.
When I code. I never write a single unit test. Just types, and integration or end 2 end tests. It doesn't hurt to write a unit test and it's actually better. But the fact that I'm confident my code works without it shows the level of importance.
gleenn
If you do it right, your tests cover the thing you care about and are less work usually because you write the test for the part of code that has the interesting part you want to verify works correctly. Types, especially on fully typed languages, make only guarantees about the type of values and they make you do it in places you might not care about. Types also only catch certain classes of errors that I personally find less helpful that tests. So to me, tests are less work, focus on thebimportant parts, and give better error messages. Obviously you can also write bad tests and do things like effectively just check the types in pmaces and you are back to square one. Testing is more of an art but the effort/economics of time are far better to me.
theLiminator
> When I code. I never write a single unit test. Just types, and integration or end 2 end tests. It doesn't hurt to write a unit test and it's actually better. But the fact that I'm confident my code works without it shows the level of importance.
Imo this might be true if you're writing a lot of glue code. But I think unit tests are extremely valuable for testing pure functions that are pure logic/computation. For glue code/ensuring everything is hooked up correctly, types easily beat tests, but for pure logic tests (ideally property based testing if you can swing it) works great.
MoreQARespect
Like tests, types can be more hassle than theyre worth if you dont use them correctly.
Before mypy came along I was pretty disciplined at A) testing and B) ruthlessly clamping down on primitive obsession.
I use types a lot now but I didnt see enormous quality or productivity gains when I started using them. I suspect people who let compilers catch their bugs were always A) pretty lax testers and B) probably often let primitive obsession get the better of them.
There are only a few types of tests where I think that types actually serve as an appropriate substitute.
90s_dev
TDD and BDD are security blankets for enterprises and clients. They add disproportionately little value, and significantly increase the cost of evolving an app in any direction.
NeutralForest
TDD/BDD are just tools, in some cases they're useful and some other cases they're not.
If your work is deeply exploratory and you don't even know what the final interface/API will look like, you shouldn't start with TDD. You should probably test as you go though, once you find some behavior you'd like to keep and pin down variations and edge cases you met during dev.
If/Once you know what the expected behavior is, you can encapsulate that knowledge in tests, that's TDD to me. Then, I can write more code that meets the need of the expected API.
MoreQARespect
TDD and BDD teaching and tutorials are almost universally terrible so people inevitably do them badly and then moan about the results, which can be worse than not using them at all.
Usually the primary mistake is either using cucumber (which is awful) or surrounding the wrong interfaces with tests (usually at too low a level).
Done well they are like a mini superpower.
jamil7
The person you're responding to only mentioned tests, not TDD or BDD.
toolslive
"unit tests are a poor man's compiler" (NN)
fyrn_
Yeah, that will really help with the auto complete and keystroke by keystroke checking?? What?
PaulKeeble
Despite the somewhat clickbait title this is quite interesting on technology preferences and the path to what makes us happy and productive.
The idea that our preferences in technology are driven by our path of learning seems relatively self evident, those that started with C/C++ verses Smalltalk verses Java verses Python as their first language likely have a very different perspective on the various trade offs of these languages. Given we don't usually learn every language and certainly not to a deep extent few have deep experiences in all the possibilities to grok the differences in practice on similar projects.
"I need the right project and the right team to function well"
AnimalMuppet
I don't think it's just "what our path of learning was", though that plays a role. I think that different personalities prefer different styles (functional vs procedural), different languages (static vs dynamic typing), and probably several other axes.
This explains, for example, why one person sees functional programming as a massive revelation, where suddenly everything "just fits", and assumes that anyone who doesn't have the same reaction hasn't "gotten it" yet. And others, despite diligent trying, never have that reaction.
goda90
I work in software where bugs can be very disruptive for the end user's very important job. Typescript was a godsend over JavaScript. I've blamed issues on changes where the developer clearly didn't grok the area they were changing. And I've witnessed dependency hell slowing down the development process. I've come to the conclusions OP did from professional experience that provides negative feedback, not some past psychology from my personal life.
There are certainly cases where you wouldn't get that negative feedback for your software, so you would never feel the need for those things. And maybe in that case you can move faster without them, but you should be careful taking those beliefs into other domains.
keithasaurus
static types: here's what this piece of data is
dynamic types: go look through code, tests, comments and project history to try figure out what this data is supposed to be
dynamic types are exhausting
dleeftink
Exhausting, yes, why would we need to prep our own meal if it can be served to order?
Types are needed for sure, but don't make up for the fact we have to prep our own meals from time to time, even the best recipes don't cover all variations.
keithasaurus
For me the variation is one of the places where dynamic typing gets really dangerous, because as variations increase, the requirement for code archaeology does as well. At some point there is enough variation that nobody could reasonably be expected to do enough code exploration to understand the full breadth of that variation.
With types, the scope of the variation is clearly stated, and if you want to expand the variation, it should be clear how to do so, depending on the flavor (e.g. union types, sum types, generics, sub types).
dleeftink
It's definitely easier to extend existing recipes than having to start from none. What I tried to get at, is that even with in-depth recipes, there's a bigger codebase picture behind the type, that GP found exhausting navigating without.
I think if we start to lean on types for our all recipes, we may forget how to prepare them without instruction.
theLiminator
In general though, a strong statically typed language will allow the user to locally reason to a much greater extent.
williamdclt
If there’s a lot of variations that’s exactly when you need help from typing to not mess things up.
If the modelling is trivial, the ROI is much lower (although the devx benefits still make it worth it to me)
igouy
static types: write types into the code to make the compiler happy, when trying to think about more important stuff
dynamic types: method parameter name gives the type and comment gives the method return type — conventions show what data is supposed to be
static types are disruptive and exhausting :-)
parpfish
i like static code because a codebase that applies types well gives you the same benefits of writing lots of tests for free.
igouy
The benefits are not the same. Code can type check but not be correct.
There's no free lunch. Some languages require explicit type definitions others don't.
kibwen
Conversely, code can pass tests and not be correct, including in ways that would have been trivially caught by a type system.
If you care about correctness, use both. Codebases written in static languages still use tests.
igouy
Yes, we care about run time behavior.
theLiminator
> Code can type check but not be correct.
Depends on your type system. It can prove the correctness of certain properties depending on your language.
Conversely, unit tests can pass but your code might not be correct.
igouy
Depends on your type system. Depends on your tests. Depends.
Yet another under-specified commentary ;-)
parpfish
Well, yeah. Types don’t remove the need for ALL tests, but it removes the need for the most boring 90% so your test suite can just focus on the most important behaviors
null
Spivak
Yep, there is basically nothing else to be said. Using a static type checker isn't some moral imperative or whatever. I simply am able to write better, more correct code faster than without it. And my test suite doesn't have to do things like check the return type of the function because the type checker already knows.
90s_dev
Type systems make 93% of tests obsolete. The other 7% are implied by developing new features and making sure they work as you expect. If nothing broke, you're good to go. Incidentally, it scales with a team. The more people writing code, the more people who will run into some bugs one of you introduced. In my experience, automated tests (unit or e2e) never reduced that number, but only slowed us down. I wonder if TDD & BDD were just an excuse to bill clients for more time while giving them a false sense of security.
theLiminator
Ironically the strongest advocates of dynamic languages tend to be places where a strong type system would solve a huge percentage of their bugs.
Web development is mostly the munging of data together and ensuring that you're glueing stuff together correctly. Static type systems, especially ML based ones would ensure that most of this is done correctly.
AnimalMuppet
> Type systems make 93% of tests obsolete.
I don't suppose I could trouble you for a source for that number?
igouy
Ummm wouldn't that be check the return value which the type checker doesn't already know?
cma
Ironically they usually make unit tests and testing by hand in the repl harder
bpshaver
I would love to read the steel man case for dynamic typing, but "static typing is for people who need therapy" isn't doing it for me. Anyone have something to recommend so I can understand the intended benefits of dynamic typing?
lisper
> I would love to read the steel man case for dynamic typing
It's very simple: sometimes lower development effort matters more than correctness. Not all software has to run in a hostile production environment to be useful.
bpshaver
That would seem to be begging the question to an extent. Why does dynamic typing lead to lower development effort? I mostly write Python and make heavy use of type hints. With LSP set up, mypy informs me immediately of any potential type errors which makes development way easier for me.
Just saying "dynamic typing is easier" doesn't do it for me without further qualification since that statement doesn't conform to my own experience.
doug_durham
How much is maintaining your type system really helping you out? I find I spend more time tracking down irrelevant type warnings than fixing type issues. For example if you declare a type hint on a function parameter as `foo: int = None` you will get a type error. It says that a parameter of type int can't have a None value. This is false. So now I have to update my declaration to be `foo: Optional[int] = None`. This yields no value because when you say `= None` you are saying that this is an optional argument. The more you tighten your type declarations the more you will be chasing non-existent issues.
igouy
>That would seem to be begging the question …
Please excuse my pedantry: That would seem to lead to the question …
lisper
> Why does dynamic typing lead to lower development effort?
Because you can run your program to see what it does without having to appease the type checker first.
There is nothing wrong with presenting type hints or type errors as warnings. The problems arise when the compiler just flat-out refuses to run your code until you have finished handling every possible branch path.
AnimalMuppet
1. Dynamic typing says "anything I can do these operations on, I accept as input". This lets you accept input from code that doesn't have something that fits the strict definition of what input you were expecting.
2. Dynamic typing lets you change what shape your data is without having to change type annotations everywhere.
Problem is, I think both of these are deeply flawed:
1. If you're writing something nontrivial, you probably have several layers of nested function calls, some of which may be calls to libraries that are not yours. If you're saying "anything I can do these operations on, I accept", it becomes very difficult to say what the full extent of "these operations" are. Thus it becomes hard to say whether the caller is passing in valid input. You can "just try it", but that becomes hard if you care about it working in all cases.
2. Refactoring IDEs are a thing these days. You want to change the type signature? Press the button. Even better, it will tell you everything you broke by making the change - everywhere where you're doing something that the new type can't do. Without types, sure, you can just change it without pressing the button. Now try to find all the places that you broke.
It may be possible to construct a better steelman than I have done. For myself, even trying to steelman the position, I find it incredibly unconvincing.
igouy
"Static typing is a powerful tool to help programmers express their assumptions about the problem they are trying to solve and allows them to write more concise and correct code. Dealing with uncertain assumptions, dynamism and (unexpected) change is becoming increasingly important in a loosely couple distributed world. Instead of hammering on the differences between dynamically and statically typed languages, we should instead strive for a peaceful integration of static and dynamic aspect in the same language. Static typing where possible, dynamic typing when needed!"
https://ics.uci.edu/~lopes/teaching/inf212W12/readings/rdl04...
bpshaver
But you can achieve #1 with typing.Protocol in type-annotated Python and traits in Rust. Fitting the "strict definition" sounds like nominal typing but you can opt in to explicit duck typing or structural typing while still being typed. (Someone correct me if I'm using these terms incorrectly.) In short you can still encode a lot of flexibility with types without just abandoning them alltogether.
And with #2, you can get that with static typing too... Let's say a method accepts an instance of an object `Foobar`. I can change the definition of `Foobar` ("change what shape [my] data is") without having to change type annotations everywhere.
I agree with you, I guess, that I find the steel man position unconvincing.
igouy
Refactoring IDEs were a thing back in the day.
"Less than 35 bugs were found in the 17,100 changes."
igouy
> Without types … Now try to find all the places that you broke.
Do failing tests show what we broke?
AnimalMuppet
Yes, if you have tests that test all aspects of the behavior for all possible inputs.
Oh, you don't have that? Then do not scorn the help you can get from types.
bpshaver
Sometimes, but maybe you haven't written any tests! Type hints and immediate feedback from mypy are a lot easier than writing unit tests.
Jtsummers
The way I see it:
Your type system is sound or complete (cannot be both, if it's a Turing-complete language). If it's dynamically typed, then it's probably complete but not sound (many, but not all, dynamically typed language implementations have some basic static type checking). If it's statically typed, it can be either sound or complete. The difference between sound and complete is: Sound type systems will reject valid programs that they cannot prove are valid; Complete type systems will reject only those invalid programs they can prove are invalid.
In practice, the choice is more one of default these days:
Do you default to static typing and allow some dynamic (runtime) type checking? C++, C#, Java, etc.
Do you default to dynamic typing and allow some static (compile-ish time) type checking? Python, JS, Common Lisp, etc.
This lets both sides have what they really want. They want to be able to express all valid programs (a complete type system) but they want to reject all invalid programs (a sound type system). They can't have it. So you end up choosing a direction to approach it from. Either start conservatively and relax constraints, or start liberally and add constraints.
If you accept that, then the case for dynamic typing is that it's a choice to move from the too permissive extreme towards a stricter position. For me this works better (in general, though I also happily use statically typed languages like Ada) because I find it easier to add constraints to a relaxed system than to remove constraints from a restrictive system.
null
bryanlarsen
My attempt: "These dynamic languages are so much more pleasant and productive than Java 1.X."
dkarl
The author seems obsessed with what their code says about them personally, and only mentions other people to discuss other points of view on this question. At no point do they say anything about how working with other people influenced their thinking about programming or their technical preferences. In fact they only mention peers a single time:
> I met many people whose programming approach was my polar opposite.... I don’t have any issues with their way, as long as we don’t work on the same system
Being obsessed with what your code says about you is a concern that competes with and inevitably detracts from other desirable outcomes. This is true even when working by yourself, but it is especially true and especially obvious when working with other people.
adamnemecek
Types give you speed, correctness and better tooling. Dynamic typing supposedly gives you "authentic self". I think I'll pick the former.
alabhyajindal
So many comments about static vs dynamic typing whereas the article barely discusses that. I loved reading this - very well written!
constantcrying
I think it is important to understand why you are doing what you are doing. Sure, enjoyment and "authenticity" can be part of it, but it clear that e.g. static vs. dynamic typing is an engineering tradeoff. Making a decision in either direction should be based on those tradeoffs.
One important consideration is the importance of the project, hobby projects are for enjoyment mostly, so there "authenticity" is really important. At the same time you shouldn't make decisions on how to develop aerospace software based on how "authentic" the development process feels.
roman-kashitsyn
> you shouldn't make decisions on how to develop aerospace software based on how "authentic" the development process feels.
You don’t just land in an aerospace company with an unbiased, rational mind and make an engineering tradeoff. You join it because you find building high-integrity software fulfilling (I am!), and the job enables you to exercise choices that feel right to you. Alternatively, you are so passionate about space that you can endure whatever it takes to get there, including writing Ada/Spark.
The best swimmers don’t grow high and develop long limbs and a big chest due to their practice and rational decisions. They become best by already having a matching physique and working hard to capitalize on it.
I don’t promote a fixed mindset, saying that you can’t get better if you weren’t born with a natural talent. My point is that some things will resonate more with you and bring you the most satisfaction. You should try different things, listen to your inner response, and not judge others because they made different choices.
gejose
Ragebait title
constantcrying
And a thread where people respond to the title of an article and not the article itself.
chrisweekly
It's not a title that suggests much subtlety or wisdom will be found in the article.
EDIT: ... which is unfortunate, bc it's actually a decent read w/ interesting points about the relationship between (programming preferences) and (emotions / psychology).
https://news.ycombinator.com/item?id=43966948
I'll make the same remark I did last time this was posted here (it's been submitted 3 times in one week):
The author starts with this:
> I conclude with two implications of this idea: the necessity to accept other people’s preferences without judgment and the importance of finding an environment rewarding your style.
And follows it with these two things:
> Type theory maximalists should give up their aura of moral and intellectual superiority and accept that they need therapy just as badly as everyone else in the industry (if not more).
>> Haskell will still be used in 20 years, because there will always be people looking for a productive way to weaponize their autism.
So much for "without judgement".