> For example class properties [...] I think all information should be in the code itself
A bit of a quibble, but the information is already "in the code", even when viewing it in a simple text-editor.
What you're describing is redundant display of information in the raw text, as opposed to a different redundant display the IDE does automatically on the fly when needed.
Sometimes that's useful, and other times it harms comprehension, like when you have dozens of integer variables sharing a prefix like `i_apples` and `i_pears`. An IDE lets you switch presentation modes without making changes.
That's true. Maybe it's more correct that I want to have the information in the minimal considered code unit. Let that be a function or something.
Also languages are already redundant in a lot of places, because humans prefer it that way. For example you wouldn't really need to have types in a function signature, because it is already in the declaration. I think a lot of '(' or ',' could be omitted without it becoming ambiguous.
IMO this is very much like database table (de)normalization decisions. Sometimes you want one single source of truth, for correctness and ease of maintenance, and other times you want it repeated for read-performance.
For source code, that suggests a spectrum between:
1. Important information is declared in just one spot, and it is difficult to make anything inconsistent. You rely heavily on analysis tools (IDE) to provide combined views of information in useful places so that you don't need to keep tracing back to the single source of truth.
2. Important information is duplicated in different areas, where any mismatch between primary and secondary sites makes potential for corruption. Tools are used heavily to block corrupt states from being loaded, or to "repair" bad secondary sites, and to recheck relationships to avoid saving corrupt states.
Personally I feel erring towards #1 is better: While unassisted-reading of the code becomes marginally harder, it doesn't ruin the ability to make unassisted-changes of the code.
That is a very good comparison. I tend to err to #2, because I think of this more as separate databases. It is quite useful to decompose problems into different units, which might represent different actors or aspects of a domain space. Thus, the ability to describe interface definitions from both sides provides a way to describe the interface in the terms of each side, serving as a way to document internal assumptions and allowing for the necessity of intermediaries to surface. This is a concept that is shaped by C's notion of translation units.
A bit of a quibble, but the information is already "in the code", even when viewing it in a simple text-editor.
What you're describing is redundant display of information in the raw text, as opposed to a different redundant display the IDE does automatically on the fly when needed.
Sometimes that's useful, and other times it harms comprehension, like when you have dozens of integer variables sharing a prefix like `i_apples` and `i_pears`. An IDE lets you switch presentation modes without making changes.