Java.next
I quite agree with him.
What mistake most people make when they compare Java with other programming languages and talk about how bad Java is is that they only talk about the Java programming language but not Java platform. It is not really fair to talk about Java without thinking its ecosystem including the platform, frameworks, libraries, tools, etc. As Erik says in the talk above, if you use vim to programme Java code, it's like pounding a nail with your head. People complain about static typing but with help from proper IDEs, it can actually increase programming productivity not to mention of easier debugging.
What about Java's verbosity? Programming is a conversation between a computer and a human. Imagine, instead of using a human language, we use all mathematical symbols to talk, would it be so easy to understand?
What does this picture mean? It might be 2? or victory? But if I say, "two" or "victory" then it's clear. There are places where simple symbols and icons are helpful (think about iPhone app icons and math problems) while there are some other places where verbose instructions are helpful. Verbosity in Java, in fact, helps you understand the code written by you or others. It doesn't mean there is no room for Lambda (closure) in Java though. Java with Lambda can result in much simpler code, but without it, it's still not that bad to read. Anyway, Lambda will come to Java soon (JDK 8 ), and I'm looking forward to it as it looks much nicer than its initial state. I do functional programming using Java in many places in my project so it would be nice to have Lambda, but without it, I'm still fine. What I more desire to have in Java is a way to retrieve the names of method parameters using reflection (or some other simple and easy way). I had to use ASM instead to solve this issue. Why do I need that? I needed it to develop JSON Statham, Java/Json mapper library, to use one of my projects that is mQlicker (audience response system). I can keep using ASM but it's a library to decompose and modify Java bytecode so there can be some situations where I cannot use it (e.g. Android uses its own bytecode that is dalvik bytecode, and ASM doesn't support it as far as I know).
Some people perhaps complain about the design patterns. If you don't need it, you don't have to or should not use it. We do not programme to apply the patterns. We do programme to solve our problems. We can use the patterns if these solve our problems. If applying it causes more problems, don't use it. I don't try to apply the patterns first. I code to solve a problem and later find my solution is actually some pattern A. It's usually like this. When I know exactly what pattern solves my problem, then of course, I use it, but I've never coded in order to use the patterns I know unless I need to write some example code to show how to use the patterns.
Some others may say like "Framework A is too heavy and complex. It took me more time to learn than developing apps and still requires more time to develop than the time spent on development without it." If it's the case, you should not use it. You've got lots of other choices so why bother to stick to only one thing? Albert Einstein said that repeating the same thing over and over again and expecting different results is insane. You can try something else. Usually, if you feel like that about the framework you're using, it's either you don't need it or you're not good enough to use it. "you don't need it" might mean the framework really sucks or it's not appropriate to your project. "you're not good enough to use it" probably means "you're not good enough YET to use it and need more knowledge to learn it then will be able to use it properly." Either way, try something else as well then you will possibly have some more idea of what to use. You don't have to repeat the same thing and have the same bad result.
I know there are too many bad examples of Java code and projects which are enough to make a really bad impression of Java on people who try to learn and use it. Fortunately, owing to the Internet, we can easily find good ones too these days. If I read only those terrible Java code examples and books, I would probably not use Java. So don't read too old Java books and go to some developer's websites to find some good Java examples. I also have to admit that there are really horrible and poorly designed APIs in Java (e.g. JAXP DOM API, java.net.URL, java.util.Calendar, etc.). There are also no immutable collections in Java JDK (there are unmodifiable collections but these are not really immutable since the collection passed as the parameter of Collections.unmodifiableXxx() methods can be modified by the user of the Collections utility class or any objects having the reference to the parameter collection). These are bad, but it can be solved by using other nice libraries (e.g. XStream, XOM, dom4j, Joda-Time, DATE4J, Apache Commons, Guava, etc.).
Don't be extremist. Object-oriented programming or functional programming is not the answer to your problems. You may need both to solve your problem or neither might help you solve your issue. It's just one of the tools you can use to solve your problems. Don't waste your time to argue which is superior to the other.
By the way, I don't like Java. It's just a tool. I can use whatever tools that solve or help me solve my problems. Wouldn't you feel weird if I say "I like a hammer but hate a screwdriver"? I neither like nor dislike these tools. I just need a hammer to put a nail into a well and a screwdriver to tighten a screw. Wouldn't it look so stupid if I attempt to pound a nail with a screwdriver or try to tighten a screw using a hammer? I use Java as it is just a proper tool to solve some of my problems. For other problems, I use some other tools.
Hmmm, come to think of it, I'd rather not waste my time on this kind of topic anymore.