Want to wade into the snowy surf of the abyss? Have a sneer percolating in your system but not enough time/energy to make a whole post about it? Go forth and be mid: Welcome to the Stubsack, your first port of call for learning fresh Awful youāll near-instantly regret.
Any awful.systems sub may be subsneered in this subthread, techtakes or no.
If your sneer seems higher quality than you thought, feel free to cutānāpaste it into its own post ā thereās no quota for posting and the bar really isnāt that high.
The post Xitter web has spawned soo many āesotericā right wing freaks, but thereās no appropriate sneer-space for them. Iām talking redscare-ish, reality challenged āculture criticsā who write about everything but understand nothing. Iām talking about reply-guys who make the same 6 tweets about the same 3 subjects. Theyāre inescapable at this point, yet I donāt see them mocked (as much as they should be)
Like, there was one dude a while back who insisted that women couldnāt be surgeons because they didnāt believe in the moon or in stars? I think each and every one of these guys is uniquely fucked up and if I canāt escape them, I would love to sneer at them.
(2026 is off to a great start, isnāt it? Credit and/or blame to David Gerard for starting this.)
Doesnāt look interesting to me. NB Iām not a Swifty. If youāre someone looking to make a compile-time dependency injection validation framework, cycle detection seems like an early feature to add, and feels like a pretty early unit test to implement.
E: read response from BurgersMcSlopshot please :)
DI frameworks are tricky beasts. Either they sacrifice flexibility for simplicity (Iāve seen this done in Go and in Scala, where the DI essentially generates basic instantiation and more advanced resolution is left to the app developer) or they can get really complex but do some handy things (.Net 4.x DI frameworks like Castle Windsor provided some neat lifecycle management tools but was internally very complex).
Cycle detection gets a little hairer the more complex a dependency/ class of dependencies gets. The process itself doesnāt change but the internal representation of the graph needs to be sufficiently abstract enough to illustrate a cycle for all possible resolution scenarios.
Based on the commit to fix the particular bug, it looks like the change will address a specific scenario but will probably fail to address similar issues.
All this to say āthe problem isnāt too hard to think about but the solution isnāt straight-forwardā, also āthis is a fine short- term fix but longer-term would involve redefining the internal representation of a dependency graphā, and finally " An LLM-provided solution is at best a band-aid, in the most generous light.ā
Thanks so much! Now I can waste my life on more interesting thingsā¦
I see. I guess I was thinking too abstractly about how a system like this might work.