Types and unit tests are bloat that increase the maintenance cost of whatever code they are involved in. Most types force premature design/optimization. Most unit tests lock up some specific implementation (increasing cost of inevitable refactors) rather than prevent actual bugs.
Nil-punning in clojure has spoiled me rotten, and now every other language is annoyingly verbose and pedantic.
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.
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.
Types help you refactoring and communicating with other team members about expected inputs/outputs. Did you ever try debugging a number that should’ve been a string in a codebase that you didn’t write? Example from today: jsforce will throw an exception when you pass a number instead of string due to the fact that the Salesforce server will complain that the type is incorrect. If the method had correct typing of “string”, it would save me a few hours of debugging a huge library without visibility inside of it…
Sounds like a frustrating issue - feels like salesforce shouldn’t be enforcing that number vs string in the first place, because it could just get coerced later on. But, it’s out of your hands for sure, and there are tradeoffs for them making their API “easier” to work with.
And yeah I’m being a bit obstinate in this hot take - it’s easy to get away without types when working on smaller projects and in more modern languages, especially for low-stakes dev tooling. In larger projects, types can help improve confidence during large refactors.
Meanwhile here I am thinking about pivoting my career from Python to Rust because I’ve grown to hate Python’s lack of typing. I also religiously write unit test even for minor personal projects.
I’m a longtime fan of python, but honestly I don’t know how I lived with it before type hints. It still feels a little backwards from the original design philosophy of python, and it’s more verbose than other strongly typed languages, but it’s come to feel pretty natural all the same.
Yup, IMO Python is so much better with type hints that I can’t help but think they should just be part of the language. Which is kinda stupid because of the “original philosophy” as you said. But on the other hand things like third party static type checkers and type stubs, or just untyped libraries can be a real PITA .
Also, I acknowledge that the lack of typing can be an advantage for some people in some circumstances, even though I use typing even in the simplest and shortest scripts myself. Why would I want to figure out the types every time I look at the function if I can just write it down?
I suppose i should at least caveat by saying i don’t by any means advocate for all dynamic langs over statically typed, and i agree types/unit tests are necessary for most languages. So please don’t make me write python over rust!
You can get the benefits of types/unit-tests via static analysis on a per-function basis with clojure and a library like malli, and for me that hits a minimalist sweet-spot.
Sorry, I liked this hot-take setup and I’m shooting from the hip a bit. Maybe i actually mean objects/classes, not types? Can’t everything just be a bag of key-values, like in clojure?
I have been building mostly prototypes (games and wm-tools) for a year, so most of my context is getting things working to see if they are useful rather than locking them down.
I thought about my argument a bunch, and while i have alot of complaints, it all sounds like non-specific whining to me, so i’ve decided to give up.
types and unit-tests have their place. Fine! I admit it! i was pushing a hot-take I’ve had on a few occasions, and I’m glad to see this programming community is alive and well! If you need me I’ll be in my clojure repl.
It’s also important to acknowledge how different is prototyping from writing production code which has to be extendable and maintainable for years by multiple developers.
Your take isn’t even very hot when we are talking about prototyping 😉
I disagree. What you’re saying is true for Java-like OOP languages because OOP is actually complete garbage if you want to design good, easy to understand abstractions. Types are way more elegant in functional or functional-inspired languages.
Most unit tests lock up some specific implementation (increasing cost of inevitable refactors) rather than prevent actual bugs.
Agreed, unit tests are useless in most cases, they mostly test the bullshit abstractions you built for the unit tests themselves.
I think you’re right re:oop - let’s throw that in there too.
One problem is naming things - bad names/naming conventions can start things off in a bad direction, so you spend forever figuring one out… but do you really need this thing you’re naming after all?
Maybe the hot-take is more like: All code is bad, so less code is better…. what should we drop first?
types are bloat for maintenence? id rather get a compiler error in 0.1 seconds than spend hours tracking down where in the code my number was coersed into a string.
Types and unit tests are bloat that increase the maintenance cost of whatever code they are involved in. Most types force premature design/optimization. Most unit tests lock up some specific implementation (increasing cost of inevitable refactors) rather than prevent actual bugs.
Nil-punning in clojure has spoiled me rotten, and now every other language is annoyingly verbose and pedantic.
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.
Then your opinion is absolutely understandable.
Types help you refactoring and communicating with other team members about expected inputs/outputs. Did you ever try debugging a number that should’ve been a string in a codebase that you didn’t write? Example from today: jsforce will throw an exception when you pass a number instead of string due to the fact that the Salesforce server will complain that the type is incorrect. If the method had correct typing of “string”, it would save me a few hours of debugging a huge library without visibility inside of it…
Sounds like a frustrating issue - feels like salesforce shouldn’t be enforcing that number vs string in the first place, because it could just get coerced later on. But, it’s out of your hands for sure, and there are tradeoffs for them making their API “easier” to work with.
And yeah I’m being a bit obstinate in this hot take - it’s easy to get away without types when working on smaller projects and in more modern languages, especially for low-stakes dev tooling. In larger projects, types can help improve confidence during large refactors.
I just want less code to maintain in general…
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
Meanwhile here I am thinking about pivoting my career from Python to Rust because I’ve grown to hate Python’s lack of typing. I also religiously write unit test even for minor personal projects.
(psst: you are right)
I’m a longtime fan of python, but honestly I don’t know how I lived with it before type hints. It still feels a little backwards from the original design philosophy of python, and it’s more verbose than other strongly typed languages, but it’s come to feel pretty natural all the same.
Yup, IMO Python is so much better with type hints that I can’t help but think they should just be part of the language. Which is kinda stupid because of the “original philosophy” as you said. But on the other hand things like third party static type checkers and type stubs, or just untyped libraries can be a real PITA .
Also, I acknowledge that the lack of typing can be an advantage for some people in some circumstances, even though I use typing even in the simplest and shortest scripts myself. Why would I want to figure out the types every time I look at the function if I can just write it down?
I suppose i should at least caveat by saying i don’t by any means advocate for all dynamic langs over statically typed, and i agree types/unit tests are necessary for most languages. So please don’t make me write python over rust!
You can get the benefits of types/unit-tests via static analysis on a per-function basis with clojure and a library like malli, and for me that hits a minimalist sweet-spot.
Can you clarify what you meant about types, then? Because I’m not sure I really understand your point there.
Sorry, I liked this hot-take setup and I’m shooting from the hip a bit. Maybe i actually mean objects/classes, not types? Can’t everything just be a bag of key-values, like in clojure?
I have been building mostly prototypes (games and wm-tools) for a year, so most of my context is getting things working to see if they are useful rather than locking them down.
I thought about my argument a bunch, and while i have alot of complaints, it all sounds like non-specific whining to me, so i’ve decided to give up.
types and unit-tests have their place. Fine! I admit it! i was pushing a hot-take I’ve had on a few occasions, and I’m glad to see this programming community is alive and well! If you need me I’ll be in my clojure repl.
It’s also important to acknowledge how different is prototyping from writing production code which has to be extendable and maintainable for years by multiple developers.
Your take isn’t even very hot when we are talking about prototyping 😉
deleted by creator
It was pointed out to me i should add OOP. Burn it all down!
I disagree. What you’re saying is true for Java-like OOP languages because OOP is actually complete garbage if you want to design good, easy to understand abstractions. Types are way more elegant in functional or functional-inspired languages.
Agreed, unit tests are useless in most cases, they mostly test the bullshit abstractions you built for the unit tests themselves.
I think you’re right re:oop - let’s throw that in there too.
One problem is naming things - bad names/naming conventions can start things off in a bad direction, so you spend forever figuring one out… but do you really need this thing you’re naming after all?
Maybe the hot-take is more like: All code is bad, so less code is better…. what should we drop first?
types are bloat for maintenence? id rather get a compiler error in 0.1 seconds than spend hours tracking down where in the code my number was coersed into a string.