3 ms·

Having this in the editor leads to people removing that information from other channels. For example class properties are now often coloured, so people do not

Having this in the editor leads to people removing that information from other channels. For example class properties are now often coloured, so people do not name or refer to them to denote that they are not some random other variable. I don't like this, because I think all information should be in the code itself and it can be really annoying once you work and haven't your favorite editor available in the correct setup.

em-bee 1y ago
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.
- 1718627440 1y ago
  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?
  - em-bee 1y ago
    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/fe4b7ef78cc26316e62e792561cb114c123be396/lib/modules/Array.pmod#L55 https://github.com/pikelang/Pike/blob/fe4b7ef78cc26316e62e79...
    - 1718627440 1y ago
      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.
    - skydhash 1y ago
      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.
      - em-bee 1y ago
        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.
Terr_ 1y ago
> 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.
- 1718627440 1y ago
  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.
  - Terr_ 1y ago
    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.
    - 1y ago

em-bee 1y ago

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.

1718627440 1y ago
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?
- em-bee 1y ago
  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/fe4b7ef78cc26316e62e792561cb114c123be396/lib/modules/Array.pmod#L55 https://github.com/pikelang/Pike/blob/fe4b7ef78cc26316e62e79...
  - 1718627440 1y ago
    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.
  - skydhash 1y ago
    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.
    - em-bee 1y ago
      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.

Terr_ 1y ago

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

1718627440 1y ago
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.
- Terr_ 1y ago
  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.
  - 1y ago