The big problem with this take is that they seem to assume it is an all or nothing feature.
Personally I love how rust does it, types are inferred inside a body of a function where they matter less and are generally unambiguous (you need to specify them if they are ambiguous) as you often don’t care as much about the exact type you have. But on function parameters are return types they are never inferred as these form the contract to the rest of your program and a unexpected change to one of these can result in your code breaking somewhere else entirely.
Personally I never really use the automatic type annotations in IDEs, they just add noise I rarely care about.
I’m just glad that type inference can improve this sort of situation a bit:
ConfigManager configManager = new ConfigManager();
You know what really sucks?
When I have a method that returns a Foo and like 300 places it gets called.
And then I change it to return an ever so slightly different Bar
Ah, now I need to go and update the code in 300 places cause the return type changed.
“Can’t you just sed your codebase?”
Maybe, but it could cause some serious unintended dawizard
The solution to this problem (and many others) is to use an IDE / editor which supports refactoring like that. Which is pretty much every IDE / editor unless you’re using some very obscure language I think.
I dont think external tooling should be a factor in deciding your language’s definition.
If it returned a “Foo”, whose structure changes in such a way as to requires changes in all places it was used…
That, sounds to me like a disaster you avoided by being helped (which is the polite way to describe developers not getting away with ignoring lazy and dangerous type conversion bugs) to fix each and every usage of it.
No, there’s countless ways code could be consuming a Foo or Bar and not care which.
Literally any form of serialization won’t care, for example.
Also you can change from a Foo to a Bar in a non breaking manner, where it’s name changed but the still have the same interface.
We’re talking about type inference, right?
If you have countless examples, I’d be happy to entertain others that have to do with type inference, because 1) serialisation is not related, 2) renaming in APIs is arguably, also not. Though, I cannot remember the last time my IDE wasn’t able to know, and do this for me.
I can’t speak for OCaml, but type inference provides a lot of benefit in Rust. I already have too many keystrokes as it is, and forcing me to be explicit about everything would just add to the stress of using a keyboard.
I agree that types should be explicit at API boundaries. That’s precisely where you want to catch misuse.
As for the point about inference making code harder to read: I suppose that’s true if you spend a lot of time reading code outside of your editor where you also must know what the types are. But that just sounds like a bad workflow in general. Why are you avoiding using a better tool for the job? Modern code review tools like Github even support LSP-like features to solve this problem; and if your language isn’t supported… just pull the feature branch to review it.
He explicitly states that its not that bad in Rust because all functions must have type annotations. Its only a problem if your functions are huge (they shouldn’t). I think thats the correct way to go. Local variables can be inferred but anything else should be annotated.
Modern code review tools like Github even support LSP-like features to solve this problem; and if your language isn’t supported… just pull the feature branch to review it.
But now your requiring more tools and effort on the reviewer over, just reading the code.
But now your requiring more tools and effort on the reviewer over, just reading the code.
This should be completely negligible if you are writing code in the same code base.
I was already assuming I was working on the same codebase. I am not going to stash my work, checkout the branch and wait for the LSP to start up (if it’s working) just to confirm that your types aren’t doing anything weird. I’d rather just have them annotated correctly in the first place and just read the PR and trust the CI.
It’s really weird to me to base any decisions around how much typing you have to do.
Typing is such a small part of programming I really don’t get it.
stress of using a keyboard
Can you elaborate?
Readability and maintainability are core imo.
It’s really weird to me to base any decisions around how much typing you have to do. Typing is such a small part of programming I really don’t get it.
Typing is a huge part of programming. Have you heard of RSI? People invest hundreds (sometimes thousands) of dollars in ergonomic keyboards just to overcome RSI pain. If you’re younger than 30 you might not be impacted by this, but many people who have been typing every day for over a decade are realizing it’s not sustainable without proper ergonomics.
Readability and maintainability are core imo.
I don’t think you sacrifice these by having local type inference. It’s never been an obstacle for me.
Like many things… it depends.
Type inference is wonderful for prototyping and writing short lived tools - it is an unnecessary expense for mature projects with a large number of developers on it.
At my shop we have a concept of “one off” routes that are written to accomplish a specific task and intended to be run once. A few of these are run repeatedly but with the understanding that these routes are unmaintained and exempt from automated testing requirements (we’ve got a separate bucket for routes that are only rarely invoked but are complex enough and frequently enough used to get test coverage). For stuff like those one off scripts I’ll never block a PR for omitting typing - while I absolutely will in our regular codebase.