4 ms·
Exactly - I often read "easy changes" as "I don't have to think about all the implications of this" which is never good. Personally I find Java one of the easi
by lemming 16y ago
Exactly - I often read "easy changes" as "I don't have to think about all the implications of this" which is never good.
Personally I find Java one of the easiest languages to make functionality changes in just because of the excellent refactoring tools that are available. People always claim to feel restricted by the language when they use Java. If they're using emacs or Textmate to edit it then sure, I can see that. Personally, whenever I'm writing something other than Java I feel desperately restricted by the tools - editors that don't have semantic knowledge of the program structure and just treat it all as text seem unbelievably primitive to me now after years of using IntelliJ.
- davelnewton 16y agoRefactoring isn't a functionality change--functionality should stay exactly the same during refactoring; that's why unit testing makes refactoring easier. Functionality changes require expressiveness, something Java lacks, due to its superfluous ceremony. Functionality changes require an ability to clearly see where and how things are done, and this is obscured by the extra noise of Java. Java 5/6 went a fair ways to mitigating this... somewhat. And IDEs can help reduce extraneous noise (like IntelliJ's <~> for generics). But it's not eliminated, and it's not enough. Java still has an impoverished model of abstraction and OO, it forces me to repeat myself continually (and having an IDE do the grunt work of repetition doesn't help--nothing should have to do it), and that both slows me down, and obfuscates meaning. The tooling is the only thing that makes Java even remotely palatable.