On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
> On 5/27/2013 3:18 PM, H. S. Teoh wrote:
>> Well, D *does* support non-English identifiers, y'know... for example:
>>
>> 	void main(string[] args) {
>> 		int число = 1;
>> 		foreach (и; 0..100)
>> 			число += и;
>> 		writeln(число);
>> 	}
>>
>> Of course, whether that's a good practice is a different story. :)
>
> I've recently come to the opinion that that's a bad idea, and D should not support it.

Why do you think its a bad idea? It makes it such that code can be in various languages? Just lack of keyboard support?

On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
> I've recently come to the opinion that that's a bad idea, and D should not support it.

I think it is a bad idea to program in a language other than english, but I believe D should still support it.

On Tue, May 28, 2013 at 01:28:22AM +0200, Hans W. Uhlig wrote:
> On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
> >On 5/27/2013 3:18 PM, H. S. Teoh wrote:
> >>Well, D *does* support non-English identifiers, y'know... for example:
> >>
> >>	void main(string[] args) {
> >>		int число = 1;
> >>		foreach (и; 0..100)
> >>			число += и;
> >>		writeln(число);
> >>	}
> >>
> >>Of course, whether that's a good practice is a different story. :)
> >
> >I've recently come to the opinion that that's a bad idea, and D should not support it.

Currently, the above code snippet compiles (upon inserting "import std.stdio;", that is). Should that be made illegal?


> Why do you think its a bad idea? It makes it such that code can be in various languages? Just lack of keyboard support?

I can't speak for Walter, but one issue that comes to mind is when someone reads the code and doesn't understand the language the identifiers are in, or worse, can't reliably recognize the distinctions between the glyphs, and so can't match identifier names correctly -- if you don't know Japanese, for example, seeing a bunch of Japanese identifiers of equal length will look more-or-less the same (all gibberish to you), so it only obscures the code. Or if your computer doesn't have the requisite fonts to display the alphabet in question, then you'll just see a bunch of ?'s or black blotches for all program identifiers, making the code completely unreadable.

Since language keywords are already in English, we might as well standardize on English identifiers too. (After all, Phobos identifiers are English as well.) While it's cool to have multilingual identifiers, I'm not sure if it actually adds any practical value. :) If anything, it arguably detracts from usability. Multilingual program output, of course, is a different kettle o' fish.


T

-- 
Doubt is a self-fulfilling prophecy.

On 5/27/2013 4:28 PM, Hans W. Uhlig wrote:
> On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
>> I've recently come to the opinion that that's a bad idea, and D should not
>> support it.
>
> Why do you think its a bad idea? It makes it such that code can be in various
> languages? Just lack of keyboard support?

Every time I've been to a programming shop in a foreign country, the developers speak english at work and code in english. Of course, that doesn't mean that everyone does, but as far as I can tell the overwhelming bulk is done in english.

Naturally, full Unicode needs to be in strings and comments, but symbol names? I don't see the point nor the utilty of it. Supporting such is just pointless complexity to the language.

On Tuesday, 28 May 2013 at 00:11:18 UTC, Walter Bright wrote:
> On 5/27/2013 4:28 PM, Hans W. Uhlig wrote:
>> On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
>>> I've recently come to the opinion that that's a bad idea, and D should not
>>> support it.
>>
>> Why do you think its a bad idea? It makes it such that code can be in various
>> languages? Just lack of keyboard support?
>
> Every time I've been to a programming shop in a foreign country, the developers speak english at work and code in english. Of course, that doesn't mean that everyone does, but as far as I can tell the overwhelming bulk is done in english.
>
> Naturally, full Unicode needs to be in strings and comments, but symbol names? I don't see the point nor the utilty of it. Supporting such is just pointless complexity to the language.

The most convincing case for usefulness I've seen was in java where a class implemented a particular algorithm and so was named after it. This name had a particular accented character and so required unicode. Lots of algorithms are named after their inventors and lots of these names contain unicode characters so it's not that uncommon.

On 28 May 2013 09:05, Walter Bright <newshound2@digitalmars.com> wrote:

