> It's a full word, not a single letter operator. Its uses add up to noise pretty fast. But it's still 1) a different color; 2) always in the same place (along

> It's a full word, not a single letter operator. Its uses add up to noise pretty fast. But it's still 1) a different color; 2) always in the same place (along with static/final). For me to call something "noise", it must be unpredictable, or otherwise hard to avoid. A thing consistently at the start of each line and in a different color is very easy to avoid. > is your screen real estate situation really that desperate you can't afford a single new line? It's not screen real estate, it's how much effort you have to put in to find something. In Java, to find whether a thing is public, I have to just look left a bit. In C++, I have to scan multiple lines upwards for a 'public:' or 'private:'. (but vertical screen real estate is indeed a ton more expensive than horizontal) > Your brain have an amazing ability to filter out conversations My whole point is that the filtering is extremely trivial. Not as trivial as ignoring whitespace at the starts of lines, sure, but still very much not a problem, at all. > By this argument why write functions then or generics or really any abstraction at all? Every function invocation or generic instantiation is unique and contains novel information, so why not write the whole thing each time for extra readability? That information is both very trivially derived, and not that much more useful than the parts. A single type annotation, however, can save a long time on trying to track down what even you're working with. Arbitrary expressions are much more complex, requiring you to either need to use the IDE to assist in understanding (and I can surely scan plain text much faster than any doing interaction with an IDE), or have read & understood much of the preceding/surrounding code to be able to infer the types of things. > Because severing the type system into primitives and classes at the language level was never a good idea. Actually, I prefer them being separated. But that's the performance-wanting part of me, not the language-design one. If done well (which java of course hasn't), it allows for a bunch of trivially achievable performance improvements, and shouldn't complicate usage. (C# has that with class vs struct, but I don't know enough to comment on how easy they are to use) > That's the praises of the JVM being sung here, not java the language. Not every language can performantly map to the JVM though. And, given that the JVM was made for Java, I think it's very fair to praise java for good things about it. End result is the same. > <T implements some_interface> ok yeah those are rough, with all the different variations that exist. But luckily they're used very infrequently, and are nevertheless not that hard to understand in practice. > Java frameworks are some of the most bloated lovecraftian horrors I have ever seen in my life Even with those around (and oh boy are they), there are plenty of actually good frameworks/libraries too. > Again, a feature of the JVM. A compiled .class knows nothing about Java or any other language it happened to come from. I usually prefer source code as documentation over actual documentation, so the library source being in the same language that I'm writing is very valuable to me.