The new and improved is the old and busted: Dependency Injection

One of the things that's been the rage in the past few years in the Java scene (and it seems that it's mostly the Java scene that has a preoccupation with this) is dependency injection. The idea that you can have a loosely-coupled runtime system such that you as a programmer live in nirvana and everything is rainbows and unicorns.The problem is that we've tried to do this a number of times in the past. We just didn't call it "dependency injection."In the case of really old school case you just called this "global variables."Later we had things like Ada Smalltalk where the entire environment was the program. If you had a an object of whatever type you could send it messages and simply hope for the best. With Ada Smalltalk it wasn't "injection" as much as "ambient," for the way it works it's essentially the same.In each of these cases you had a system that had little to no compile-time checking of stuff. You had a system that could appear to work, but the complexity of testing it with certainty is daunting.Could you test it can make working code? Sure you can -- without a doubt. The problem is that you've traded off the part that's easily solvable, the static linking, for a mess of loosely connected spaghetti. Spaghetti can work... but when it doesn't it's a pain in the tuchus.This has been gnawing in my craw based on the stabilization of a bunch of dependency injected code at work. For how long we're spending trying to get the dependency injection working we likely could have had a real working system already.What's old is new again... but it brings with it the same problems that we had in the past.If only we would learn.Note: After publication it was pointed out that I wasn't really talking about Ada, but rather Smalltalk. Oops! Sorry! The two languages are as different as can be and I have no rationale to have confused them.