[erlang-questions] A proposal for Unicode variable and atom names in Erlang.

Benoit Chesneau <>
Tue Oct 23 07:38:40 CEST 2012


On Oct 22, 2012 4:18 PM, "Mahesh Paolini-Subramanya" <
> wrote:
>>
>> People speaking other languages only aren't morons. They damn well know
that the international community won't understand their language already,
and they probably deal with it daily. People on this list seem to think
that as soon as you allow other alphabets or glyphs, they'll be invaded by
foreigners taking over their code bases. It just won't happen, the same way
it doesn't happen already while it's entirely possible to represent other
languages in the current subset of Erlang.
>
>
> On a side note, the vast majority of code out there is not "community",
"open source", etc., etc. Au contraire it consists of "stuff" that is
written for internal use, for glue code, for private functionality, for
hacks, and oh, a million other uses, none of which will ever make it to
github, bitbucket, and the like.

Beeing private doesn't mean you won't need any help from external
programmer. And sometimes they are foreigner.

imo programming in that context is like math. It should be understandable
by all. Now imagine if all maths where localized...

- benoît

> I'm with Fred in that I don't particularly see a Clear and Present Danger
here…
>
> Cheers
>
>
On Oct 22, 2012 4:18 PM, "Mahesh Paolini-Subramanya" <
> wrote:

