Po co dodawać obsługę identyfikatorów Unicode do różnych implementacji językowych?

14

Osobiście uważam, że czytanie kodu pełnego identyfikatorów Unicode jest mylące. Moim zdaniem zapobiega to również łatwemu utrzymywaniu kodu. Nie wspominając już o wysiłku włożonym przez autorów różnych tłumaczy w wdrożenie takiego wsparcia. Ciągle zauważam również brak (lub obecność) obsługi identyfikatorów Unicode na listach (nie) zalet różnych implementacji językowych (tak jakby to naprawdę miało znaczenie). Nie rozumiem: dlaczego tyle uwagi?

Egor Tensin
źródło
1
Masz na myśli nazwy rzeczy, czy masz na myśli znaki specjalne, takie jak gwiazdy, lambdy i środkowe kropki?
Frank Shearar
5
lol ! Czy wiesz, że istnieje świat poza językami obcojęzycznymi? Zadziwiające odkrycie, prawda?
deadalnix
3
deadalnix: Mieszkam w takim kraju, więc możemy użyć identyfikatorów takich jak größe. To powiedziawszy, nigdy tego nie robię i zdecydowanie to odradzam. Dlatego pytanie jest bardzo ważne.
user281377,
2
deadalnix: Do tej pory nigdy nie byłem w kraju anglojęzycznym. Dlaczego nie zwracać uwagi na rzeczywiste pytanie, a nie na pytającego?
Egor Tensin,
6
Chciałbym, żeby języki koncentrowały się na poprawnym ułożeniu Unicode i pomijały wymyślne identyfikatory Unicode. W każdym razie dobre zasoby programistyczne są w języku angielskim (StackOverflow), więc przyznajmy, że programowanie powinno odbywać się w języku angielskim (ułatwia także współdzielenie) i skupić się na implementacji poprawnej manipulacji ciągiem Unicode.
Matthieu M.

Odpowiedzi:

17

Kiedy myślisz o Unicode, myślisz o chińskich lub rosyjskich znakach, co powoduje, że myślisz o kodzie źródłowym napisanym w języku rosyjskim, który widziałeś w Internecie, i który był bezużyteczny (chyba że znasz rosyjski).

Ale jeśli Unicode może być użyte w niewłaściwy sposób, nie oznacza to, że samo w sobie jest złe w kodzie źródłowym.

Podczas pisania kodu dla określonego pola za pomocą Unicode możesz skrócić swój kod i uczynić go bardziej czytelnym . Zamiast:

const numeric Pi = 3.1415926535897932384626433832795;
numeric firstAlpha = deltaY / deltaX + Pi;
numeric secondAlpha = this.Compute(firstAlpha);
Assert.Equals(math.Infinity, secondAlpha);

Możesz pisać:

const numeric π = 3.1415926535897932384626433832795;
numeric α₁ = Δy / Δx + π;
numeric α₂ = this.Compute(α₁);
Assert.Equals(math.∞, α₂);

co może nie być łatwe do odczytania dla przeciętnego programisty, ale nadal jest łatwe do odczytania dla osoby, która codziennie używa symboli matematycznych .

Lub, robiąc aplikację związaną z fotografowaniem lustrzanek, zamiast:

int aperture = currentLens.GetMaximumAperture();
Assert.AreEqual(this.Aperture1_8, aperture);

możesz zastąpić przysłonę jej symbolem ƒ, pismem zbliżonym do ƒ/1.8:

int ƒ = currentLens.GetMaximumƒ();
Assert.AreEqual(this.ƒ1¸8, ƒ);

Może to być niewygodne : podczas pisania ogólnego kodu C # wolałbym pisać:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.Average()
double sum = this.ProductPrices.Sum();

zamiast:

var productPrices = this.Products.Select(c => c.Price);
double average = productPrices.x̅()
double sum = productPrices.Σ();

ponieważ w pierwszym przypadku IntelliSense pomaga mi napisać cały kod prawie bez pisania, a zwłaszcza bez użycia myszy, podczas gdy w drugim przypadku nie mam pojęcia, gdzie znaleźć te symbole i musiałbym polegać na myszy, aby przejść i przeszukaj je na liście autouzupełniania.

To powiedziawszy, w niektórych przypadkach jest nadal przydatne. currentLens.GetMaximumƒ();z mojego poprzedniego przykładu można polegać na IntelliSense i jest tak łatwy do pisania, ponieważ GetMaximumAperturejest krótszy i bardziej czytelny. Ponadto w przypadku określonych domen z dużą ilością symboli skróty klawiaturowe mogą pomóc w szybszym wpisywaniu symboli niż ich dosłowne odpowiedniki w kodzie źródłowym.

