As for prior knowledge, that argument doesn’t fly. A lot of the verboseness of Java could be addressed VERY easily with clear syntax that doesn’t require a lot more prior knowledge. An example is getters and setters, which are very easy to understand in languages that have built-in support for concise syntax but Java has somehow ignored the advantage of concise syntax for 25 years.

Besides, if your argument is that Java doesn’t require “prior knowledge,” I beg to differ. E.g., correct usage of arrays vs. ArrayList.

The difference between arrays and ArrayList is simple: an array has a constant size known at the time of allocation.

Arrays vs lists is a thing in all languages, not Java. They just have different names (list, vector, sequence...)

Kotlin isn't terse.

This is a strong argument for Clojure. The language makes helpful and readable guarantees about data shape, and provides a wealth of functions that operate on its core data structures.

Kotlin has a bunch of inferred classes, and Java has a bunch of explicit ones. Clojure recognizes that data does not look like either of those: it’s fundamentally a sequential list of things or a key/value map of things. Everything else is a special case that only your program cares about, and it gives you the tools to build a system to work with them as generally or specifically as you need it to.

What makes a WindowLayoutEngine “a state-holding object with proper structures?” How is it different from “a data tree with proper structure,” except that the former includes methods inside the class instance while the latter relies on functions to operate on the data tree?

Solving problems and formulating a problem solving approach takes time. This is the important part of writing software. A few extra keystrokes are relatively minor in comparison.

"I want to write software, but I don't want to type too much", never made sense for me.

Such as?

"Java, by virtue of being more verbose, requires writing everything out explicitly, so you really have to expend some extra effort to make your code unreadable."

Boilerplate is what makes code unreadable. Getters, setters, backing fields, all that noise, takes lots of space getting in the way of grasping the meaning of the code. Java is too much about how instead of what.

The things that I write in a computer program’s code should correspond as closely as possible to what the program means - nothing more and nothing less. Java is terrible at this.