> People speaking other languages only aren't morons. They damn well know
> that the international community won't understand their language already,
> and they probably deal with it daily. People on this list seem to think
> that as soon as you allow other alphabets or glyphs, they'll be invaded by
> foreigners taking over their code bases. It just won't happen, the same way
> it doesn't happen already while it's entirely possible to represent other
> languages in the current subset of Erlang.
>
>
> On a side note, the vast majority of code out there is not "community",
> "open source", etc., etc. *Au contraire* it consists of "stuff" that is
> written for internal use, for glue code, for private functionality, for
> hacks, and oh, a million other uses, none of which will ever make it to
> github, bitbucket, and the like.
> I'm with Fred in that I don't particularly see a Clear and Present Danger
> here…
>
> Cheers
>
> *
> Mahesh Paolini-Subramanya<http://www.gravatar.com/avatar/204a87f81a0d9764c1f3364f53e8facf.png>
> *
> That Tall Bald Indian Guy...
> Google+ <https://plus.google.com/u/0/108074935470209044442/posts>  | Blog<http://dieswaytoofast.blogspot.com/>
>    | Twitter <https://twitter.com/dieswaytoofast>
>
> On Oct 22, 2012, at 10:03 AM, Fred Hebert <> wrote:
>
>  Have you ever heard communities from any of the languages I listed (Ada,
> C#, CL, D, Go, Haskell, J, Java, Mathematica, Perl, Python, Ruby1.9, etc.)
> complain that "well we would accept that change, but it's incompatible with
> Unicode variable names?" Have we had problems with Spanish or Portuguese
> programmers submitting Spanish or Portuguese code to OTP? That code exists,
> just without using other characters, and it's just not much of a problem
> from what I understand.
>
> Many of us are 'foreigners' already, and many of us made the effort to
> switch to English to be understood -- hell, wasn't Swedish at the origins
> of Erlang?  We all understood, pretty fast too, that English was the way to
> go around here. I can tell you people who don't speak English realize it
> also.
>
> People speaking other languages only aren't morons. They damn well know
> that the international community won't understand their language already,
> and they probably deal with it daily. People on this list seem to think
> that as soon as you allow other alphabets or glyphs, they'll be invaded by
> foreigners taking over their code bases. It just won't happen, the same way
> it doesn't happen already while it's entirely possible to represent other
> languages in the current subset of Erlang.
>
> I'd like to call bull shit on this entire premise. It's entirely made up.
>
>
> On 12-10-22 9:49 AM, Rustom Mody wrote:
>
>
>
> On Mon, Oct 22, 2012 at 5:59 PM, Fred Hebert <> wrote:
>
>>  Regarding the use of Unicode in variables, here is a short list of
>> languages that allow it:
>>
>> - Ada
>> - C#
>> - Common Lisp
>> - D
>> - Delphi
>> - GNU Forth (other impls are often ASCII only)
>> - Go
>> - Haskell
>> - J
>> - Java
>> - Mathematica
>> - Perl (also Perl 6)
>> - Python
>> - Racket
>> - Tcl
>>
>> Now in any of these languages, can you blame the use of Unicode in
>> identifiers as the source of woes in there? Is it usually due to semantics,
>> other syntax, lack of clarity (even in English), their community? Name me
>> one language where unicode support is a true problem compared to anything
>> else, in this list.
>>
>> Is a Chinese programmer suddenly typing with her own glyphs rather than
>> pinyin a problem? If I'm programming in French already and had my education
>> in French, it's possible I learned everything using French terminology:
>>
>> tableau -> array, arbre binaire -> binary tree, liste -> list, paquet ->
>> packet, octet -> byte, taille -> size, fichier -> file, dossier ->
>> directory, boucle -> loop
>>
>> and so on. Note that I can use all of these in my existing Erlang
>> programs if I want to, if I'm working with people who do not speak English
>> but still have a formal education in Computer Science, software
>> engineering, or whatever. Chances are that someone who doesn't speak French
>> won't have the best time reading that code, but has it been a major problem
>> so far? Would allowing, say accented characters so someone can write
>> 'colonne' and 'rangée' instead of 'colonne' and 'rangee' for 'column' and
>> 'row', be the straw that breaks the camel's back? Is the use of accents
>> what's going to be the problem here? Or are we supposed to be especially
>> afraid of non-latin-looking characters?
>>
>> I've mentioned to a few people here before that I'm coming from a small
>> part of Quebec where people don't speak English that well. I've had to work
>> on code bases where French was mandatory because otherwise, people on your
>> team wouldn't be able to understand what the code was supposed to do.
>> French code shoved in English exists, and it's being used. I'm sure you
>> know the same happens in a boatload of other languages.
>>
>> Telling these people "well just Learn English, that's what I did when I
>> needed to" isn't a valid way of doing things. Nobody should have to jump
>> through the hoops we had to jump through, just because we had to when we
>> were learning. This isn't a reason enough. I'm not willing to go back to my
>> old office, and tell this father of 3 children (who programs to feed them)
>> "Sorry buddy, you're out of a job because apparently English is now
>> necessary." It just won't happen because it is *not* necessary to know
>> English to program.
>>
>> As much as the huge github love circle and "code is global" thing has
>> been going, there's still an entire localized world out there where people
>> work in small private enterprises, providing local services to people who
>> speak their language, a place where people don't give a shit whether user
>> 'robocop56' stars your repository or not. Programmers who want to go global
>> can still write English stuff all the same, lest they want to see their
>> code shunned by the majority of the world. That's likely what anyone using
>> the listed languages above did.
>>
>> This is no excuse to make it hard for everyone else to work in a way
>> they're comfortable. A huge part of programming is being able to reason
>> about code. Let programmers who want to do it, be able to do so, especially
>> when we see that so many languages support it already, without most people
>> even noticing.
>>
>> Here's one for you specifically Yurii: why would you want to keep people
>> from using a feature they want to use but that you wouldn't use anyway?
>>
>> Regards,
>> Fred.
>>
>
> Fred:
> If I may use a marketing metaphor: if one widens the net of the marketing
> campaign, one potentially gets more customers, but also the campaign cost
> rises. So a hardnosed cost-benefit analysis is required.
>
> To take an example closer to us: at some point in the long history of
> emacs, emacs decided to support windows.  Today probably there are 3 times
> more windows users of emacs than all else combined -- just my guesstimate
> from hanging about the emacs users list. However when I move over to the
> emacs dev list a different picture emerges.
> The windows code in the low level parts of the display manager is
> sufficiently different and sufficiently brittle for the devs to wish avoid
> touching it.
> So supporting windows has a direct cost in slowing the progress of emacs.
>
> Its obvious that for Erlang to support unicode will be a development cost.
> The important (and hopefully non-rhetorical) question is whats the
> cost-benefit analysis.
>
> In the Erlang world I am completely unqualified at this point to say (hope
> this changes soon!)
>
> Rusi
>
>
>  _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
>
> _______________________________________________
> erlang-questions mailing list
> 
> http://erlang.org/mailman/listinfo/erlang-questions
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20121023/0d6915cd/attachment.html>


More information about the erlang-questions mailing list