On the other hand, it leads to some people abusing the static type system: They just randomly change types until it somehow compiles, without thinking about what their doing.
On the other hand, it leads to some people abusing the static type system: They just randomly change types until it somehow compiles, without thinking about what their doing.
ArrayList<Map<String,Object>> myArrayList = new ArrayList<Map<String,Object>>();
Could have been just:
ArrayList<Map<String,Object>> myArrayList = new();
or even better:
ArrayList<Map> = new(); <- if you don't care what the type of map is.
ArrayList<Map<String,Object>> myArrayList = new ArrayList<>();
ArrayList<Map> myArrayList = new ArrayList<>(); works already today.
> if you don't care what the type of map is
You can use raw types, it works perfectly fine (just generates a compiler warning). For explicitly being unspecific, you can also use a type wildcard (`?`).
Java has a particularly verbose and clumsy type system.
You need to specify the class twice on the same line, because Java can't figure it out on its own.
That's what I mean—Java's type system is verbose and clumsy, because it doesn't bother trying to figure out things it could figure out, forcing the programmer to be redundant and repeat themselves all over the place. The fact that it's 2 separate operations to the compiler shouldn't dictate anything about the language.
This makes operations like this intuitive:
Animal results = new Dog("Lassie");I did that, too, when I was inexperienced with C++. Especially with const, but also with * and &. But somehow it "clicked" at one point and I don't have that problem anymore.
In recent times, I've found static type systems to helpfully nudge me in the direction of correct code. I was pleasantly surprised by TypeScript. Also, in modern C++, if you use unique_ptr, shared_ptr, try to get rid of naked pointers, and use value types and RAII if possible, the code ends up a lot cleaner. I've found a couple of places where ownership was unclear, and I previously had circular references or dangling pointers as a result.
And anecdotically, the way people program in Haskell is basically, write what you mean, and then fix it until it compiles; it will likely also be correct.