4 ms·

I'm with you on this. Dependency injection seems to me to replicate some of the features of interfaces while introducing complexity because the injection is ind

by orisho 6y ago

I'm with you on this. Dependency injection seems to me to replicate some of the features of interfaces while introducing complexity because the injection is indirect -- instead of having code that initializes a different object, it all happens dynamically during runtime using reflection. An antipattern as far as I'm concerned. It seems to achieve little or no gain at a very high cost.

throwaway894345 6y ago
It sounds like people just want a little bit of dynamic typing to assemble their object graph or something, but that's such a small (possibly negative) value add for such a steep price (everyone who might touch this software--new team members, system administrators, whoever takes over maintenance, etc--now needs to know the DI framework for even the most basic troubleshooting).
isbvhodnvemrwvn 6y ago
It doesn't have to happen at runtime. For instance in Java you have annotation processors which generate the boilerplate for you (in DI space I'm only aware of Dagger 2 that does it). It's a bit inconvenient but you can easily audit what's going on. That being said I somehow doubt a similar tool is used with go.
specialist 6y ago
Me three. DI and IoC are for people ignorant of or hostile towards composition. Further, aspects and reflection are for those unwilling or unable to make reasonable architectural assumptions. Said another way, meta programming is for personal projects. And maybe for small, disciplined, high trust teams. Most devs are average (axiomatically) and most projects are CRUD or scraping. So choice of these tools is self soothing to mitigate inferiority complexes. Like Mensa.
- throwaway894345 6y ago
  > DI and IoC are for people ignorant of or hostile towards composition. This isn't helped by the messy terminology. "Dependency Injection" is literally another term for "composition", but dependency injection frameworks imply automating the composition of one's object graph. However, people who like these frameworks don't seem to be aware that they can more easily compose their object graph using the structures available in most general purpose languages (literals for lists, maps, structs, etc as well as function calls and so on). Arguably there's some repetition in constructing an object graph (initializing a list of objects that vary only slightly) that one might want to DRY up, but we already know how to do that with helper functions in host languages, and anyway this is just boilerplate--it's almost certainly not where your bugs are, and it's not where your developers are spending their time. A framework introduces a bunch of complexity at the top level (near main()) i.e., the stuff that everyone from developers to testers to operators/sysadmins will probably need to dig into at some point, and all that for no material advantage to anyone.
  - specialist 6y ago
    Agree on all points. VRML-97 is the near pinnacle of human achievement, for declaring scene graphs, a special use case of object graphs. It had reuse. It had patch cords (specify non parent-child relations). It only lacked path expressions. I really I wish I could tell younger me to publish my own VMRL successor, way back when. Young me forfeited when confronted by XML's JavaScript-like metastasis, which had overwhelmed all rationale human endeavors. Then maybe I could have spared humanity the indignity of JSON and kin. Had I only known that all bouts of irrational exuberance eventually implode...

by orisho 6y ago

throwaway894345 6y ago

It sounds like people just want a little bit of dynamic typing to assemble their object graph or something, but that's such a small (possibly negative) value add for such a steep price (everyone who might touch this software--new team members, system administrators, whoever takes over maintenance, etc--now needs to know the DI framework for even the most basic troubleshooting).

isbvhodnvemrwvn 6y ago

It doesn't have to happen at runtime. For instance in Java you have annotation processors which generate the boilerplate for you (in DI space I'm only aware of Dagger 2 that does it). It's a bit inconvenient but you can easily audit what's going on. That being said I somehow doubt a similar tool is used with go.

specialist 6y ago

Me three. DI and IoC are for people ignorant of or hostile towards composition. Further, aspects and reflection are for those unwilling or unable to make reasonable architectural assumptions. Said another way, meta programming is for personal projects. And maybe for small, disciplined, high trust teams. Most devs are average (axiomatically) and most projects are CRUD or scraping. So choice of these tools is self soothing to mitigate inferiority complexes. Like Mensa.

throwaway894345 6y ago
> DI and IoC are for people ignorant of or hostile towards composition. This isn't helped by the messy terminology. "Dependency Injection" is literally another term for "composition", but dependency injection frameworks imply automating the composition of one's object graph. However, people who like these frameworks don't seem to be aware that they can more easily compose their object graph using the structures available in most general purpose languages (literals for lists, maps, structs, etc as well as function calls and so on). Arguably there's some repetition in constructing an object graph (initializing a list of objects that vary only slightly) that one might want to DRY up, but we already know how to do that with helper functions in host languages, and anyway this is just boilerplate--it's almost certainly not where your bugs are, and it's not where your developers are spending their time. A framework introduces a bunch of complexity at the top level (near main()) i.e., the stuff that everyone from developers to testers to operators/sysadmins will probably need to dig into at some point, and all that for no material advantage to anyone.
- specialist 6y ago
  Agree on all points. VRML-97 is the near pinnacle of human achievement, for declaring scene graphs, a special use case of object graphs. It had reuse. It had patch cords (specify non parent-child relations). It only lacked path expressions. I really I wish I could tell younger me to publish my own VMRL successor, way back when. Young me forfeited when confronted by XML's JavaScript-like metastasis, which had overwhelmed all rationale human endeavors. Then maybe I could have spared humanity the indignity of JSON and kin. Had I only known that all bouts of irrational exuberance eventually implode...