That's exactly what I was thinking. I've not used Clojure specifically, but in the sitations where OO people use dependency injection I tend to use a free monad with multiple interpreters. I'm yet to make serious use of an algebraic effect system, but that would make this even simpler and more composable.
After using Clojure for a while, i've found that some of the ideas from OO still apply to larger systems. It just happens that most programs, because of the functional programming style, dynamic typing, and Clojure's abstractions, end up too small / simple to warrant introducing them into the codebase.
Well, "dependency injection" is a pompous term. This just relies on two simple clojure features: protocols and namespace introspection to easily configure a program. It's definitely not a framework, but I see how using the term DI can be a bit scary and off-putting.
I'd like to think it's common for programs to need extensions & plugins, without it deriving from "the point of of clojure".
DI isn't scary sounding, it's just unnecessary most of the time I've seen it, especially in public facing APIs that third party developers use. Most classes don't have so many varied amounts of diverse dependencies where you have to resort to convoluting the constructors for the sake of testing. You could just use inheritance.
Dependency injection takes a thing that should be one line of code and makes it twenty lines. It requires third party developers to have know all kinds of unnecessary implementation details. DI is a piece of shit that should be a measure of last resort and if you find yourself resorting to it often maybe question your entire architecture.
I have yet to meet one person to convince me that DI is not unnecessary in most cases. It always boils down to making writing tests easier. Well you should not shit all over your public APIs for the sake of testing.
Comments
This is just my opinion, but if one is writing dependecy-injected frameworks in Clojure, then they're missing the point of Clojure.
That's exactly what I was thinking. I've not used Clojure specifically, but in the sitations where OO people use dependency injection I tend to use a free monad with multiple interpreters. I'm yet to make serious use of an algebraic effect system, but that would make this even simpler and more composable.
Could you please share a few examples?
After using Clojure for a while, i've found that some of the ideas from OO still apply to larger systems. It just happens that most programs, because of the functional programming style, dynamic typing, and Clojure's abstractions, end up too small / simple to warrant introducing them into the codebase.
Well, "dependency injection" is a pompous term. This just relies on two simple clojure features: protocols and namespace introspection to easily configure a program. It's definitely not a framework, but I see how using the term DI can be a bit scary and off-putting.
I'd like to think it's common for programs to need extensions & plugins, without it deriving from "the point of of clojure".
DI isn't scary sounding, it's just unnecessary most of the time I've seen it, especially in public facing APIs that third party developers use. Most classes don't have so many varied amounts of diverse dependencies where you have to resort to convoluting the constructors for the sake of testing. You could just use inheritance.
Dependency injection takes a thing that should be one line of code and makes it twenty lines. It requires third party developers to have know all kinds of unnecessary implementation details. DI is a piece of shit that should be a measure of last resort and if you find yourself resorting to it often maybe question your entire architecture.
I have yet to meet one person to convince me that DI is not unnecessary in most cases. It always boils down to making writing tests easier. Well you should not shit all over your public APIs for the sake of testing.
In the article, it has nothing to do with what is commonly referred to as DI in the Java world.
It's just a rather a simple mechanism to provide an extension mechanism for a daemon.
"The only place you should be injecting dependencies is behind a dumpster in an alleyway." - someone on #clojure