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].
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).
This clearly makes it pretty awkward to handle. Yet considering that the compiler manages to figure out where code needs to be injected, one can ask: why does the programmer not get to see this information?
This is not a fundamentally unsolvable problem. It is a tools problem. It's easy to imagine a programming environment where you can tell immediately which code gets injected where. Even in a dynamic system you should be able to see, on examining a function, what its current contents including injected code are.
Some programming language features require proper tools support to be useful. This requires languages that want to introduce such features to be opinionated on the matter of what tools you can use.