The fact that Spring even exists should be a big red flag for the value of static typing. People routinely make mistakes using type systems. And when done correctly I see static type systems work very well solving problems that they themselves created.
The gambit of static typing is that the type checker can attest correctness. But the result, if indeed that the type checker does this (provide a mechanism of provable correctness), you still have to deal with protocol bloat that type systems incur. Hence the deeply nested method calls: that's a result of adopting a static type system.
I'm saying that with all that overhead, people still routinely make mistakes using static typing systems. They get the compiler to tell them that they're correct but their code is still not working.
Comments
The fact that Spring even exists should be a big red flag for the value of static typing. People routinely make mistakes using type systems. And when done correctly I see static type systems work very well solving problems that they themselves created.
How do you get from deeply nested method calls to "people routinely make mistakes using type systems"?
The gambit of static typing is that the type checker can attest correctness. But the result, if indeed that the type checker does this (provide a mechanism of provable correctness), you still have to deal with protocol bloat that type systems incur. Hence the deeply nested method calls: that's a result of adopting a static type system.
I'm saying that with all that overhead, people still routinely make mistakes using static typing systems. They get the compiler to tell them that they're correct but their code is still not working.
It sounds like you once read a blog that you half understood.
The best way to configure Spring beans is through @Bean annotations in code, precisely because it allows for static typing...