Standard shitpost and then out of nowhere “Hello inject me with beans please”
WHY IS IT SO FUNNY
I inject myself with beans every morning, usually French press
We’re struggling to deal with climate change and these selfish developers can think of nothing except building more factories. This is a global issue, we need a global solution: eschew factories and services for defining everything globally.
I fucking hate Spring.
The quickest way to get a team of 10 contractors to turn 100 lines of basic code from a decent engineer into 2k, with 50 janky vulnerable dependencies, that needs to be babied with customized ide’s and multi-minute+ build times and 60m long recorded meetings.
Fuck Spring.
They can do that in any season
Ok, you win! 😁 😂
Wouldn’t want to write a webserver / database connection / scheduler / etc. from scratch. Spring Boot plus lombok turns 2k lines of code into 100.
… Looks both ways…
Python does the same in 10 lines of code.
… Ducks under a table to avoid the ensuring flames …
I replaced the P in my LAMP stand with Python and I’ve never been happier.
Same here.
They say he’s still ducking to this day
Yep. That’s why we call it “duck typing” in Python.
Sure… That"s what libraries are for. No one hand-rolls that stuff. You can do all of that just fine (and, actually, in a lot less code, mostly because Java is so fucking verbose) without using the nightmare that is Spring.
Fuck Spring.
Actually, there’s a lot to be said for being able to configure your spleamtomoter without needing to reverse the polarity on the stack cache rotator arm.
I’m kidding.
Fuck Spring.
Hello inject me with beans please
not again
Yeah, I’d rather get injeancted with beans.
XML is the second worst programming language ever created by humans
I’m gonna need a bell curve hooded figure meme template of this comment, this is comedy gold.
Good luck deciding where each opinion goes.
It’s a markup language, not a programming language.
Whoosh
Seriously though, spring configurations are written in XML and you create variables, call functions, and have control flow. Effectively turning XML into a horrible twisted shadow of a programming language.
All in the name of “configurability” through dependency injection.
Spring moved away from XML ages ago. I work on a 6 year old Spring project and it has never had a single line of XML in it.
I’m fond of saying that all great code earns it’s right to become good code by starting as trash…
But I still think we should all quietly and politely let Spring die a simple dignified death, as soon as possible.
Out of wildly morbid curiosity, do Maven and Ant still shit all over each other to make sure no one has any real idea what the build inputs and outputs are?
I shouldn’t ask things I don’t really want to know, though. My inbox is gonna be full of Java apologists.
No idea, I’ve never used either of those tools.
I think some people still use Maven, but I use Gradle in all of mine. Gradle build files are written in Kotlin instead of XML like Maven.
No idea, I’ve never used either of those tools.
That’s a relief to hear. They were quite bad. Or rather, the way most teams used them was quite bad.
I’ve heard nice things about Gradle. Of course that was mainly from people with deep psychological scars after working with Ant and Maven…
Thanks, my works’ codebase feels old now.
So if you take XML, pervert it beyond recognition, cut off it’s balls and one hand, then it’s somehow it’s fault that it sucks?
They started from XML. There’s nowhere to go but up but spring managed to fuck even that up.
FactoryStrategyFactoryFactoryObserverInterface
Friends don’t let friends use Java 😜
It was a markup language until someone decided to parse and execute it as a programming language. This person should be watched for other deranged behavior.
I use XML as markup language, what kind of deranged person thought to turn it into a programming language? My problems with the Lua API led me down the rabbit hole of making my own VM and implementation, not looking at a markup languge, then go “what if I used this for scripting?”.
When they make XML do these things (or the way Github Actions does it with YAML), they’re essentially creating a representation of the AST that the compiler would make internally from a mini language. So there’s a few possibilities:
- They don’t know how compilers work and reach for a tool they do know
- They know, but figure the problem at hand doesn’t need the complexity of a mini language and start the project the quick and dirty way, and it gets out of hand as they add features
- They may or may not know, but they do get caught up in the hype of some other tool (likely what happened with XSLT)
Tell that to SOAP.
Yo dawg, I heard you like XML over HTTP so I put XML over HTTP in your XML over HTTP.
Like yaml/toml
The one benefit of toml is that nobody creates a programing language over it.
The one benefit of toml is that nobody creates a programing language over it.
Heh. Any day though, right? I can’t wait to see an excited presentation on code-free coding in YAML…
Github Actions have entered the chat.
Thanks. I hate that you’re right.
so far
Why yes, I would like my stack traces to make no ffing sense! I’m so glad you asked.
My favourite take on DI is this set of articles from like 12 years ago, written by a guy who has written the first DI framework for Unity, on which are the currently popular ones, such as Zenject, based on.
The first two articles are pretty basic, explaining his reasoning and why it’s such a cool concept and way forward.
Then, there’s this update:
Followed by more articles about why he thinks it was a mistake, and he no longer recommends or uses DI in Unity in favor of manual dependency injection. And I kind of agree - his main reasoning is that it’s really easy for unnecessary dependencies to sneak up into your code-base, since it’s really easy to just write another [Inject] without a second thought and be done with it.
However, with manual dependency injection through constructor parameters, you will take a step back when you’re adding 11th parameter to the constructor, and will take a moment to think whether there’s really no other better way. Of course, this should not be an relevant issue with experienced programmers, but it’s not as inherently obvious you’re doing something potentially wrong, when you just add another [Inject], when compared to adding another constructor parameter.
Exactly. Dependency injection is good; if you need a framework to do it, you’re probably doing it wrong; if your framework is too magical, you’re probably not even doing it at all anymore.
Say what you want about DI frameworks, but if I have to remove another fucking global variable so I can write a test, I’m going to cut a bitch.
Dependency injection is so much worse. Oh, hey, where’d this value come from? Giant blob of opaque reflection code.
It can be used in bad ways, but if it’s used in the right way you should never have the situation you just described.
I’m not exactly sure what you mean. Doesn’t all dependency injection work the way I described?
Without being familiar with the framework, you can’t trace your way from the class getting injected into to the configuration, even if you’re experienced with the language.
I don’t think so. When I’ve seen it done it’s usually not been random values injected (except when those values are secret keys which should absolutely not be stored in code to begin with), it’s usually injecting a service. Another class, usually with a name that makes it easy to trace down. Like if you’re building an
OrderService, that might take as a dependency anIProductService, which would have injected into it the classProductService(personally, I don’t like the Hungarian notation that C# uses, but it’s a convention and my preference for sticking to strong conventions for the sake of consistency outweighs my distaste for Hungarian notation). That’s easy to find, and in fact your IDE can probably take you straight to it from theOrderService’s constructor.I’m using value in the loosest sense, like how all objects are values.
So now if you have three implementations of
IProductService, how do you know which one is configured?It’s easy to imagine a hypothetical way that could lead to problems. But in all the code I’ve worked with, either that scenario is avoided entirely, or other context makes it absolutely clear which
IProductServiceis being used.
Same could be said of a global. There’s a time and a place for each.
One thing I’ll say is I don’t remember us needing a team of senior+ devs to handle web app back in the day…
Is this even a joke? In Spring DI beans are nothing but glorified over complicated global variables.
Also this fits in here perfectly https://m.youtube.com/watch?v=k0qmkQGqpM8
Spring singleton beans are supposed to be stateless though, so they can’t be called variables. Maybe the DI aspect of Spring is less relevant today in the micro service era, but in the day Spring helped make layered monolith apps much cleaner.
Really? From my experience the opposite is the case. I work on a smallish team with 3 other developers and we also have a few spring services with < 100 classes and we constantly run into issues where making changes to a bean causes issues in another unrelated part of the codebase. I can’t imagine what a nightmare it would be with a larger codebase and more devs working on it.
I think this might be the first of these I’ve seen where pretty much all the comments are just agreement.
Tell me more about these beans
Can we talk about annotations which are broken when you upgrade spring boot ? You are asked to upgrade some old application to the newest version of spring boot, application that you discover on the spot, the application does not work anymore after the upgrade, and you have to go through 10 intermediate upgrade guides to discover what could possibly be wrong ?
Spring annotations in general. There’s a completely hidden bean context where every annotation seems to throw interceptors, filters, or some reflection crap into. Every stacktrace is 200 lines of garbage, every app somehow needs 500mb for just existing and if you add something with a very narrow scope, that suddenly causes something completely unrelated to stop working.
Realistically, DI and all the Spring crap does not add anything but complexity.
Our Spring service was so simple until we decided we needed annotations to handle the fetching of settings. Now we are corrupted with needless reflection.
Holy shit mood, described to the tee.
An application I’ve never heard or seen before that needs to be upgraded, and it breaks, so you now need to understand what the hell this application does so you can fix it properly.
And the management not getting why it takes so long to « just update some version numbers in Pom.xml files »…
Gradle, with it’s transitive dependency modifications is a huge pain in this area.
It used to be that if a library ended up having a flaw then it would be flagged and we would get the dependency updated. These days security block the “security risk” and you have to replace your dependencies dependency. Fingers crossed you can get it to actually test all the code paths.
If an second level project gets a flaw, and it’s used indirectly then we should really look at getting the import updated so that we know it works. If that import is abandoned then we should not be updating that second level dependency, either adopt and fix the first level dependency or look at an alternative.
I’ll never plaster the back of my car with stickers that all proclaim the same things in ALL CAPS.
But if I was going to…
It would pretty much match this meme.
DI: ☺️
DI frameworks: 😒
I just DI all the time, it’s called a constructor.
At work we have a lot of old monolithic OOP PHP code. Dependency injection has been the new way to do things since before I started and it’s basically never used anywhere.
I assume most people just find it easier to create a new class instance where it’s needed.
I’ve never really seen a case where I think, “dependency injection would be amazing here” I assume there is a case otherwise it wouldn’t exist.
Isn’t the point of injecting classes so that you don’t have tens of instances of the same class in memory?
When we implemented it significantly improved our ability to write unit tests. It also allowed us to make more modular code due to the default of every class having an interface. So I’m all for it.
In my opinion dependency injection solves a problem that doesn’t need to exist, and does it by adding even more obfuscation and complexity.
The problem is that the original gang of four design patterns had very little to say about managing effects. In old java code things like network and file IO often happen deep inside the object graph, hidden behind multiple impenetrable abstractions such that it’s impossible to run the logic without triggering the effect.
The wrong solution is to add even more obfuscation and abstraction, so that you can inject replacement classes deep inside the object graph where the effects happen. it solves the immediate problem of implementing tests, but makes everything else worse and more confusing.
The right solution is to surface all your effects at the top level of the call graph. The logic only generates data, and passes it back up to the top level of the program. The top level code then decides whether to feed this data into an effectful operation. Now all your code is easier to reason about, and in you can easily test the logic without triggering unwanted effects.
Yeah. Injection has a place in test patterns. Thankfully, it’s usually possible to hide injection from strongly affecting anything else that matters, as long as the team hates injection deeply enough.
Could be. There’s easier ways to minimize instances in memory. That’s what GLOBAL variables are for.
P.S. I have now gone:
0 dayswithout trying to wind up other senior developers.
As a fellow PHP dev (working in laminas specifically) DI actually is fucking awful, there’s a distinction between a service factory pattern and this thing called DI which is similar to a service factory pattern but uses reflection based type sniffing to guess at which service you want where. I’d considered making a reference to it but PHP developers are few and far between these days.
There are dozens of us