> On 5/27/2013 3:18 PM, H. S. Teoh wrote:
>
>> Well, D *does* support non-English identifiers, y'know... for example:
>>
>>         void main(string[] args) {
>>                 int число = 1;
>>                 foreach (и; 0..100)
>>                         число += и;
>>                 writeln(число);
>>         }
>>
>> Of course, whether that's a good practice is a different story. :)
>>
>
> I've recently come to the opinion that that's a bad idea, and D should not support it.
>

Why? You said previously that you'd love to support extended operators ;)

On 28 May 2013 09:39, <luismarques@gmail.com>"@puremagic.com < "\"Luís".Marques"> wrote:

> On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
>
>> I've recently come to the opinion that that's a bad idea, and D should not support it.
>>
>
> I think it is a bad idea to program in a language other than english, but I believe D should still support it.
>

I can imagine a young student learning to code, that may not speak English
(yet).
Or a not-so-unlikely future where we're all speaking chinese ;)

On Tuesday, 28 May 2013 at 00:34:20 UTC, Manu wrote:
> On 28 May 2013 09:05, Walter Bright <newshound2@digitalmars.com> wrote:
>
>> On 5/27/2013 3:18 PM, H. S. Teoh wrote:
>>
>>> Well, D *does* support non-English identifiers, y'know... for example:
>>>
>>>         void main(string[] args) {
>>>                 int число = 1;
>>>                 foreach (и; 0..100)
>>>                         число += и;
>>>                 writeln(число);
>>>         }
>>>
>>> Of course, whether that's a good practice is a different story. :)
>>>
>>
>> I've recently come to the opinion that that's a bad idea, and D should not
>> support it.
>>
>
> Why? You said previously that you'd love to support extended operators ;)

I find features such as support for uncommon symbols in variables a strength as it makes some physics formulas a bit easier to read in code form, which in my opinion is a good thing.

On Tue, May 28, 2013 at 02:23:32AM +0200, Diggory wrote:
> On Tuesday, 28 May 2013 at 00:11:18 UTC, Walter Bright wrote:
> >On 5/27/2013 4:28 PM, Hans W. Uhlig wrote:
> >>On Monday, 27 May 2013 at 23:05:46 UTC, Walter Bright wrote:
> >>>I've recently come to the opinion that that's a bad idea, and
> >>>D should not
> >>>support it.
> >>
> >>Why do you think its a bad idea? It makes it such that code can
> >>be in various
> >>languages? Just lack of keyboard support?
> >
> >Every time I've been to a programming shop in a foreign country, the developers speak english at work and code in english. Of course, that doesn't mean that everyone does, but as far as I can tell the overwhelming bulk is done in english.
> >
> >Naturally, full Unicode needs to be in strings and comments, but symbol names? I don't see the point nor the utilty of it. Supporting such is just pointless complexity to the language.
> 
> The most convincing case for usefulness I've seen was in java where a class implemented a particular algorithm and so was named after it. This name had a particular accented character and so required unicode. Lots of algorithms are named after their inventors and lots of these names contain unicode characters so it's not that uncommon.

I don't find this a compelling reason to allow full Unicode on identifiers, though. For one thing, somebody maintaining your code may not know how to type said identifier correctly. It can be very frustrating to have to keep copy-n-pasting identifiers just because they contain foreign letters you can't type. Not to mention sheer unreadability if the inventor's name is in Chinese, so the algorithm name is also in Chinese, and the person maintaining the code can't read Chinese. This will kill D code maintainability.


T

-- 
Don't drink and derive. Alcohol and algebra don't mix.

On 5/27/2013 6:06 PM, H. S. Teoh wrote:
> I don't find this a compelling reason to allow full Unicode on
> identifiers, though. For one thing, somebody maintaining your code may
> not know how to type said identifier correctly. It can be very
> frustrating to have to keep copy-n-pasting identifiers just because they
> contain foreign letters you can't type. Not to mention sheer
> unreadability if the inventor's name is in Chinese, so the algorithm
> name is also in Chinese, and the person maintaining the code can't read
> Chinese. This will kill D code maintainability.

+1