> If your data have a complicated type like List<Set<Pair<Foo, ? extends Bar>>>, you have to copy-paste this type everywhere, without a way to name it succinctly.
Java has had generic type inference since at least 7 [0], so all you need is <>
It's not perfect, but I believe it's been improved with each version.
[0] https://docs.oracle.com/javase/7/docs/technotes/guides/langu...
Yes, this is what I called "diamond operator".
I'm talking about a different use case where inference via assignment does not work, e.g. a method declaration:
public List<Set<Pair<Foo, ? extends Bar>>> combine(
List<Set<Pair<Foo, ? extends Bar>>> a,
List<Set<Pair<Foo, ? extends Bar>>> b
) {...}
type Quux = List<Set<Pair<Foo, ? extends Bar>>>;
public Quux combine(Quux a, Quux b) {...}
Re:Habits of Expert Software Designers
by Noumenon72 on Tuesday October 08, 2019 @10:22PM
(#21199389)
Huh, I always thought I was doing Java wrong when I would try to write the equivalent of four Python list comprehensions in a row and end up declaring a ton of List<Set<Pair>>> things. Didn't think to blame the language.
Another problem is that Java lacks type aliases. If your data have a complicated type like List<Set<Pair<Foo, ? extends Bar>>>, you have to copy-paste this type everywhere, without a way to name it succinctly.
On top of that, Java lacks type inference, even the weakest syntactic form. This is why you often need to write a long declarations, so long that they exceed the space you may have saved by factoring out a small function. Lombok and the diamond operator somehow alleviate that, but not completely.
The lack of pattern matching, or named arguments, or null vs Optional vs Result, goes without saying.
This makes Java a very verbose language, even if the logic of your code is streamlined and economical. In many standard library APIs, it is not.
(Hence Kotlin, obviously, or Scala if you can tolerate the build times.)