Nawiasem mówiąc, to samo dotyczy komentarzy. Nikt nie chce czytać kodu pełnego komentarzy po chińsku (chyba że sam dobrze znasz chiński). Ale w niektórych językach programowania symbole Unicode mogą być nadal przydatne. Jednym z przykładów są przypisy¹.


¹ Z pewnością nie podobały mi się przypisy w kodzie C #, w którym istnieje ścisły zestaw reguł stylu dotyczących pisania komentarzy. Z drugiej strony w PHP, jeśli jest wiele rzeczy do wyjaśnienia, ale te rzeczy nie są bardzo ważne, dlaczego nie umieścić ich na dole pliku i stworzyć przypis w PHPDoc metody?

Arseni Mourzenko
źródło
ASCII zawiera 37 znaków, których można użyć w identyfikatorach; Spodziewałbym się, że w większości czcionek są one na tyle wyraźne wizualnie, że nawet osoby nie znające alfabetu łacińskiego mogą nauczyć się mówić, że dwa ciągi znaków w różnych czcionkach mają ten sam identyfikator. Ile wysiłku debugowania zmarnuje się, gdy programista użyje „Ф” dla kąta zamiast „Φ”?
supercat
1
@supercat: dobry punkt. Ale podany przykład pokazuje złe użycie narzędzia, a nie to, że samo narzędzie jest złe. Δxlub -∞są poprawnymi zastosowaniami (z pewnymi wadami, które wyjaśniłem w mojej odpowiedzi). Ф/ Φz drugiej strony są tylko znakami, że programista nie rozumie, jak poprawnie nazwać zmienne.
Arseni Mourzenko
1
Jeśli programista chciał małej greckiej litery theta (np. Dla kąta poziomego), czy wiesz, który z podanych przeze mnie symboli jest właściwy? Istnieje wiele grup postaci, które wyglądają bardzo podobnie, jeśli nie identycznie. Gdyby pliki źródłowe miały zawierać dyrektywy określające, jakie znaki mogą współistnieć w obrębie identyfikatorów, które mogą pomóc, ale w przeciwnym razie widzę wiele potencjalnych nieporozumień między zmiennymi nazwanymi dokładnie znakami obcymi a tymi nazwanymi znakami wyglądającymi podobnie.
supercat
1
@ supercat: miałeś na myśli grecką literę phi? Chodzi mi o to, że jeśli programista użyje tego symbolu w aplikacji, w której spodziewany jest termin „funkcja skumulowanej dystrybucji”, każda osoba znająca terminologię i symbole domeny zrozumie, co oznacza Φ. cumulativeDistributionFunctionjest za długi. CDFjest mniej czytelny niż Φ. cumDistFuncjest brzydka. Oznacza to również, że jeśli programista używa w tym kontekście cyrylicy małej litery EF (Ф), jest to po prostu błąd. W ten sam sposób programista mógł użyć niewłaściwego terminu lub niewłaściwego skrótu.
Arseni Mourzenko
1
Jeśli nazwa zmiennej składa się z podkreślników, 0-9, az i AZ, osoba z kopią kodu, która nie obsługuje kopiowania / wklejania (np. Wydruk), może mieć nadzieję na dokładne odtworzenie. Ktoś, kto próbuje skopiować „ɸ” nie wiedząc, co to znaczy, może z łatwością skończyć na „Ф”, a nawet jeśli programista wie, że to „phi”, nie byłoby oczywiste, czy „φ” czy „or” jest właściwy. [Jeden z nich to „Latin Small Letter Phi”, a drugi to „Greek Small Latter Phi” - pojawiają się wyraźnie w tej czcionce komentarza, ale nie w np. Lucida Sans Unicode].
supercat
8

Powiedziałbym:

  1. aby ułatwić nieprofesjonalistom i nowicjuszom uczącym się programowania (np. w szkole) i nie znającym angielskiego I tak nie piszą kodu produkcyjnego. Wiele razy widziałem kod taki jak:

    double upsos, baros;
    cin >> upsos >> baros;
    

    Niech biedny facet napisze to w swoim języku:

    double ύψος, βάρος;
    cin >> ύψος >> βάρος;
    
  2. Nie podoba ci się

    class ☎ {
    public:
        ☎(const char*);
        void 📞();
        void 🎧(👨);
    };
    
    ☎ ☏("031415926");
    ☏.🎧(👨("Bob"));
    ofstream f;
    f.💾();
    
ybungalobill
źródło
Jak na ironię, kod pod „Dont 'you like it” nie wyświetla się poprawnie, co ilustruje powód, dla którego możesz chcieć unikać funky.
Kris,
5

