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

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?

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?}

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.💾();
   

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.

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.

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ć.

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.

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.

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.