Kodowanie w innych (mówionych) językach

Zawsze się nad tym zastanawiałem i nie mogę znaleźć żadnej wzmianki o tym w Internecie. Kiedy sklep z, powiedzmy, Japonii, pisze kod, czy byłbym w stanie przeczytać go po angielsku? A może języki, takie jak C, PHP, cokolwiek, mają japońskie tłumaczenia, które piszą?

Myślę, że pytam, czy każdy koder na świecie zna wystarczająco angielski, aby używać dokładnie tych samych zastrzeżonych słów co ja?

Czy ten kod:

If (i < size){
    switch
        case 1:
            print "hi there"
        default:
            print "no, thank you"
} else {
    print "yes, thank you"
}

wyświetlać dokładnie to samo, co ja teraz widzę, po angielsku, czy też jakaś inna osoba nieanglojęzyczna widziałaby słowa „if”, „switch”, „case”, „default”, „print” i „ else ”w swoim języku ojczystym?

EDYCJA - tak, to jest poważne. Nie wiedziałem, czy różne lokalizacje języka mają różne słowa kluczowe. lub jeśli w ogóle istnieją różne lokalizacje.

Jeśli dobrze zrozumiałem, pytanie w rzeczywistości brzmi: „czy każdy koder na świecie zna wystarczająco angielski, aby używać dokładnie tych samych zastrzeżonych słów co ja?”

No cóż ... nie chodzi tu o język angielski, ale o słowa zastrzeżone w języku programowania. To znaczy, kiedy zaczynałem około 10 lat temu, nie miałem pojęcia o języku angielskim, a mimo to potrafiłem programować proste rzeczy, ucząc się języka programowania, nawet jeśli nie wiedziałem, co mają na myśli (po angielsku). Właściwie to pomogło mi nauczyć się angielskiego.

Na przykład. Wiem, że muszę zrobić „iteración” (oczywiście iterację), musiałem napisać:

 for( i = 0 ; i < 100 ; i++ ) {}

Dla mnie „za”, „;” oraz „++”, gdzie proste obce słowa lub symbole. Później dowiaduję się, że „for” znaczyło „para”, a „while” znaczyło „mientras” itd., Ale w międzyczasie nie potrzebowałem znać angielskiego, ale w moim przypadku potrzebowałem znać „C”.

Oczywiście, kiedy musiałem nauczyć się więcej rzeczy, musiałem nauczyć się angielskiego, ponieważ dokumentacja jest napisana w tym języku.

Tak więc odpowiedź brzmi: nie, nie wiem, czy, podczas, itp. W moim ojczystym języku. Widzę je po angielsku, ale nie znaczyły dla mnie żadnej innej rzeczy, którą z kolei oznaczały dla języka programowania.

Jest jak instrukcja switch w bash: case .. esac. Co to jest „esac” ... dla mnie koniec instrukcji switch w bash.

Myślę, że to właśnie nazywamy „abstrakcją”

W języku Java niektóre metody muszą być nazwane (przynajmniej częściowo) w języku angielskim ze względu na konwencję JavaBeans.

Konwencja ta wymaga, aby właściwość X została ustanowiona za pomocą pary metod getX () i setX (). Tutaj we francusko-Kanadzie, gdzie niektórzy programiści są zobowiązani do kodowania w języku francuskim, prowadzi to do następującej parodii:

interface Foo {

  Color getCouleur();

  void setCouleur(Color couleur);
}

Mam problem ze znalezieniem odniesień, ale przypominają mi się trzy historie.

Haker Lisp broni bezsensownych funkcji, takich jak „cdr” i „car”, porównując je z programowaniem w Twoim języku obcym: obcym http://people.csail.mit.edu/gregs/ll1-discuss-archive-html/msg01171. html