Oczywiście, każdy współczesny kompilator musi dziś radzić sobie z kodem źródłowym Unicode. Na przykład stałe łańcuchowe mogą wymagać znaków Unicode. Ale kiedy to zostanie osiągnięte, dlaczego nie zezwolić również na identyfikatory Unicode? To nic wielkiego, chyba że kod kompilatora zależy od tego, czy znaki są kodami 7-bitowymi.

Ale OP ma rację, o ile: Hindus mówiący w języku hindi musi teraz zachować kod z rosyjskimi identyfikatorami i komentarzami arabskimi. Co za koszmar dla biednego Chińczyka, który powinien przeprowadzić kontrolę jakości i nie potrafi odczytać żadnego z powyższych 3 alfabetów!

Dlatego teraz zadaniem organizacyjnym jest upewnienie się, że identyfikatory programów i komentarze są napisane we wspólnym języku. Nic na to nie poradzę, ale myślę, że to będzie angielski po jakimś czasie.

Ingo
źródło
Problem z dopuszczaniem identyfikatorów Unicode polega na tym, że kod źródłowy może zawierać informacje, które są semantycznie ważne, ale nie można ich wydrukować. Na przykład, jeśli klasa deklaruje pole А, jego konstruktor akceptuje parametr Α, a instrukcja konstruktora mówi var x = A.boz();, że Aodwoływałaby się do pola, parametru, a może czegoś innego? Jak można powiedzieć?
supercat
1
Tak, ale wtedy tylko kilka znaków wygląda podobnie, a następnie, jak to często bywa, kwestia stylu, wytycznych dotyczących kodowania i zapewnienia jakości, które musiałyby zapewnić, że nie użyjesz 3 różnych znaków, które wyglądają jak A w jedno miejsce. OTOH, będąc miłośnikiem wolności, brzydzę się zakazaniem czegoś tylko dlatego, że nie ma pewności, że ktoś mógłby go nadużyć.
Ingo
Chyba jestem zdania, że ​​programy powinny być wprowadzane albo w formacie czytelnym dla człowieka, albo w formacie, który nie jest ograniczony do bycia zunifikowanym plikiem tekstowym (ale może zawierać stany połączone liniami, adnotacje dołączone do rzeczy itp.). Myślę, że wiedza o tym, że „to, co widzisz, jest - przynajmniej semantycznie - tym, co istnieje”, i myślę, że różne programy powinny wyglądać inaczej. Jeśli istnieją standardy, które zabraniają używania identyfikatorów, które byłyby bliskie, ale nie do końca pasowały, identyfikatory w bliższym zakresie, to mogłoby pomóc.
supercat
4

Myślę, że sensowne jest dopuszczanie znaków Unicode w ciągach znaków i komentarzach. A jeśli i tak lexer i parser muszą w tym celu obsługiwać Unicode, autor kompilacji prawdopodobnie otrzymuje za darmo obsługę znaków Unicode w identyfikatorach, więc wydawałoby się, że dowolne ograniczenie pozwala na stosowanie tylko znaków ASCII w identyfikatorach.

nikie
źródło
8
Nie całkiem. W literałach łańcuchowych znaki spoza ASCII można traktować jako nieprzezroczyste. W przypadku identyfikatorów musisz podjąć decyzję, które znaki są prawidłowe i czy je znormalizować (np. Czy to várto samo, co vár?)
dan04,
4

Moim zdaniem jest to wyłącznie ze względów marketingowych . A dodatkowo może utrudnić nam życie.

Argumenty marketingowe

Znasz te zwariowane listy funkcji, którymi może się pochwalić większość języków? Jest to zasadniczo bezużyteczne, ponieważ jest tak dalekie od języka, że ​​nie dostarcza wielu informacji na temat konkretnego, ale pozwala szybko ubierać tabele za pomocą haczyków i krzyżyków i słusznie dochodzić do wniosku, że skoro X ma więcej tyknięć niż Y, musi bądź lepszy.

Cóż, obsługa identyfikatorów w Unicode jest jedną z tych linii. Nie ma znaczenia, że ​​w porównaniu ze wsparciem dla Lambda, Ogólnym wsparciem programowania itp. Może nie być wiele, ludzie rysujący tabele nie dbają o jakość każdej linii, tylko o ich liczbę.

I dlatego mogą się pochwalić: „Ach, z Y nie masz obsługi Unicode dla twoich identyfikatorów! W X tak, więc dla studentów jest to o wiele łatwiejsze!”

Błąd dostępności

Niestety argument dotyczący dostępności jest błędny.

