if the editor allows Kanji, Cyrillic, Chinese and Greek, contributors are quite likely to type comments in Kanji, Cyrillic, Chinese and Greek. the end-result is that every single damn programmer who wants to contribute must not only install Kanji, Cyrillic, Chinese and Greek unicode fonts, but also they must be able to read and understand Kanji, Cyrillic, Chinese and Greek. again: you've just destroyed the possibility of collaboration by terminating communication and understanding.
This is a project management issue. Many managers might think code is code and programmers are interchangeable, but it is important that programmers can communicate (and thus need to speak a common language). Besides, source code repositories could be adapted for this - just specify what subset of unicode is allowed, and disallow check-ins of files that contain characters outside of this subset.
then, also, you have the issue of revision control, diffs and patches. by moving to unicode, git svn bazaar mercury and cvs all have to be updated to understand how to treat unicode files - which they can't (they'll treat it as binary) - in order to identify lines that are added or removed, rather than store the entire file on each revision. bear in mind that you've just doubled (or quadrupled, for UCS-4) the amount of space required to store the revisions in the revision control systems' back-end database, and bear in mind that git repositories such as linux2.6 are 650mb if you're lucky (and webkit 1gb) you have enough of a problem with space for big repositories as it is!
Seriously? In this day and age, the amount of space required for source code should never an issue. Storage space is cheap. If people are serious about a project, getting adequate space for storing the code repository should never an issue.
but before that, you have to update the unix diff command and the unix patch command to do likewise. then, you also have to update git-format-patch and the git-am commands to be able to create and mail patches in unicode format (not straight SMTP ASCII). then you also have to stop using standard xterm and standard console for development, and move to a Unicode-capable terminal, but you also have to update the unix commands "more" and "less" to be able to display unicode diffs.
Are there technical reasons why this would not be feasible?
there are good reasons why ASCII - the lowest common denominator - is used in programming languages: the development tools revolve around ASCII, the editors revolve around ASCII, the internationally-recognised language of choice (english) fits into ASCII. and, as said right at the beginning, the only reason why stupid obtuse symbols instead of straightforward words were picked was to cram as much into as little memory as possible. well, to some extent, as you can see with the development tools nightmare described above, it's still necessary to save space, making UNICODE a pretty stupid choice.
Those were good reasons in the past. Why can't we move past these reasons now, though?
Why should code be tied to text only anyway? I know there have been some experiments that never really took off, but even if we could expand programs to more than simple text just for comments that would be a huge help. A diagram or picture can often more accurately, and quickly, convey how a piece of code should work than a long piece of text. It would also be nice if we could reference non-code files from a code file. How about linking a class or method to a specification document (or part of it)? It would also be nice if you were alerted to check correctness of the linking code if the relevant section of the specification document changed.
We currently write source code as the compiler is the only consumer of the file that matters and that humans are some inconvenient aspect that we begrudgingly make the code accessible to. Thinking of people as first class consumers of source code may have a significant impact on programming.
THEGODDESSOFTHENETHASTWISTINGFINGERSANDHERVOICEISLIKEAJAVELININTHENIGHTDUDE