Kiedy Yukihiro Matsumoto ("Matz") zaczął tworzyć Rubiego, użył angielskich słów kluczowych, mimo że całą dokumentację pisał po japońsku! . Przez kilka lat nie istniała angielska dokumentacja dla Rubiego i bardzo niewielu Amerykanów używało tego języka. Ale teraz jest to język światowej klasy, a fakt, że urodził się w Japonii, ma znaczenie tylko historyczne. Gdyby język używał słów kluczowych w hiraganie, znacznie trudniej byłoby mu zdobyć popularność.

Kiedyś przeczytałem esej - może ktoś inny go znajdzie, dziś Google nie jest pomocny - sugerujący, że tłumaczenie słów kluczowych było błędne, ponieważ słowa nie są w rzeczywistości angielskie - to żargon. Nie tylko słowa para i pour nie tylko nie mają takiego dokładnego znaczenia, jakie dla ma w języku angielskim, ale dla nie-programistów wyrażenie „pętla for” jest jibberish. Nawet Amerykanie muszą nauczyć się nowego znaczenia. Zatem przetłumaczenie powierzchownego znaczenia słów na inny język jest bardziej jak zrobienie wielojęzycznej gry słów, a nie bycie pomocnym.

Naprawdę nie myślałem wcześniej zbyt wiele o programowaniu w języku japońskim, ale zaczynamy, używając przykładowego kodu pytania.

Używanie tylko instrukcji językowych w języku japońskim ze zmiennymi w języku angielskim:

// In Japanese, it makes more sense to put the keywords/modifiers as
// postfix expressions rather than prefix expressions.
(i < size)か {
     (l[i])は {
     1だ:
         「もしもし。」を書く;
     省略時値:
         「いいえ、いいですよ。」を書く;
     }
} ない {
     「はい、ありがとうございます。」を書く;
}