Och, rozumiem, że możliwość napisania „résultatDuJetDeDé” zamiast „diceThrowResult” (tak, jestem Francuzem) może wydawać się wygraną w krótkim okresie ... jednak są wady!

Programowanie polega na komunikacji

Twój program jest przeznaczony nie tylko dla kompilatora (który może mniej obchodzić identyfikatory, których używasz), ale także dla twoich towarzyszy. Muszą być w stanie to przeczytać i zrozumieć.

  • jego odczytanie oznacza możliwość wizualizacji użytych znaków, Unicode nie jest tak dobrze obsługiwany przez wszystkie czcionki
  • zrozumienie go oznacza poleganie na identyfikatorach - chyba że uzupełnisz je długimi komentarzami, ale to narusza zasadę SUCHEGO.

Oczywiście, twój kolega z klasy może mówić tym samym językiem co ty (nie jest to oczywiste, miałem zajęcia z programowania z Niemcami, Hiszpanami, Libanesem i Chińczykami), a także twój nauczyciel ... ale załóżmy, że jakoś pracujesz nad tym w domu i nagle potrzebuję pomocy: Internet jest świetny, możesz rozmawiać z tysiącami ludzi, którzy znają rozwiązanie, odpowiedzą tylko, jeśli zrozumieją twoje pytanie. A ty musisz zrozumieć ich odpowiedzi, jak również.

Programowanie wymaga zrozumienia

Dostępność i inicjacja wymagają oparcia się na bibliotekach, aby wykonać ciężkie podnoszenie dla ciebie: nie chcesz wymyślać warstwy IO, aby czytać / pisać na konsoli podczas pierwszego zadania.

  • W jakim języku są napisane te biblioteki?
  • W jakim języku te biblioteki są udokumentowane?

Jeśli odpowiesz na arabski marokański, będę zaskoczony.

O ile nie polegasz tylko na wykładach, w których asystujesz, i którzy prezentują obszerną dokumentację na temat każdej funkcji biblioteki, której będziesz potrzebować (a być może nawet przetłumaczonych bibliotek), będziesz musiał nauczyć się odrobiny języka angielskiego. Ale prawdopodobnie i tak zrobiłeś już na długo przed rozpoczęciem tego kursu programowania.

Angielski jest...

... lingua franca programistów (i większości naukowców).

Im wcześniej ktoś się do tego przyzna i zamiast tego walczy z nim, tym szybciej można naprawdę się uczyć i robić postępy.

Niektórzy nieuchronnie się temu przeciwstawią i słusznie będą bronić swojego prawa do mówienia wybranym przez siebie językiem (zwykle językiem ojczystym), jednak, jak wykazał Babel, im więcej języków jest używanych, tym trudniejsza jest komunikacja.

Nadal...

Tak, jak wielokrotnie argumentowano, pewne wsparcie dla Unicode (głównie symbole) może znacznie ułatwić zrozumienie dla ludzi, którzy muszą na przykład tłumaczyć wzory matematyczne lub fizyki na kod. Wadą jest to, że niektóre symbole są przeciążone, ale i tak może to pomóc.

Więc dlaczego ?

Jak już powiedziano, tak naprawdę nie chodzi o wygodę użytkownika, ale o roszczenia marketingowe. Jest to również bardzo łatwe, ponieważ parser i tak już rozpoznaje ciągi znaków i komentarze w Unicode, więc większość przeskakuje.

I mogą być korzyści dla niektórych użytkowników.

Ale osobiście zajmę się tylko kodem napisanym przy użyciu angielskich identyfikatorów. Nie obchodzi mnie, czy potrzebujesz mojej pomocy z twoim fragmentem kodu, czy twoja biblioteka jest po prostu niesamowita i mógłbym wiele zyskać, korzystając z niej: jeśli jej nie zrozumiem, będę musiał to zignorować.

Matthieu M.
źródło
Więc jesteś jednym z tych, którzy chcą upiec w rzeczywistości de facto historyczne w de jure (przepraszam za brak akcentów, dziś wydaje się, że nikogo to nie obchodzi)?
Milind R
@MilindR: Jestem jednym z tych, którzy uważają, że świat byłby lepszym miejscem, gdyby wszyscy mówili tym samym językiem; i jestem wystarczająco pragmatyczny, aby rozważyć angielski jako rolę, mimo że jestem Francuzem. Mogę być przekonany, że podzbiór Unicode może być ogólnie pomocny (litery greckie, dla matematyki / fizyki). Rozumiem, że do nauczania programowania pomocny jest język programowania, w którym uczeń może wyrazić identyfikatory w swoim własnym języku; nie wymaga to jednak, aby wszystkie języki obsługiwały pełne identyfikatory Unicode. To moja osobista opinia, zrób z tego co chcesz :)
Matthieu M.
3

