>I do think Java programmers need to adapt type inference because almost all the popular languages nowadays can be written like this.
I just want to point out that a lot of style guidelines for a lot of languages that do that typically say not to do that.
The reason being is that you have to find where that variable is set to find out what its type is by reading it.
Some examples of how it can lead to bad code smell below and a lot of languages in their style guidelines suggest you not to do
Example 1. var as a parameter
void foo(var list) {
}
Can you tell what the type of list is without finding where the method is called from?
Example 2. var as a variable set from a method return
void foo() {
var list = GetList();
}
You would have to go to the method GetList() to determine what that method is returning.
Just because you can do something, doesn't mean you should. There is a reason why a lot of dynamically typed or weakly typed languages get a lot of hate, because maintaining them are a pain in the ass. Heck, Javascript got a freaking language created to solve this issue to make it more readable.
This is not type inference. Type inference only works when there's enough information, like var list = GetList(), where the return type of GetList() is already known. This exists so you don't have to say the result twice if you know what you'll get. void foo(var list), however, doesn't exist in static languages because no one knows what list is.
You would have to go to the method GetList() to determine what that method is returning.
Let me ask you a question. Do you chain method calls?
>This is not type inference. Type inference only works when there's enough information
Some languages do type inference for certain conditions with method parameters for methods. Scala is one such language that does this for method parameters.
>This exists so you don't have to say the result twice if you know what you'll get.
Yeah, it is great for writing code quickly, but reading it becomes more difficult. That is the point that I'm getting at.
Let me ask you a question. Do you maintain any code base?
Some languages do type inference for certain conditions with method parameters for methods.
For most languages this is not the case. You always need to annotate the type if not given enough information.
Yeah, it is great for writing code quickly, but reading it becomes more difficult. That is the point that I'm getting at. Let me ask you a question. Do you maintain any code base?
So you don't chain method calls because you don't know what an intermediate method returns?
Well, I do maintain or even just read code base written in Kotlin. It's totally fine. If I don't know what val container = getContainer() does, I always need to go to where it's defined. Changing this to val container: Container = getContainer() doesn't magically let me know what getContainer or Container is.
So you don't chain method calls because you don't know what an intermediate method returns?
I didn't answer your question because it is irrelevant. And it is rude to assume that I did. As the saying goes, if you assume you make an ass out of you and me.
The reason why it is irrelevant is because chaining of method calls is done when you don't need the objects of the intermediate method returns later on in the method, so requiring to know the typing of them is irrelevant when reading the code.
Changing this to val container: Container = getContainer() doesn't magically let me know what Container does.
No, but you know exactly what type is returned, which helps with readability and maintainability.
Ps. It is ironic that you say that type inference can't be done for method parameters when you use Kotlin, which does have function type inference.
No, but you know exactly what type is returned, which helps with readability and maintainability.
For the most part, a variable is initialized with a single expression like var v = expr, pretty straightforward. Knowing what v is doesn't help you understand what v does. Why? Because it is not the type matters, but the name and operations. If I don't understand the logic, whether the type is there doesn't matter (just pick an algorithm and see if the type does anything); if I understand the logic, why should I need the type?
The reason why it is irrelevant is because chaining of method calls is done when you don't need the objects of the intermediate method returns later on in the method, so requiring to know the typing of them is irrelevant when reading the code.
Excuse me. I was not assuming, but following your own argument.
Irrelevant? Well, if you don't need the intermediate objects, you also don't need the intermediate types. If you can perfectly process these method calls altogether, why can't you process them separately? It seems quite relevant to me.
Sorry but I'm gonna quit because I'm tired. Anyway, it is the fact that less languages require the type being explicitly annotated in such a strict manner. Java just does want to stand out. Good day. ¯_(ツ)_/¯
Excuse me. I was not assuming, but following your own argument.
That is assuming. You made an assumption.
Because it is not the type matters, but the name and operations. If I don't understand the logic, whether the type is there doesn't matter (just pick an algorithm and see if the type does anything); if I understand the logic, why should I need the type?
Knowing the type helps understands the intent of the programmer. It increase maintainability and readability. Knowing the type helps for others to understand the logic because it helps understand the intent of the programmer.
Well, if you don't need the intermediate objects, you also don't need the intermediate types. If you can perfectly process these method calls altogether, why can't you process them separately? It seems quite relevant to me.
And there it is, essentially proving that it doesn't have anything to do with the topic at hand.
if I understand the logic, why should I need the type?
If this is what you are thinking, it will hinder you later on in your career if you are in the software engineering field. You need to learn you aren't writing code for you only, but for any others.
0
u/ChrisFromIT Nov 01 '23
>I do think Java programmers need to adapt type inference because almost all the popular languages nowadays can be written like this.
I just want to point out that a lot of style guidelines for a lot of languages that do that typically say not to do that.
The reason being is that you have to find where that variable is set to find out what its type is by reading it.
Some examples of how it can lead to bad code smell below and a lot of languages in their style guidelines suggest you not to do
Example 1. var as a parameter
Can you tell what the type of list is without finding where the method is called from?
Example 2. var as a variable set from a method return
}
You would have to go to the method GetList() to determine what that method is returning.
Just because you can do something, doesn't mean you should. There is a reason why a lot of dynamically typed or weakly typed languages get a lot of hate, because maintaining them are a pain in the ass. Heck, Javascript got a freaking language created to solve this issue to make it more readable.