Jak wiele osób już zauważyło, w większości języków programowania wystarczy nauczyć się kilku słów kluczowych, więc nie ma większego znaczenia, czy są one w języku angielskim (lub w języku innym niż twój). To tylko symbol, który kojarzysz z jakąś konstrukcją. Na przykład w VB masz „TO”, które w wielu językach w stylu C byłoby „{” i nie robi dużej różnicy w czytelności (cóż, przynajmniej tak to widzę, będąc nieanglojęzycznym osoba mówiąca w ojczystym języku).

Ale czasami rzeczy mogą się skomplikować i gdzie wybór (naturalnego) języka ma znaczenie, dotyczy nazewnictwa identyfikatorów. Jeśli nazwy zmiennych, funkcji, klas itp. Nie mają dla Ciebie znaczącej nazwy ze względu na barierę językową, przestrzeganie nawet najprostszego kodu może być dość trudne.

Pamiętam, że ktoś dał mi kiedyś krótki fragment kodu Actionscript wzięty z jakiegoś bloga. Nazwy były w języku niemieckim, a ponieważ nie mówię ani słowa w tym języku, rzeczy mogłyby również nazywać się var_123, var_562 lub func_333 (i prawdopodobnie byłoby mi łatwiej zapamiętać nazwy lub przynajmniej mieć szansa na poprawną pisownię bez kopiowania i wklejania). Ponieważ był to krótki, samodzielny fragment, użyłem internetowego tłumacza, aby nadać tym zmiennym i funkcjom znaczące nazwy w moim ojczystym języku (hiszpańskim), a potem wszystko było jasne. Chodzi o to, że kod był w rzeczywistości prosty, ale byłem w stanie wyciągnąć z niego sens tylko bez zbytniego (niepotrzebnego) dodatkowego wysiłku, kiedy pokonałem barierę językową.

Od tego czasu przerzuciłem się na używanie języka angielskiego do nazewnictwa identyfikatorów. Czy ci się to podoba, czy nie, jest to „koine” do programowania, inżynierii i ogólnie spraw technicznych. Większość interfejsów API jest napisana w języku angielskim, podobnie jak większość dokumentacji (i prawdopodobnie najlepsze zasoby, jakie można znaleźć, są również w języku angielskim). Miło na marginesie, dzięki temu twój kod jest bardziej spójny z kodem, z którym prawdopodobnie będziesz wchodzić w interakcje, i myślę, że jest bardziej zwarty i zwięzły niż inne języki, takie jak hiszpański (co w przeciwnym razie byłby moim naturalnym wyborem).

Oczywiście, jeśli nie rozumiesz przynajmniej części angielskiego, problem pozostaje ten sam, więc nie jest to idealne rozwiązanie. Jednak biorąc pod uwagę liczbę programistów z wielu różnych krajów, istnieje duże prawdopodobieństwo, że wspólnym językiem komunikacji (za pomocą kodu i oczywiście w inny sposób) będzie język angielski. Wybór języka angielskiego jest więc chyba najlepszą opcją, mimo że nie byłoby to idealne rozwiązanie tego problemu.

Język programowania definiuje słowa kluczowe i standardowe nazwy klas, a najlepszą praktyką jest nadawanie zdefiniowanych przez użytkownika typów, zmiennych i funkcji także nazw angielskich (jako obcego mówca mogę powiedzieć ;-).

Więc tak, jeśli wszystko jest w porządku, będziesz mógł odczytać kod.

Jednak języki takie jak Java i Perl zezwalają na pełny zestaw Unicode dla identyfikatorów, więc jeśli ktoś napisze nazwy swoich klas w kanji, prawdopodobnie będziesz miał problem.

Aktualizacja: dla Perla istnieje moduł żartów, który pozwala pisać w Perlu po łacinie. Ale to naprawdę tylko żart. Nikt nie używa takich rzeczy na poważnie.

Druga aktualizacja: Idea zlokalizowanych języków programowania nie jest aż tak śmieszna. Język makr programu Excel jest zlokalizowany, ale na szczęście jest przechowywany w jednym języku kanonicznym (angielskim) w pliku, więc lokalizacja to tylko warstwa na wierzchu normalnej rzeczy. Takie rzeczy mają sens tylko w przypadku małych „programów”, w przypadku „prawdziwych” programów staje się to trudne do utrzymania.

Faktycznie tam są niektóre języki programowania Nieanglojęzyczna oparte (Wikipedia)

Jestem Norwegiem, ale zawsze używałem angielskiego dla całego kodu z wyjątkiem wyjścia (ignorując jakiś głupi kod ze szkoły). Właściwie to zazwyczaj piszę wszystko po angielsku, a następnie tłumaczę to na mój język ojczysty, używając gettext (lub czegoś podobnego).

Jestem Brytyjczykiem i często napotykamy na konflikt pisowni amerykańsko-brytyjskiej. Dzieje się tak często w przypadku terminów związanych z programowaniem, takich jak Initialise () lub Initialize (), Analyze () lub Analyze () itp. Może to (prowadziło) do problemów z zastępowaniem metod i czasami jest trudne do wykrycia.

Ponieważ framework (w naszym przypadku C #) został zaprojektowany przez Amerykanów, stwierdziliśmy, że najlepiej jest być spójnym i używać amerykańskiej pisowni. Przyjmujemy nawet Color.

W naszych zespołach programistycznych mamy mieszankę narodowości, a większość osób spoza Wielkiej Brytanii ma naturalny skłonność do pisowni amerykańskiej.

AppleScript był kiedyś dostępny w dialektach francuskim i japońskim. Nie wiem, dlaczego został wycofany.

Przechodząc na wyższy poziom, co z możliwością zastępowania symboli?

Po obejrzeniu języków takich jak Brainf ** k i Whitespace pomyślałem o stworzeniu takiego języka: byłby identyczny z C, z wyjątkiem używania nawiasów zamykających do otwierania, nawiasów otwierających do zamykania, zamiany znaczeń + i -, * i / ,; i:,> i <itp.

Koncepcja to nic innego jak sztucznie zmodyfikowany kompilator C. Ale podobnie jak inne myślenie o słowach kluczowych, zmusza Cię do przemyślenia kilku podstawowych założeń, jeśli nigdy wcześniej nie myślałeś o takich rzeczach. Dawny:

int foo)int i, char c( }
    int six = 2 / 3:
    int two = six + 4:
    if )i > 0( }
        printf)"i is negative"(:
    {
{

Jestem we francuskim zespole tworzącym system oprogramowania w języku C #. Pomimo faktu, że słowa kluczowe języka programowania są pozornie angielskie, wyobrażam sobie, że miałbyś duże trudności z odczytaniem kodu, ponieważ wszystkie nazwy funkcji, zmienne, komentarze do kodu, tabele i kolumny bazy danych, specyfikacje techniczne, protokoły i tak dalej są w Francuski, w tym te urocze akcentowane znaki ç, é, è, ù itd. Nie jestem nawet pewien, czy system działałby w innym miejscu z powodu błędów lokalizacyjnych, takich jak poleganie na przecinku jako domyślnym separatorze dziesiętnym.

W przeciwnym razie WinDev jest popularną platformą programistyczną we Francji, a jej język programowania WLanguage ma słowa kluczowe w języku francuskim lub angielskim, zobacz i przykład tutaj: tekst linku

Jedynym językiem, który widziałem, jest zlokalizowany, jest Excel z jego makrami. Jeśli spróbujesz zsumować kolumnę za pomocą włoskiej wersji pakietu Office, musisz wpisać, SOMMA(A1:A10)a nie SUMA. Jaka szkoda.

Przy okazji, tylko dlatego, że to zabawne, oto jak powinien wyglądać kod z włoskimi słowami kluczowymi:

se (i < size){
    commuta
        caso 1:
            stampa "hi there"
        normalmente:
            stampa "no, thank you"
} altrimenti {
    stampa "yes, thank you"
}

widziałem VBA przetłumaczone na polecenia podobne do hiszpańskich. to jedna z najbrzydszych rzeczy, jakie kiedykolwiek widziano. wstydziłbym się mieć coś takiego na swoim komputerze.

PD: Tak się składa, że ​​wydaje mi się, że hiszpański jest o wiele ładniejszym językiem niż angielski; ale tłumaczenie jest NIEPRAWIDŁOWE

Cóż, jak zauważyli inni, słowa kluczowe i wywołania systemowe prawdopodobnie pozostaną w języku angielskim.

Jednak zrozumienie słów kluczowych języka to tylko niewielka część zrozumienia kodu. Nazwy zmiennych, nazwy funkcji i komentarze mogą być w języku ojczystym autora.

Edycja : Właśnie wróciłem do mojej młodości, w której przeszedłem do tabel mapowania mojego wbudowanego w TRS-80 języka BASIC, aby zmienić słowa kluczowe na francuskie. Mogłem zmienić wszystkie słowa kluczowe, ale nie mogłem zwiększyć żadnego z nich. Stworzony do zabawnych programów.

Nie śmiej się z tego. Kilka lat temu Microsoft ogłosił G # (niemiecki Sharp) - C # z niemieckimi słowami kluczowymi i API. Oczywiście był to żart primaaprilisowy, ale cała strona na ten temat wyglądała tak realistycznie i profesjonalnie (i była na microsoft.com). Straszny.

W pracy używamy dwóch systemów magistrali polowych, oba opracowane w krajach niemieckojęzycznych, które mają przerażającą mieszankę niemieckiego i angielskiego do identyfikacji, w tym kilku uroczych fałszywych przyjaciół. To bałagan.

Nie, angielskie słowa kluczowe i identyfikatory są w porządku. Chociaż niektórzy mogą się spierać, czy powinien to być kolor czy kolor :)

W kilku projektach VBA, nad którymi pracowałem (tak, bardzo wcześnie w mojej karierze) musieliśmy wykryć wersję pakietu Office, która została zainstalowana na komputerze użytkownika i odpowiednio zmienić formuły używane w arkuszach.

Ponieważ programuję w języku portugalskim, „SUM” musiałoby zostać przetłumaczone na „SOMA” i tak dalej, i tak dalej. Po prostu nie mogę sobie wyobrazić pracy niezbędnej do tego w kilku językach. Czy ktoś jeszcze cierpiał z tym problemem?

W niektórych językach zostały przetłumaczone słowa kluczowe. Na przykład formuły programu Excel. Jeśli napiszesz jakieś obliczenia w arkuszu kalkulacyjnym, będzie to w Twoim języku.

Na szczęście nie jest to ogólna praktyka i nawet osoby nie mówiące po angielsku, takie jak ja, dziękują Bogu, że istnieje standardowy język słów kluczowych:

• łatwiej jest dzielić się swoją pracą.
• zapobiega temu, by dokumentacja stała się większym koszmarem, którym już jest.
• Angielskie słowa i zdania są zwykle krótkie i składniowo pragmatyczne. W literaturze języki łacińskie są znacznie piękniejsze, ale z technicznego punktu widzenia angielskie skały.

A gdzie się zatrzymać? Czy możesz sobie wyobrazić C w starożytnej grece?

Słowa kluczowe muszą pozostać w jednym języku i cóż, zaczęło się od angielskiego, niech tak pozostanie. To mogło być najgorsze (język azjatycki?). Musimy więc pisać metody i komentarze po angielsku. Ok, więcej pracy dla nas, ale przynajmniej międzynarodowa baza kodowa pozostaje zgodna.

Jest jednak jeden przypadek, w którym używanie nazw metod w języku ojczystym i komentarzy może być dobrą praktyką: w kraju trzeciego świata. Za kilka miesięcy jadę do Senegalu, aby zarządzać projektem Django. Senegal ma olbrzymi wskaźnik analfabetyzacji, dlatego już świetnie, że poświęcają energię na doskonalenie swojej wiedzy programistycznej. Francuski jest tutaj językiem ojczystym, więc zmuszanie ich do jednoczesnej nauki obsługi komputera ORAZ nowego języka byłoby nieefektywne.

Przy okazji, to byłby twój kod z francuskimi słowami kluczowymi:

Si (i < taille) {
    cas par cas :
        cas 1:
            afficher "salut"
        défaut:
            afficher "non merci"
} sinon {
    afficher "oui, merci"
}

Nie znaczy to, że tłumaczenie słów kluczowych nie ma nic wspólnego z tłumaczeniem napisów. Oczywiście mamy przetłumaczone słowo „cześć” na nasz język. Europejscy programiści używają I18N znacznie częściej niż amerykańscy, aby ich usługa mogła dotrzeć do szerszej publiczności.

Ogólnie rzecz biorąc, większość programistów dostosowuje się do formy angielskiej. Nauczyłem się programowania, gdy miałem 7 lat i mówiłem tylko po hebrajsku (od prawej do lewej) i bez angielskiego, co sprawiło, że było to dość fascynujące doświadczenie.

Problem, który zwykle pojawia się, dotyczy dokumentacji, zmiennych i nazw funkcji. Widziałem swój udział zmiennych w innych językach przy użyciu alfabetu angielskiego.

Jedynym językiem, który znam, a który został przetłumaczony, było stare, dobre logo (wciąż niesamowite).

Kiedy byłem dzieckiem, pojechaliśmy do Francji i pamiętam, że w muzeum, do którego pojechaliśmy, znalazłem wystawę, która pokazywała, jak pisać programy komputerowe. Język był rodzajem BASIC-a i wyraźnie pamiętam, że użyłem POUR zamiast FOR, i tak dalej. Miałem 7 lat i dopiero się nauczyłem BASIC-a i wydawało mi się całkowicie naturalne, że Francuzi mają swój własny dialekt!

Myślę, że to mogło być LSE, które widziałem?

Język skryptowy Filemaker jest zlokalizowany. Skrypty (i dane!) Są przechowywane w okropnej, „trochę kanonicznej” formie.

Jeśli więc napiszesz skrypt w wersji amerykańskiej, a następnie otworzysz go w wersji francuskiej, wszystkie słowa kluczowe i nazwy funkcji wbudowanych będą w języku francuskim. Ale dlaczego nie działa ?! Aha! Wersja francuska używa „,” jako kropki dziesiętnej, dlatego w celu uniknięcia niejednoznaczności używa się „;” aby oddzielić argumenty funkcji - gdzie wersja amerykańska używa "." i „,” odpowiednio. To nawrócenie musisz zrobić sam.

Więc pracujesz przez niesamowicie zły interfejs edycji skryptów (nie możesz pisać skryptów jako plików tekstowych), aby naprawić wszystkie te rzeczy. To biegnie! Wspaniały! Wszystkie wyniki są błędne! O nie! Aha! Data 7 stycznia 2004 r., Którą wprowadziłeś w wersji amerykańskiej, jest interpretowana jako 1 lipca 2004 r. - najwyraźniej daty są nie tylko wyświetlane, ale przechowywane w kolejności zależnej od ustawień regionalnych. Żartuję ? Nie.

[Uwaga: Filemaker 8 i 9 mogą być rozsądne - pracowałem tylko z 3 - 7.]

Twoje pytanie jest interesujące w odniesieniu do Perla, ponieważ jego składnia jest zgodna z (angielskim) językiem naturalnym. Zastanawiam się, czy to utrudnia życie nieanglojęzycznym ...

Oczywiście Perl i Perlers odmawiają gry według konwencjonalnych zasad. Szalony naukowiec Damian Conway napisał moduł Lingua :: Romana :: Perligata , który wykorzystuje czarną magię filtrów źródłowych, aby umożliwić pisanie w języku Perl po łacinie!

Tutaj w Australii nadal musimy przeliterować kolor jak kolor . Jednak wydaje mi się irytujące, gdy inni (australijscy) programiści, pracujący nad australijskim projektem, decydują, że wewnętrzne nazwy zmiennych muszą być pisane po amerykańsku.

Nie ma sensu, IMHO, i18n składni języka . Po prostu zabiłoby wszelką przenośność.

Jedynym wyjątkiem są języki edukacyjne, takie jak LOGO. Zostały zaprojektowane tak, aby ułatwić naukę, więc przenośność nie stanowi problemu.

Czytam dużo kodu, ale problem zawsze dotyczy nazw zmiennych / metod i komentarzy, jeśli komentują swój kod w swoim własnym języku, używając znaków specjalnych języka, takich jak japoński lub cyrylica, mamy kłopoty! ale myślę, że słowa kluczowe pozostaną w języku angielskim.

po włosku

se (i < dimensione){
    scegli
        caso 1:
            stampa "ciao"
        mancante:
            stampa "no, grazie"
} altrimenti {
    stampa "sì, grazie"
}

Aby potwierdzić obawy któregoś z poprzednich plakatów, widziałem kod Fortran z dołączonym makrem do przetłumaczenia wszystkich słów kluczowych z angielskiego na francuski. Pozwól mi nie kontynuować tego.

Musiałem też pracować z kodem jednocześnie zawierającym identyfikatory w języku włoskim, niemieckim, angielskim i francuskim, nie tylko dlatego, że został opracowany w wielu różnych miejscach, ale także dlatego, że główny programista uznał to za zabawę i pomógł mu nie powielać nazw identyfikatorów ( oczywiście z rutynowym 2000 linii długości ...)

Myślę, że WordBasic został zlokalizowany. WordBasic był używany do pisania makr w programie Word przed użyciem VBA.

Jeśli dobrze pamiętam, tylko WordBasic napisany w angielskiej wersji będzie działać na wszystkich zlokalizowanych wersjach. Gdybyś napisał wersję holenderską, mógłbyś ją wykonać tylko na holenderskim słowie.