What annoys me about articles of this kind is that they compare the most simple, trivial summation example with full-grown, framework-y dependency injection.
There is a reason why this kind of configurable, Interface dependent DI style has developed- because it makes your life easier in large-scale applications.
I’d be inclined to agree that you probably don’t need that in your hobby or research projects, but if you ever worked on a serious application with test mocks, production/beta environments, hundreds of libraries that need to play in tandem, and a team of several developers, not having proper DI kills your productivity.
I'm not buying the "large-scale" and "serious" applications (whatever that means) argument so easily. The functional programming community builds large-scale applications and there is no trendy dependency injection frameworks.
In Elixir you could pass either a function or a module and defines an interface (the @callback notation). Maybe frameworks are then more a symptoms to a deeper problem in the language than a solution?
It's like a few years ago where you could listen to the same argument regarding XML. Now most of the systems use JSON in 90% of cases and for these cases it's better.
"because it makes your life easier in large-scale applications."
People like to say things like that of 'enterprisey code styles', but is it actually true?
What evidence is there that this in fact increases productivity, makes code easier to maintain and develop?
I can only speak for myself, but after maintaining a couple of legacy projects with database credentials sprinkled happily throughout the entire code base and other exciting refactoring opportunities, I welcome tight guardrails preventing a team (and this includes me) from writing bad code.
I agree. When I read this kind of articles, it makes me think: either we're doing it completely wrong, or the author simply doesn't have experience designing and maintaining large projects. In any case, good food for thought.
I don't know on which side I/we stand in your example, but 300K SLOC of a great codebase (without this style of programming) so far! Granted, the team is wonderful and management is top notch.
In 2020 we served roughly 4 billion purchases on that platform :)
I trust you if you say that your project and code base is great, without DI (of that particular kind).
But the comment was about your examples, and they are not great - they appear to be created to show how useless or overcomplicated DI is. And it is overcomplicated - in your toy examples.
However, there are plenty of better examples on the net of the benefits of DI, but in order to actually show any usefulness they either have to be large, or depend on the readers to "extrapolate" to larger/more complicated code bases.
The first draft dragged on as I tried to give a concrete example (API + Service + DB CRUD) in various implementations (Erlang gen_servers, CL CLOS, JS currying, C# with/out automated DI etc). I have a hard time tying my lose ends when writing, so I opted by a simpler example, perhaps swinging the bell too far the other way.
Thank you (all) for pointing it out, I missed it completely :)
My comment above was to exemplify that there perhaps is a span between everyone-is-wrong (by some definition of everyone) and the-author-is-inexperienced.
I'm not sure, my company used a mix of DI frameworks and regular/manual DI. Overall I think the DI framework codebases were about equal quality, just harder to understand.
I’d be inclined to agree that you probably don’t need that in your hobby or research projects, but if you ever worked on a serious application with test mocks, production/beta environments, hundreds of libraries that need to play in tandem, and a team of several developers, not having proper DI kills your productivity.