Yep. I'm reminded of the advice "Favor Composition over Inheritence", which begs the question "When can we not use Composition and need to fall back down to Inheritence?" and it turns out the answer is that you can always use composition with the exception if you are relying on someone else's library that does it wrong and you can't change it.
Dependency injection and currying both do the same thing, and they are both useless most of the time just like Inheritence. You want to avoid nesting as much as possible. We should be rejecting dependencies. We should be returning values and passing them through functional pipelines.
lmao, is this satire? We should be using whatever abstraction is easiest to reason about. Sometimes that's apeasing the primate brain with objects and things, sometimes it's shoving those things through a pipeline.
Free yourself from the dogma, just do what makes sense.
> We should be using whatever abstraction is easiest to reason about
I dare mention Rich Hickey and his talk “Simple Made Easy”, and postulate that we should be using whatever abstraction is _the simplest_ (not the easiest one) to reason about, to which the grand parent rightfully refers, as far as I understand.
Objects are easy to many, but far from being objectively simple.
I would have linked the Principle of Least Power[0], but same idea. Rich certainly fleshes the idea out with more examples and I deeply respect his opinions.
I can't find it but there once was a blog that expressed this as: Reddit is a site where you can talk about anything with the exception of a few banned topics. Voat(might have been another reddit clone?) is a much less popular site where you can talk about anything. What do they talk about on Voat? Only the few topics banned on reddit.
While is strictly more powerful than for, for is strictly more powerful than foreach, foreach is strictly more powerful than map. And yet 95% of the time, the power in map is sufficient. Therefore 95% of the time you should use map. When you encounter a foreach, you should be expecting non-purity. When you encounter a while, you know that it's doing some recursive operation that requires that power.
This let's you reason about it. This allows you to compose these less powerful things.
But why do you have to curry to inject your dependencies? Dependency injection is satisfied by moving internal constructs in your function or method into parameters, no?
That's the style that functional programmers prefer. It makes it slightly easier to work with as you can now pass them together as one. Most OOP dependency injection is done through interfaces, but with the functional approach where you have functions as first class citizens you can just pass functions around. And as the best interface is a one function interface, that's the ideal way to do it.
The point being, essentially they are the same thing, they hold the same power, and it's just a stylistic difference.
I’m still not seeing it. As a Java dev by day, I see DI mostly through the lenses of Hollywood principle and IOC containers, neither of which bear much resemblance to currying (as I see it). When it comes to something like DI frameworks, currying is certainly not as powerful, but I don’t think that’s what you mean. Currying seems much more related to something like the builder pattern. Maybe there’s some article you know of that I could read? Googled around but didn’t find anything.
So there is two types of DI, one way automatically wired through an IOC container, and the other manually wired through constructors. They both are the same thing, but one uses some configuration and magic to make it easier to pass around these interfaces.
Mark Seeman's blog[0][1][2](many more related articles, these are particularly related) helped me grasp some of this stuff.
Dependency injection and currying both do the same thing, and they are both useless most of the time just like Inheritence. You want to avoid nesting as much as possible. We should be rejecting dependencies. We should be returning values and passing them through functional pipelines.