I think the point about not requiring syntax highlighting is meant to mean that the syntax of the language should not be so complicated that the majority of users need the fancy colours and bold/italics (and even syntax error underlines) to be able to understand it easily.

I've been reading a lot of Edward Tufte's website recently and it got me thinking about this in terms of helping the user be more productive with the tools available, but still with the end goal of better tools. For the minute, though, Perl, while not as much of a soup nazi as the machine on which it runs, is still a strict language, where word order and type matters and it helps the programmer to see rather than read errors as seeing is faster than reading. Differentiating by colour is faster still than parsing the difference between a heredoc and code.

I was going to say that syntax highlighting benefits maintainers, especially those who may not be as familiar with the language as the original 'guru', so that when they open up the editor, their vision is challenged by the colours on screen and then it is easier to skip visually through the code as it is not just one lump of black and white marks on the screen (HT/HP Basic, I'm looking at you, with your lack of spatial freedom and primitive monochrome IDE). But then I thought that functional higlighting rather than syntactical highlighting would be a great useful addition, e.g. so that you can tag related bits of a program with the same colour as you try to read it and understand the flow. I think VS may already have it, I was using it today at work, but can't remember, I never thought about it before this thread. I don't think XCode has user highlighting.

On your point about extra operators (1 and 2), apart from not having the glyphs visible on the keyboard, I think a good programming language should not cause Carpal Tunnel Syndrome or force it's users to learn too much over and above the normal set of characters in order to use it. However, I think captial Sigma and capital pi are probably good suggestions for extra operators as they are likely to be well understood by any programmer who has even an high school education. As for the arrow, I think the period is slightly better for OOP and I don't tend to use arrows for hashes anyway.

Rereading your point 5 I think that it is a little more useful than I first thought, but still sounds like another way to create a watch list. My original thought was that in general, I think the value of plain text as a way of writing code is the benefit of speed of entry without too much worrying about formatting other than lining up lists vertically and stuff. At the minute, most editors and even Word 2007's ribbon, don't have the facilities to enter even rudimentary formatting faster than the average programmer can type. Speed of entry is crucial where you need the throught process to flow. Having said that, most problems could well be designed out. When you think about it CTRL+I for italic is little different from SHIFT+[ to open a curly bracket. What you then get down to is more a carryover from the UNIX philosophy/tradition of human readable plaintext wherever possible, although if you go down the rich text route you could have xml and a stylesheet, but that complicates things too much for me. I think the goal of code should be what you see is what is done. I supose as well, that code could be thought of as cash. Not always the best transaction medium, e.g. debit cards can be more efficient, but everyone accepts cash, like text flowing through data pipes. Debit cards need more infrastructure than cash in a similar way to rich text and diagrams needing more infrastructure than ASCII.

Finally, I think a slightly different take on syntax highlighting would be useful for something like LilyPond source files, e.g. each beat in a bar gets a different colour (most music doesn't go past about 12/8 and even that could be argued to be similar to 4/4).

I hope everyone here will read Tufte and his forum contributors so that they can be more creative and productive in creating user interfaces and presenting output.