Hacker News Reader

Comment by michaelochurch | Hacker News Reader

Why do you need all this complexity in order to do that?

I feel like one of Java's problems is that these design patterns have taken it away from the language's intended design. It wasn't intended to be a dynamic language. Most of Java's ugliness is an extremely incompetent Greenspun's Tenth Rule: solving of problems where the solution is "use a different language, like Clojure or Scala".

There are occasions where Java and C++ are the right languages to use, but most of the time when people are using these over-complex frameworky solutions, it'd be much more elegant to use a different language, and the code would be more legible.

View on HN

Mentally rewriting the beginning of your last paragraph to "Sometimes Java or C++ is the right language to use, but most..." made it make considerably more sense to me.

As it stands, I think the double-aren't is colloquial or a mistake; I honestly couldn't follow the meaning of the overall triple-negative. :) Not trying to be a jerk - I love reading your stuff, but I spent more than a minute thinking about that sentence before just guessing it from the rest of what you said.

Good catch. It was a mistake. Two or four negations would have been semantically correct (if ugly). Three is wrong.

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

[2] http://en.wikipedia.org/wiki/Java_(programming_language)

[3] http://en.wikipedia.org/wiki/Scala_(programming_language)

[4] http://en.wikipedia.org/wiki/Clojure

But 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!".

IMHO, Java combines the worst of statically typed and dynamically typed programming languages. To paraphrase Rob Pike, programming in Java is like dotting all the i's and crossing all the t's in a fairly complex contract but at runtime, the contract can be overridden by dynamic classloading. So you do not get the efficiency of a statically typed language (because the compiler cannot make certain assumptions about the types / classes) nor do you get the expressiveness of a dynamically typed language.

In the case of DI, I would observe that no programs in other languages seem to require or even use this pattern. If you need to implement LGPL at the language level, a better abstraction is modules with contracts... or even better a proper metaobject protocol a la Lisp.

DI is also used quite heavily in C#. And in most - if not all - functional languages, one of the flavors of dependency injection (what a C# programmer would call method injection) is so pervasive that it doesn't even have a name. People just think of it as an idiom rather than a design pattern.

If I may speculate, I suspect that the reason why DI is discussed so much more in the big enterprise programming languages isn't because of the languages so much as the problem space. Enterprise software has a tendency to be enormous, live for a very long time, and involve stitching together components from a variety of sources, none of which are being modified or replaced on exactly the same schedule. Hard-coded dependencies always have the potential to be a maintenance hassle, but that kind of situation compounds the problem immensely. The promise of DI - that if you follow it scrupulously you can produce software that's so easy to modify that you might even be able yank out and replace entire modules without so much as a recompile - becomes very attractive in that kind of situation.

It's also a huge win for huge teams. If you make good use of dependency injection then it's easy for different teams to develop different modules that depend on each other in parallel. All you have to do is whip up some stub implementations of the modules that aren't available and get to work.

Reply on news.ycombinator.com