On Thu, Nov 29, 2001 at 07:45:01AM +0100, Humbel Otmar wrote:
| [ Arno.Schmidmeier / dman ]
| > | The problem is simply:
| > | You write some lines of code with your favourite editor, on
| > plattform A, the
| > | file gets stored as ascii + some local code enhancements.
| > | Then you transfer the files to a different plattform/mashine with a
| > | different codeset.
| > | In the best case the names of variables, etc. changed quite
| > dramatically in
| > | the rest, just forget the result.
| That's exactly my experience.
| Please also consider file names with special characters - shudder.
| Only a small example: How many times has a blank in a windows file name
| broken up a *nix shell command of yours ?
That happens sometimes, but only if the app or script doesn't use
proper quoting techniques to guard against that (and similar things --
java class files like to have $ in their name, but that is also a
| And there is another point: readability/maintainability. We have here a
| development team of people with various mother languages (in
| alphabetical order and hopefully spelled correctly): Dutch, English,
| French, German, Italian, Slavish, Swiss German, Turkish, and maybe even
| If we would allow localized characters in source code, the chance would
| be high that poeple choose variable names in their mother language. The
| rest you can imagine.
I would expect that a multi-lingual development group would choose a
common language to code in, though for single-use throw away scripts,
or for students (or non-students) who want to begin programming it
could be helpful to use the native tongue.
| > Certainly if two processes try and use different encodings for the
| > same file, it won't work. That's what happened to me with jythonc --
| > it was encoded in latin1 (though only a single character in a comment
| > was affect) but jython (java) was trying to read it as utf-8.
| > The developer's editors and environment must all be set to the correct
| > encoding. PEP 263 addresses that as far as the interpreter is
| > concerned. It is up to the developers to configure their editor
| > appropriately.
| Beside the fact that there are systems where you simply cannot configure
| your editor, I think it is a matter of lowest common denominator, for
| the reasons above.
I understand what you are saying, though if I generalize it we should
never make progress because something already (incompatibly) exists.
I disagree with the view that we should not make progress (moving to
unicode, for example) just because some systems are incapable of
coping with it. IMO those systems should be fixed instead.
If native alphabets are allowed in identifiers, that doesn't prevent
you from exclusively using US-ASCII charaters. As I alluded to in my
"dumb american" comment, I only know English. Hence I will only be
using US-ASCII characters regardless of the outcome. Interestingly
enough, java allows other characters (umlauts, etc) in identifiers. I
recently (just yesterday) got some source code that used such
characters in it. My system (the one at work) was not correctly set
up for utf-8 so many characters were turned into "?". That didn't
work too well. When I fixed my environment it looked much better :-).
If the people whose language(s) contain non-US-ASCII characters don't
want those characters allowed in identifiers, then I have no problem
with it. I just thought it seemed a bit elitist (from an american
perspective anyways) to only allow US-ASCII characters.
It took the computational power of three Commodore 64s to fly to the moon.
It takes at least a 486 to run Windows 95.
Something is wrong here.