3 ms·

> (Tuple unpacking is the clean way, but that has only recently been added.) Oh, I agree with you there, but that doesn't change the fact that ref/out paramete

by curtis 9y ago

> (Tuple unpacking is the clean way, but that has only recently been added.) Oh, I agree with you there, but that doesn't change the fact that ref/out parameters were a much, much better than the way Java forced you to do it. I don't mean to imply that C# 1.0 was a good language even for the 90s, but it was a big practical improvement over Java. I think C# 2.0 is the first point where someone could make the claim that it was actually a good language, at least for that era.

Arwill 9y ago
The logic behind Java is that the language should not concern itself with technicalities, the JVM will take care of it. This principle goes both ways, the JVM can't optimize your code if you have already decided how it should behave. As i understood, that is why they never added the more technical features as MS did in C#. In principle if you want to return multiple values from a method, you can return them in an array, and in principle the JVM optimizer will take care of the array. That is in principle, i don't know how good the optimizer got in this regard. But i still prefer Java for simplicity and readability.
- dtech 9y ago
  > In principle if you want to return multiple values from a method, you can return them in an array This is not viable. If I want to return e.g. an (error) code and string, the only Array you can put that in is an array of the root type (Object), losing all type-safety. In C# and Scala multiple return values use a Tuple class, with some syntactic sugar to easy create and read them. It will eventually be in Java [1], it just takes decades. It also has very little to do with the optimizer, there's not reason why the JVM couldn't support & optimize it. [1] http://openjdk.java.net/jeps/305 http://openjdk.java.net/jeps/305
- olavk 9y ago
  Optimization is not the issue. It is not possible in a strongly typed language to return multiple heterogeneous values in an array. That is why we have tuples.

by curtis 9y ago

Arwill 9y ago

The logic behind Java is that the language should not concern itself with technicalities, the JVM will take care of it. This principle goes both ways, the JVM can't optimize your code if you have already decided how it should behave. As i understood, that is why they never added the more technical features as MS did in C#. In principle if you want to return multiple values from a method, you can return them in an array, and in principle the JVM optimizer will take care of the array. That is in principle, i don't know how good the optimizer got in this regard. But i still prefer Java for simplicity and readability.

dtech 9y ago
> In principle if you want to return multiple values from a method, you can return them in an array This is not viable. If I want to return e.g. an (error) code and string, the only Array you can put that in is an array of the root type (Object), losing all type-safety. In C# and Scala multiple return values use a Tuple class, with some syntactic sugar to easy create and read them. It will eventually be in Java [1], it just takes decades. It also has very little to do with the optimizer, there's not reason why the JVM couldn't support & optimize it. [1] http://openjdk.java.net/jeps/305 http://openjdk.java.net/jeps/305
olavk 9y ago
Optimization is not the issue. It is not possible in a strongly typed language to return multiple heterogeneous values in an array. That is why we have tuples.