Jak zamierzasz wpisać identyfikatory ASCII na chińskiej klawiaturze? Kilka słów kluczowych w języku to jedna rzecz, a zrobienie całego kodu w ten sposób to inna sprawa.

Programiści powinni mieć prawo i możliwość wywoływania swoich zmiennych, jak chcą. To nie twoja sprawa w jakim języku.

Jeśli czujesz się tak mylić kod z identyfikatorów, które mają symbole z języków cudzych w nich czyta, to jestem pewien, że dokładnie zrozumieć, jak mylić one czują, kiedy mają używać identyfikatorów z symbolami od Twojego języka.

DeadMG
źródło
4
Piszę tę wiadomość za pomocą klawiatury „rosyjskiej”. Znalazłem klawiaturę chińską ( goo.gl/U1q0m ) i tak naprawdę nie widzę żadnej różnicy w stosunku do rosyjskiej ( goo.gl/af04R ). Nawiasem mówiąc, zauważ, że oba mają układ łaciński wraz z rodzimym.
Egor Tensin
2
Powiedzmy, że używam identyfikatorów za pomocą cyrylicy. Ale co z Chińczykami utrzymującymi mój kod? Powiedzmy, że zna litery łacińskie, ale teraz jest przygotowany do obsługi zupełnie innego zestawu znaków! Nie wspominając już o arabskich ozdobnych literach itp.
Egor Tensin
2
Trzeci akapit to dokładny powód, aby używać tylko angielskiego, prawda?
Anton Barkovsky
9
@Egor: To jest powód, dla którego zespół lub kierownik projektu powinien wprowadzić regułę. Ale nie jest to powód, dla którego język lub implementacja wymusza to. Zespół lub firma mogą zawsze ograniczyć identyfikatory - nie mogą rozszerzyć dostępnego zestawu. Dlatego oryginalny zestaw powinien być tak duży, jak to możliwe.
DeadMG
3
„Jak zamierzasz wpisać identyfikatory ASCII na chińskiej klawiaturze?” - dokładnie tak samo jak na angielskiej klawiaturze. Wybrałeś zły przykład; Chińskie (i japońskie) są zwykle wprowadzane jako angielskie litery opisujące wymowę, a następnie wyświetlana jest lista pasujących chińskich / japońskich, z których użytkownik może wybrać poprawny, jeśli domyślny jest nieprawidłowy (nowoczesne systemy używają analizy kontekstu, aby upewnić się, że zazwyczaj jest).
Michael Borgwardt
2

Zgodnie z PEP 3131 - Obsługa identyfikatorów spoza ASCII z 2007 r., Pierwsza część uzasadnienia stanowi:

Kod Python jest pisany przez wiele osób na świecie, które nie znają języka angielskiego, a nawet dobrze znają system pisania w języku łacińskim. Tacy programiści często chcą definiować klasy i funkcje za pomocą nazw w swoich językach ojczystych, zamiast wymyślać (często niepoprawne) tłumaczenie angielskiego pojęcia, które chcą nazwać. Dzięki zastosowaniu identyfikatorów w ich języku ojczystym poprawia się przejrzystość i łatwość konserwacji kodu wśród użytkowników tego języka.

Nie badałem jeszcze innych języków, ale powinien to być jeden z powodów, dla których dodali wsparcie.

吴 烜 _ 中文 编程
źródło
1

Naprawdę ułatwiłoby to życie (przynajmniej niektórym z nas), gdyby kompilator nie obsługiwał Unicode. Identyfikatory od prawej do lewej są okropne. Połączone alfabet rzymski i identyfikatory Unicode od prawej do lewej są jeszcze gorsze.

Złą rzeczą w nieobsługiwaniu jest to, że niektóre kreatory GUI pobierają tekst wstawiony dla elementu i automatycznie używają tego tekstu jako identyfikatora elementu. Co dokładnie zrobiliby z tekstem Unicode na tych elementach? Obawiam się, że nie ma łatwej odpowiedzi.

Komentarze od prawej do lewej w Unicode również mogą być zabawne. Na przykład w VS 2010 komentarze XML są wyświetlane (poprawnie) jako RTL w kodzie ... ale gdy używasz Intellisense do pobierania identyfikatora w innym miejscu w kodzie, podpowiedź wyświetla (niepoprawnie) LTR. Może lepiej, gdyby w ogóle nie było wsparcia? Ponownie, nie jest to łatwe połączenie.

sq33G
źródło