3 ms·
I feel the same way: author wants Java and was hoping only for a better Java: compatible with most patterns, tools, even libraries, but addressing some of his p
by ptero 8y ago
I feel the same way: author wants Java and was hoping only for a better Java: compatible with most patterns, tools, even libraries, but addressing some of his pet frustrations. When Kotlin did not satisfy his hopes he got disappointed. Understandably, but I do not see it as the Kotlin problem.
The other problem I have with this post is that it did not state desires/hopes up front. The intro only mentions compile-time null-safety and less boilerplate (for which many languages are better than Java), then adds his desires throughout the text. Thus his complaints seem not a thought through list of failures to satisfy specific desires, but just randomly throwing rocks at vague targets. My 2c.
- riku_iki 8y ago> a better Java: compatible with most patterns, tools, even libraries, but addressing some of his pet frustrations. But is this a main pitch of Kotlin?..
- pdpi 8y agoBeing compatible doesn't mean that compatibility is the path of least friction, especially when it clashes with good design. A good example of that tension is the final/open thing: Wonky frameworks abuse inheritance and force you to use open all over the place, but Effective Java suggests you should make every class/method final unless you specifically design it to be extended.