You must log in or register to comment.
I’m just glad that type inference can improve this sort of situation a bit:
ConfigManager configManager = new ConfigManager();Why not just use auto (assuming C++) or var (assuming C#/Java)?
Because that’s type inference. The exact thing the article is arguing against. And that this comment is saying is nice.
That’s false for closures (or unnamed/inline) functions with context because their type is unique and so you just can’t write their type and that’s not a lang’s fault - that’s logically correct side-effect by-design.
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.
To me this is an argument for why Go should not add type inference to function/method declarations. Go is like Rust (I guess, I haven’t used Rust) - type inference works for declaring a variable (or const) and generic type parameters but not for type declarations, methods, functions, etc. I was in the “more inference is always better” camp but now I’m thinking Go has the perfect level of inference. Except for function literals/lambdas. I really want go to infer the argument and return types when I’m passing a function literal/lambda to a function.
The thing about Rust’s type inference that seems wild to anyone who hasn’t seen Hindley-Milner/ML style type systems before is that it’s “bidirectional” (in quotes because that’s not a proper type theory term as far as I know). The type of the left-side of an assignment can determine the type (and behavior!) of the right side. For instance, this is ambiguous:
let foo = [("a", 1), ("b", 2)].into_iter().collect();The expression creates an iterator over the
(letter, number)pairs, andcollect()stores the elements in a newly created container. But which container type? Here are two valid variants:let foo: Vec<_> = [("a", 1), ("b", 2)].into_iter().collect();This creates a vector with items
("a", 1)and("b", 2).let foo: HashMap<_, _> = [("a", 1), ("b", 2)].into_iter().collect();This creates a mapping where
"a"and"b"are keys, and1and2are the corresponding values.Playground link in case you’d like to mess with this concept: https://play.rust-lang.org/?version=stable&mode=debug&edition=2021&gist=76f999f4db600415643b0c58c19c69b7
You know what really sucks?
When I have a method that returns a
Fooand like 300 places it gets called.And then I change it to return an ever so slightly different
BarAh, now I need to go and update the code in 300 places cause the return type changed.
“Can’t you just
sedyour codebase?”Maybe, but it could cause some serious unintended dawizard
I prefer type inference. It’s extra clutter that can often be abstracted away with good variable and method names. If it quacks the way I need it then that’s one less thing I need to hold context of in my head.
You should read the article, because it’s pretty much a direct rebuttal with justifications to this exact argument. You’ve really just re-stated what the article disputes.
Which isn’t to say you’re wrong, I’d just be interested in your response to the arguments.
My response to the article is that you’re sacrificing gains in language because some people use outdated tools. Code has more context than what is just written. Many times you can’t see things in the code unless you dig in, for example responses from a database or key value store, or literally any external api. Type inference in languages that have bad IDE support leads to a bad experience, hence the author’s views on ocaml. But in a language like Kotlin it’s absolutely wonderful. If needed you can provide context, but otherwise the types are always there, you can view them easily if you’re using a decent IDE, and type inference makes the code much more readable in the long run. I would say that a majority of the time, you do not care about the types in any application. You care about the data flow, so having a type system that protects you from mismatched types is much more important that requiring types to be specified.
Maybe I’m missing something:
Does type inference provide a practical benefit to you beyond saving you some keystrokes?
What tools do you use for code review? Do you do them in GitHub/gitlab/Bitbucket or are you pulling every code review directly into your IDE? How frequently do you do code reviews?
Does type inference provide a practical benefit to you beyond saving you some keystrokes?
it’s more readable! like, that’s literally the whole point. It’s more readable and you don’t have to care about a type unless you want or need to.
What tools do you use for code review? Do you do them in GitHub/gitlab/Bitbucket or are you pulling every code review directly into your IDE? How frequently do you do code reviews?
I use GitHub and Intellij. I do code reviews daily, I’m one of two staff software engineers on my team. I rarely ever need to know the type, and if I do Github is perfect for 90% of use cases, and for the other 10% I literally click the PR button in intellij and open up the pull request that way. It’s dead simple.
So you’re saying that for you, not only do you generally not see value is knowing types, but that them being explicitly defined is DETRIMENTAL to your ability to read the code?
For me, it’s like if I whip open a recipe book and see tomato sauce, dough, cheese, and pepperoni are the ingredients. Before the recipe details specifically how they are combined, I have a pretty good context from which to set expectations based on that alone. It’s a cheap way to build context.
But I don’t think you’re all lying. And you are very likely not all incompetent either. I wish I could sit down with you and have you show me examples of code where explicit types are detrimental to readability, so I could examine if there are cases that exist but are somehow being mitigated by a code style policy that I’m taking for granted.
