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].
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).
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.