4 ms·

Stop trying to make Python Java.

NewMountain 5y ago
100% this. Having worked on projects using and not using DI in several languages, I'd prefer a world in which we just say no to DI. What it offers, relative to the indirection and cognitive overhead has almost always been net negative.
- tored 5y ago
  How is DI a cognitive overhead?
  - mkl95 5y ago
    OP mentioned Python, and I agree that it's a cognitive overhead in that particular case, in the sense that it's an abstraction that can be avoided. If you are using something like Java or C++ then it's easy to see the benefits (some C++ developers would disagree though, read https://accu.org/journals/overload/25/140/pamudurthy_2403/ https://accu.org/journals/overload/25/140/pamudurthy_2403/).
  - pydry 5y ago
    The extra levels of indirection mean more code. Python programs are about 30-40% shorter than Java equivalents. More code = more cognitive overhead
    - a3w 5y ago
      I have not found a renown C-ish language that is more verbose than Java, so that comparison is not that strongly helpful.
    - ivanche 5y ago
      Do you have any proof of that? 40% is a pretty strong claim.
- ivanche 5y ago
  What do you suggest instead? new operators everywhere? Service Locator? Global Singletons everywhere? Honestly, I don't know how you came from "my object needs objects A, B, and C to work" to the "it's cognitive overload". Your object still needs A, B and C to work, just with any other approach it's implicit which is spooky action at a distance in its finest and way more cognitive load.
  - garethrowlands 5y ago
    The answer is that your "composition root" constructs the objects using normal code. Usually the composition root is the `main` function. def main: a = ... b = ... c = ... my_object = MyObject(a,b,c) my_object.do_something() If you think it's ugly in `main`, then extract to another function: def main: my_object = make_my_object() # constructs my_object as above my_object.do_something() I've used this pattern extensively in Kotlin and also php (ew). It works well in pretty much any language.
    - ivanche 5y ago
      I agree with you completely! As the matter of fact, I prefer this approach. But that is dependency injection at its finest, and something that NewMountain above said is "cognitive overhead" and "indirection".
      - rodelrod 5y ago
        I can't speak for NewMountain but I assume he was talking about using a DI framework or container (e.g. Spring) where dependencies are defined declaratively and the framework handles the instantiation. This is what brings the indirection and the cognitive overhead.
    - necovek 5y ago
      If a, b and c are MyObject's "dependencies", that's dependency injection. If MyObject has no other dependencies (produces no side effects other than on a/b/c), it is fully dependency injected. Magic, monkey-patching mess of dependency injection libraries is terrible. Dependency injection as a concept is simple functional approach to imperative and OO programming.
- jseban 5y ago
  I agree, here's a presentation from a guy who went full circle in Ruby: https://www.youtube.com/watch?v=ewIbYQ-QuC0&ab_channel=Confreaks https://www.youtube.com/watch?v=ewIbYQ-QuC0&ab_channel=Confr...
necovek 5y ago
That was already done with Zope3. A lot of good stuff in there, but why use Python then?

100% this. Having worked on projects using and not using DI in several languages, I'd prefer a world in which we just say no to DI. What it offers, relative to the indirection and cognitive overhead has almost always been net negative.

tored 5y ago
How is DI a cognitive overhead?
- mkl95 5y ago
  OP mentioned Python, and I agree that it's a cognitive overhead in that particular case, in the sense that it's an abstraction that can be avoided. If you are using something like Java or C++ then it's easy to see the benefits (some C++ developers would disagree though, read https://accu.org/journals/overload/25/140/pamudurthy_2403/ https://accu.org/journals/overload/25/140/pamudurthy_2403/).
- pydry 5y ago
  The extra levels of indirection mean more code. Python programs are about 30-40% shorter than Java equivalents. More code = more cognitive overhead
  - a3w 5y ago
    I have not found a renown C-ish language that is more verbose than Java, so that comparison is not that strongly helpful.
  - ivanche 5y ago
    Do you have any proof of that? 40% is a pretty strong claim.
ivanche 5y ago
What do you suggest instead? new operators everywhere? Service Locator? Global Singletons everywhere? Honestly, I don't know how you came from "my object needs objects A, B, and C to work" to the "it's cognitive overload". Your object still needs A, B and C to work, just with any other approach it's implicit which is spooky action at a distance in its finest and way more cognitive load.
- garethrowlands 5y ago
  The answer is that your "composition root" constructs the objects using normal code. Usually the composition root is the `main` function. def main: a = ... b = ... c = ... my_object = MyObject(a,b,c) my_object.do_something() If you think it's ugly in `main`, then extract to another function: def main: my_object = make_my_object() # constructs my_object as above my_object.do_something() I've used this pattern extensively in Kotlin and also php (ew). It works well in pretty much any language.
  - ivanche 5y ago
    I agree with you completely! As the matter of fact, I prefer this approach. But that is dependency injection at its finest, and something that NewMountain above said is "cognitive overhead" and "indirection".
    - rodelrod 5y ago
      I can't speak for NewMountain but I assume he was talking about using a DI framework or container (e.g. Spring) where dependencies are defined declaratively and the framework handles the instantiation. This is what brings the indirection and the cognitive overhead.
  - necovek 5y ago
    If a, b and c are MyObject's "dependencies", that's dependency injection. If MyObject has no other dependencies (produces no side effects other than on a/b/c), it is fully dependency injected. Magic, monkey-patching mess of dependency injection libraries is terrible. Dependency injection as a concept is simple functional approach to imperative and OO programming.
jseban 5y ago
I agree, here's a presentation from a guy who went full circle in Ruby: https://www.youtube.com/watch?v=ewIbYQ-QuC0&ab_channel=Confreaks https://www.youtube.com/watch?v=ewIbYQ-QuC0&ab_channel=Confr...

necovek 5y ago

That was already done with Zope3. A lot of good stuff in there, but why use Python then?