6 ms·

This would be sooooo nice, especially in DI heavy languages like Java. It might not be turtles all the way down, but finding the final turtle can be so difficul

This would be sooooo nice, especially in DI heavy languages like Java. It might not be turtles all the way down, but finding the final turtle can be so difficult.

louzell 3y ago
It drives me nuts when systems are unnecessarily built with "magic DI" frameworks rather than initializer/constructor DI. Why is it so hard to pass a dep into the initializer? Make the initializer parameter a protocol/interface and you can pass a mock in at testing. And you can also grep the whole codebase for callers and find the exact concrete type passed in at runtime.
- inoffensivename 3y ago
  IMO, automatic DI frameworks were a big mistake. An idea that looks useful at the time, but actually leads to spaghetti mess code that is harder to maintain than it would be without any automatic DI.
  - erickf1 3y ago
    Agreed.
  - flaminHotSpeedo 3y ago
    I agree, though I'd say in the more general case that overly flexible DI frameworks are the broader problem. Designers will put much more thought into how best to interact with a framework, so start with a small, opinionated interface then consider extension feature requests on a case by case basis
- Blackthorn 3y ago
  Eh, it's not like it's much easier to find the last turtle in python. Or C++ when people are extensively using patterns like PointerToImpl*, which can really obfuscate things.
giovannibonetti 3y ago
Object orientation kills traceability. Classes are instantiated in one trace, then methods are called in another trace, and if something goes wrong in the latter, it is not trivial to find the wrong settings passed in the former. I think some functional programming languages solve that by running a good chunk (if not all) of the application in a single trace.
- gombosg 3y ago
  Yes, this is why we love functional programming! "What happened along the way" equals to the call stack, as long as there is no field mutation involved. And, of course, async/non-blocking calls, as tracing a call along different threads or promises may not be available all the time.
  - asimpletune 3y ago
    Yeah, exactly. Referring back to the DI comment earlier... In FP, "DI" is literally just calling a function.
  - gpderetta 3y ago
    """The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened."""
    - afiori 3y ago

This would be sooooo nice, especially in DI heavy languages like Java. It might not be turtles all the way down, but finding the final turtle can be so difficult.

louzell 3y ago

It drives me nuts when systems are unnecessarily built with "magic DI" frameworks rather than initializer/constructor DI. Why is it so hard to pass a dep into the initializer? Make the initializer parameter a protocol/interface and you can pass a mock in at testing. And you can also grep the whole codebase for callers and find the exact concrete type passed in at runtime.

inoffensivename 3y ago
IMO, automatic DI frameworks were a big mistake. An idea that looks useful at the time, but actually leads to spaghetti mess code that is harder to maintain than it would be without any automatic DI.
- erickf1 3y ago
  Agreed.
- flaminHotSpeedo 3y ago
  I agree, though I'd say in the more general case that overly flexible DI frameworks are the broader problem. Designers will put much more thought into how best to interact with a framework, so start with a small, opinionated interface then consider extension feature requests on a case by case basis
Blackthorn 3y ago
Eh, it's not like it's much easier to find the last turtle in python. Or C++ when people are extensively using patterns like PointerToImpl*, which can really obfuscate things.

giovannibonetti 3y ago

Object orientation kills traceability. Classes are instantiated in one trace, then methods are called in another trace, and if something goes wrong in the latter, it is not trivial to find the wrong settings passed in the former. I think some functional programming languages solve that by running a good chunk (if not all) of the application in a single trace.

gombosg 3y ago
Yes, this is why we love functional programming! "What happened along the way" equals to the call stack, as long as there is no field mutation involved. And, of course, async/non-blocking calls, as tracing a call along different threads or promises may not be available all the time.
- asimpletune 3y ago
  Yeah, exactly. Referring back to the DI comment earlier... In FP, "DI" is literally just calling a function.
- gpderetta 3y ago
  """The venerable master Qc Na was walking with his student, Anton. Hoping to prompt the master into a discussion, Anton said "Master, I have heard that objects are a very good thing - is this true?" Qc Na looked pityingly at his student and replied, "Foolish pupil - objects are merely a poor man's closures." Chastised, Anton took his leave from his master and returned to his cell, intent on studying closures. He carefully read the entire "Lambda: The Ultimate..." series of papers and its cousins, and implemented a small Scheme interpreter with a closure-based object system. He learned much, and looked forward to informing his master of his progress. On his next walk with Qc Na, Anton attempted to impress his master by saying "Master, I have diligently studied the matter, and now understand that objects are truly a poor man's closures." Qc Na responded by hitting Anton with his stick, saying "When will you learn? Closures are a poor man's object." At that moment, Anton became enlightened."""
  - afiori 3y ago