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.

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.

Agreed.

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

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.

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.

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.

Yeah, exactly. Referring back to the DI comment earlier... In FP, "DI" is literally just calling a function.

"""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."""

OOP is actually class oriented programming and classes are orthogonal the object/closure duality.

For example in php class A { public $a = new B;} is not valid

https://onlinephp.io/c/31246

Such a restriction makes no sense in a "closures are a poor man's object" world.

Not sure what are you trying to say. My point was that a invoking a function that will act on arguments that have been defined away from the callsite is not a OO specific feature.

> And, of course, async/non-blocking calls, as tracing a call along different threads or promises may not be available all the time.

I think there is still hope on that front. Following structured concurrency patterns like the supervisor model should handle it. See the discussion about "Notes on structured concurrency, or: Go statement considered harmful" [1].

[1] https://news.ycombinator.com/item?id=16921761

I disagree. Pretty much any program of enough size, including those written in functional languages, are going to have state that outlives the lifetime of a single call stack.

hopefully not

it's certainly not a given

Simple example: the web server that takes in the HTTP requests? That one definitely got initialized outside the call trace that's serving the HTTP request.

No different from an object that got constructed and then a method called on it.

ah, sorry, i misinterpreted what you meant -- obviously, yes, you're correct

i thought you meant state that is created from a call stack and persists after that call stack returns -- which is something else