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

with the same argument i used to reject syntax highlighting in general. all the information should already be in the code. if i can't read that, then the syntax of the language is bad. syntax highlighting would just make me lazy. i have since decided that i like being lazy so i do like to use it, but you make a good point, if the use of colors makes you not write something in the code that you would otherwise, then that's not good. i can see that with syntax highlighting too, where the colors help me read code even if it is badly formatted, so i am less inclined to format for readability.

True, but I haven't experienced that for general syntax highlighting. I do read the code through cat or in other contexts often enough that I haven't lost the ability to read code at normal speed without syntax highlighting. Do you have an example?

i wasn't talking about the ability to read code, even though that was my initial argument for rejecting colors. what i mean is that without colors i might take more effort to write/format code so that it is more readable, instead of relying on syntax highlighting:

with colors this is perfectly readable, because if, for and return appear in red, and other keywords in blue. so they stand out, making the structure more visible than without colors.

    mixed reduce(function fun, array arr, mixed|void zero) {
      if(sizeof(arr))
        zero = arr[0];
      for(int i=1; i<sizeof(arr); i++)
        zero = ([function(mixed,mixed:mixed)]fun)(zero, arr[i]);
      return zero; }

without colors i might prefer to write something like this. using braces around each block, and line breaks, to make each part stand out.

    mixed reduce(function fun, array arr, mixed|void zero)
    {
      if(sizeof(arr))
      {  
        zero = arr[0];
      }

      for(int i=1; i<sizeof(arr); i++)
      {
        zero = ([function(mixed,mixed:mixed)]fun)(zero, arr[i]);
      }

      return zero;
    }

without colors clearly the second is easier to read.

github uses a different color scheme but maybe you can get the idea:

https://github.com/pikelang/Pike/blob/fe4b7ef78cc26316e62e79...

I see. I'm typically quite pedantic and start reformatting code manually as soon as a single space is off.

I've never seen that language. Looks C like (e.g. sizeof), but seams to have a harder type system.

For me it would be like this:

    mixed reduce(function fun, array arr, mixed|void zero) {
      if(sizeof(arr))
        zero = arr[0];

      for(int i=1; i<sizeof(arr); i++)
        zero = ([function(mixed,mixed:mixed)]fun)(zero, arr[i]);

      return zero; 
  }

I only want to isolate blocks (around 10 lines at most) then I can dive in if necessary. I'm using minimal syntax highlighting in Emacs, but I can do fine without.

sure, probably for me too. i was just trying to demonstrate my point which is that the very compact example becomes a lot more readable with syntax highlighting and therefore it potentially encourages to make code less readable for those who don't use syntax highlighting.