Java is notorious as it has very clumsy syntax. Simple arraylist of dictionaries declaration looks like this:

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.

As others have mentioned, there's the diamond operator which has been around since Java 7.

> 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 (`?`).

That is almost literally what Java does.

ArrayList<Map> myArrayList = new ArrayList<>(); works already today.

Note in Java8, you could just use:

ArrayList<Map<String,Object>> myArrayList = new ArrayList<>();

The diamond operator is available since Java 7. Tripped me up too.

> making fun of Java for its verbosity and clumsiness

Java has a particularly verbose and clumsy type system.

What do you mean it has a verbose type system?

Person myPerson = new Person("My", "Name")

You need to specify the class twice on the same line, because Java can't figure it out on its own.

The left hand side only reserves the memory, the right hand side actually initializes the object. A bit redundant I agree, but to the compiler it is two atomic operations.

It is two separate operations, but in many other languages the compiler is smart enough to figure out that they'll be the same type (and allow you to specify it when they're not)

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.

I agree it could be more clean, but the way it is designed allows for immediately understandable semantics when dealing with inherited types (which everyone though was the future during Java's Formative years).

This makes operations like this intuitive:

    Animal results = new Dog("Lassie");

It does, but they should have found a solution which allowed that, as well as not be redundant in the more common case where the two classes are the same. Hence Java's type system being verbose and clumsy.

Nice static type systems don't make you write out nearly as much crap as Java's does. It's pretty common for them to be able to completely infer the type of every expression in the program. If you're worried about the mere coherency of the concept of a "verbose type system", well, it was just a clever turn of phrase.

> They just randomly change types until it somehow compiles, without thinking about what their doing.

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.