3 ms·
Design Patterns: 1994 [1] Java: 1995 [2] Scala: 2003 [3] Clojure: 2007 [4] Unless these hypothetical developers of yours are time travellers, your propo
by lusr 14y ago
Design Patterns: 1994 [1]
Java: 1995 [2]
Scala: 2003 [3]
Clojure: 2007 [4]
Unless these hypothetical developers of yours are time travellers, your proposed solution wasn't an option for more than half of Java's life. Sometimes Java is 90% of what you need and you just get on with the other 10% because the alternative (learning a new language, finding a new team or training an existing team to use it correctly, etc.) is simply not worth it to anybody with real world time/quality/scope constraints.
[1] http://en.wikipedia.org/wiki/Design_Patterns http://en.wikipedia.org/wiki/Design_Patterns
[2] http://en.wikipedia.org/wiki/Java_(programming_language) http://en.wikipedia.org/wiki/Java_(programming_language)
[3] http://en.wikipedia.org/wiki/Scala_(programming_language) http://en.wikipedia.org/wiki/Scala_(programming_language)
[4] http://en.wikipedia.org/wiki/Clojure http://en.wikipedia.org/wiki/Clojure
- martinced 14y agoBut we're in 2013 now. Not 1994/1995 anymore. I don't care if in 2002 I couldn't use Scala. That was 11 years ago and it's not exactly an excuse for not using Scala today. There are companies working in finance today who are switching entire Java teams to Clojure. It's precisely because they have real-wold time/quality/scope constraints that they are doing so. Most Java codebase became what Rich Hickey calls "The elephant in the room". By switching to Clojure they can reduce the size of their codebase by a factor of ten, making the elephant easier to manage. So we're back to square one: the real issue is that there are still people regularly posting links to "design patterns" and "dependency injection" that get upvoted because a large part of HN only knows about Java/C# + ORM + XML + SQL hell... As long as people will be doing that, you'll be able to use your argument: "but, hey, in 1995 it was all the rage!".