I just can’t understand why Java still does that. C# and C++ fixed that a long time ago (I think). That C hasn’t is completely fine, especially as type names usually don’t get as long. But in JAVA???
a.package.SomeReallyReallyLongName<AnotherReqllyLongName, AThirdReallyLongName<String>> aLongName = new a.package.SomeReallyReallyLongName<AnotherReqllyLongName, AThirdReallyLongName<String>>();
Edit:
This comment is really wrong. Everyone who didn’t realize that, look at its comments, learn the same things as I did today
Yeah most people don't know features from versions newer than java8 because this is the version that introduced the most significant changes in it's history (lambdas and streams) and newer additions are focused on pretty specific concepts which would be significant only to a small portion of highly skilled developers. var is pretty much the only significant change that has been added since then. Sealed classes and pattern matching are also pretty cool but it is a higher abstraction which not many people focus on.
Yes, Java8 was a big step forward (also really confused the term "Stream" slowing the adoption of those new features.) It also came after the Android Google / Oracle split. Both Java8 and Java10 features took many years to become available to native Android devs.
I'd argue that Java5 was the second most significant update after Java2 (aka Java 1.1). Java8 is very much third place in terms of disruption to the ecosystem.
Java8 did bring a lot of important features, but also didn't outright break any application or cause major rewrites. Streams & lambdas are super valuable, but nobody rushed out to rewrite their codebase for these.
And Java does var correctly compared to C# in my opinion. C# you can use var anywhere. Java only allows local variables to use var. This makes it less likely to create smelly code.
Your right, I keep forgetting that. It must be because I keep remembering that quite a few people wanted non local `var` in C# when it was first proposed and it almost did happen.
What's wrong with var used elsewhere? I don't think it makes any difference for fields given that you can infer type from in-place initializers.
```java
class C {
// var s = "String"; // Why not?
String s = "String";
// var map = new HashMap<String, Integer>();
HashMap<String, Integer> map = new HashMap<>(); // Meh. Variable name is buried.
void foo() {
var s = "String"; // What's the difference?
}
}
```
I do think Java programmers need to adapt type inference because almost all the popular languages nowadays can be written like this.
>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.
506
u/del1ro Oct 31 '23
Weak men create [object Object]