I do get where you’re coming from, however. Dynamically typed languages are great for prototyping and if you’re dealing with a small codebase, it can stay that way, but IMO large codebases without typing are not fun to navigate and understand.
“Which class am I dealing with now?” is such a common problem that I’d rather have it explicitly written than guessing or assuming to know.
Very happy to share this hot-take :) Definitely code-base and team-size are a huge factor, and I mostly work on my own projects, so each project is very different. still, I expect to get downvoted into oblivion by the last decade’s influx of typey-langs and -devs.
I think most love for types is folks being happy they don’t need to assert on the input to every function, i.e. static analysis and reduced unit-tests. It’s hard for me to not see types as asking folks to pre-design their entire system (by defining types first!), before you’ve even started writing a few functions, which are actually what the system should codify (behaviors, integration tests). It’s also frustrating b/c types don’t guarantee that the system does-the-thing, only that the type-system and compiler are happy, so it’s like pleasing the wrong boss, or some metaphor like that.
I like to work with behavior directly in functions, which should be the same regardless of the type passed in. Unfortunately most dynamic languages have their flaws (js,python,etc), so this kind of opinion suffers b/c of those languages… similar to type-favoring opinions suffering b/c of langs like typescript.
Nil-punning makes me very happy - that’s a hill I will actually die on. Almost every project i’ve worked on, there’s no reason to go out of the way to specifically handle every case of not the right input or oh-no-it’s-null! Whenever you have null, you just return null from this function too, and guess what, everything’s fine - no need to crash and blow up b/c one thing wasn’t there. Mostly this is a complaint about things completely crashing for no reason, rather than being incomplete (i.e. some data missing) but still working for the user.
Anyway, lots of different use-cases, and use the right tool for the job, etc etc. types and unit tests are useful for some things.
Definitely a hot take. Wow.
I do get where you’re coming from, however. Dynamically typed languages are great for prototyping and if you’re dealing with a small codebase, it can stay that way, but IMO large codebases without typing are not fun to navigate and understand.
“Which class am I dealing with now?” is such a common problem that I’d rather have it explicitly written than guessing or assuming to know.
Very happy to share this hot-take :) Definitely code-base and team-size are a huge factor, and I mostly work on my own projects, so each project is very different. still, I expect to get downvoted into oblivion by the last decade’s influx of typey-langs and -devs.
I think most love for types is folks being happy they don’t need to assert on the input to every function, i.e. static analysis and reduced unit-tests. It’s hard for me to not see types as asking folks to pre-design their entire system (by defining types first!), before you’ve even started writing a few functions, which are actually what the system should codify (behaviors, integration tests). It’s also frustrating b/c types don’t guarantee that the system does-the-thing, only that the type-system and compiler are happy, so it’s like pleasing the wrong boss, or some metaphor like that.
I like to work with behavior directly in functions, which should be the same regardless of the type passed in. Unfortunately most dynamic languages have their flaws (js,python,etc), so this kind of opinion suffers b/c of those languages… similar to type-favoring opinions suffering b/c of langs like typescript.
Nil-punning makes me very happy - that’s a hill I will actually die on. Almost every project i’ve worked on, there’s no reason to go out of the way to specifically handle every case of not the right input or oh-no-it’s-null! Whenever you have null, you just return null from this function too, and guess what, everything’s fine - no need to crash and blow up b/c one thing wasn’t there. Mostly this is a complaint about things completely crashing for no reason, rather than being incomplete (i.e. some data missing) but still working for the user.
Anyway, lots of different use-cases, and use the right tool for the job, etc etc. types and unit tests are useful for some things.
In my opinion, pre-designing your code is generally a good thing. Hours of planning saves weeks of coding
Fair! Naming is hard, but maybe that’s no excuse for not defining a thing