News for hackers. Stuff that matters.
Re:Terrible programming features from the past by samus on Monday July 05, 2021 @11:48AM (#27739128)
In the end, it is deterministic, as you say. But it's also quite more involved than you imagine. It's a big pile of interceptors (and their proper ordering), bootstrap classes, autoconfiguration, component scans, layered property sources and some more. Lots of it is not immediately visible and you have to start to read Spring source code. And it gets worse if the project gets set up in a way that makes it hard to deal with. For example, not organizing packages by feature. Relying on component scans at the default package is also not exactly funny.

When developing a Spring project, you indeed start to quickly appreciate the introspection feature that advanced IDEs like IntelliJ IDEA provide. Inspecting the application container at runtime is also possible, but it's a clear sign that your app got waay too complicated and has to be refactored.

Re:Terrible programming features from the past by Firadeoclus on Monday July 05, 2021 @01:57PM (#27740322)
I'm sure there are existing systems for which this is quite involved. These are design choices, though. If the compiler can figure it all out and find everything, then so can an IDE, and make everything visible where it needs to be visible.
Re:Terrible programming features from the past by samus on Tuesday July 06, 2021 @12:24AM (#27744214)
The issue is that it can become very complicated very quickly, even when the IDE is able to figure it all out and present it in a useful way. Even with the best tooling, nonlocal control flow can't help but increase the WTF per minute[0].

[0]: https://www.osnews.com/story/19266/wtfsm/

Re:Terrible programming features from the past by Firadeoclus on Tuesday July 06, 2021 @07:06AM (#27746713)
If it does in fact become "very complicated" then maybe you are trying to achieve something that is very complicated.

Good tooling takes the surprise out of nonlocal control flow, and can project it into local control flow on demand.

To take it back to skrebbel's complaint, "methods defined far, far away", "absolutely no way to tell", "very surprising", "no indication whatsoever" -- all things that good tooling fixes because it can show you what gets injected where and why, when you need it (and show you a minimally intrusive reminder when you don't).