Dlaczego nie ma więcej wielojęzycznych języków programowania?

Czy są jakieś języki programowania, które są dostępne i mogą być rozszerzane w więcej niż jednym języku naturalnym?

Na przykład wersja angielska z do..whilepętlą, wersja hiszpańska z hacer..mientaspętlą, wersja francuska z faire..pendanti wersja holenderska z doe..terwijl.

Jedynym „językiem programowania”, jaki mogę sobie wyobrazić w tego rodzaju implementacjach, jest Microsoft VBA.

Pytanie dodatkowe: Dlaczego jest tak mało języków programowania, które są dostępne w wielu językach?

Nazwy funkcji w formułach programu Excel są zlokalizowane, w których można użyć angielskiego wyrażenia lub lokalnego odpowiednika.

Doprowadziło to do niezliczonej liczby przypadków łamania arkuszy kalkulacyjnych podczas przemieszczania się między regionami i językami użytkownika. Utrudnia to również wyszukiwanie informacji o funkcjonalności, ponieważ lokalna dokumentacja jest zlokalizowana i nie wspomina angielskich nazw rzeczy, i odwrotnie, prośba o SO z lokalnymi nazwami jest w zasadzie bez znaczenia dla większości czytelników.

Słowa kluczowe powinny być postrzegane jako nieprzezroczyste monikery, które akurat po prostu pasują do znaczenia angielskich słów użytych do ich przeliterowania. Istnieje wielu programistów nieanglojęzycznych, którzy nie wiedzą, co oznacza połowa ich słów kluczowych.

W poprzednim stuleciu, zwłaszcza w latach 1960-1970, były to języki programowania inne niż angielski. We Francji mieliśmy PAF i LSE z francuskimi słowami kluczowymi. WW2 Niemcy miały Plankalküll autorstwa K.Zuze. W Związku Radzieckim A.Ershov zaprojektował niektóre języki (np. Rapira ) z rosyjskimi słowami kluczowymi. IIRC PAF (zaprojektowany i wdrożony przez mojego nieżyjącego ojca, gdy byłem dzieckiem - wczesne lata 60.) można również sprzedawać ze słowami kluczowymi w języku angielskim (lub rosyjskim lub niemieckim). Niektóre języki, np. APL , w ogóle nie miały żadnych słów kluczowych. Inne języki ( PL / I ) nie zostały zastrzeżonesłowa kluczowe. I można ponownie zdefiniować słowa kluczowe z technik preprocesora (np Dziś w C #define si if& #define sinon elsefrancuskich studentów ....; podobne makro opartych sztuczki są możliwe w PL / I lub nawet Common Lisp).

Ale ITzostał opracowany głównie w kraju anglojęzycznym (USA). Tak więc języki programowania i ich implementacje miały angielską specyfikację i dokumentację oraz angielskie słowa kluczowe. Dlatego każdy programista musi umieć czytać techniczny angielski i nie ma żadnej wartości dodanej do „lokalizowania” języka programowania (a nawet czyni to, utrudniając korzystanie z innego oprogramowania, jak podano w innym miejscu). Obecna dominacja techniczna i ekonomiczna w krajach anglojęzycznych wymaga dziś od wszystkich inżynierów czytania angielskiego (jestem pewien, że nawet inżynierowie oprogramowania z Korei Północnej, Chin lub Iranu potrafią czytać dokumentację w języku angielskim oraz kod z angielskimi słowami kluczowymi i identyfikatorami) . Zatem nie ma już wystarczającej wartości dodanej, aby „zlokalizować” język programowania (z wyjątkiem być może nauczania elementarnego dzieci w szkole średniej).

Ponadto angielski ma wiele krótkich słów kluczowych (porównaj sinonw języku francuskim z elseangielskim lub mettrez francuskiego na putangielski), więc użycie słów kluczowych w języku angielskim ma niewielką przewagę ...

^{Być może za sto lat Chiny mogą stać się dominującym krajem IT, a niektóre chińskie języki programowania mogą się rozwijać. Nie wiemy, co by się wtedy wydarzyło ....}

PS. Dominacja języka angielskiego nie jest specyficzna dla IT. Nawet jeśli Wielka Brytania opuści Unię Europejską - scenariusz Brexitu - de facto oficjalnym językiem WE pozostanie angielski (który wtedy nie będzie językiem żadnego z krajów członkowskich UE), a projekty ICT H2020 zostaną napisane w języku angielskim.

Istnieją bardzo dobre powody, dla których profesjonalne języki programowania nie są tłumaczone.

1) Wysiłek: przetłumaczenie współczesnego języka byłoby ogromnym zadaniem. Weź Javę - przetłumaczenie około 50 słów kluczowych byłoby małym zadaniem, ale musiałbyś także przetłumaczyć pełną standardową bibliotekę, która składa się z tysięcy klas i metod oraz powiązanej dokumentacji.

2) Zgodność: Nawet jeśli przetłumaczono podstawowy język i bibliotekę standardów, nadal nie można używać bibliotek stron trzecich i kodu, który nie został przetłumaczony. Biblioteki i kod innych firm stanowią główną część tego, co czyni język atrakcyjnym i użytecznym. W przypadku przetłumaczonych wersji każdy język musiałby uruchamiać ekosystem dla każdego tłumaczenia od zera. Wszystkim byłoby gorzej.

3) Programiści i tak muszą znać angielski. Wiele standardów takich jak HTTP, CSS, HTML i tak używa języka angielskiego do identyfikacji. Nie można ich przetłumaczyć, ponieważ słowa są upieczone w standardzie.

Ponieważ programiści i tak muszą znać język angielski, tworzenie przetłumaczonych wersji języków programowania będzie miało tylko wady i nie przyniesie żadnych korzyści.

To powiedziawszy, dla języków przeznaczonych dla zwykłych programistów w przeciwieństwie do profesjonalnych programistów, sensowne może być tworzenie przetłumaczonych wersji. Tak jest w przypadku VBA i uważam, że AppleScript istniał również w przetłumaczonych wersjach.

Nie znam żadnych innych języków, z wyjątkiem być może jakiejś naprawdę starej ezoterycznej wersji BASIC, która zwykle przychodziła z wieloma dziwnymi względami, więc pozostanę przy dodatkowym pytaniu: dlaczego jest tak mało przetłumaczonych języków programowania:

Uważam, że jest to po prostu dodatkowa złożoność, której kompilator i implementatorzy bibliotek nie widzą zbytniej potrzeby. Oto kilka powodów, które moim zdaniem przyczyniają się.

• Ograniczysz odbiorców swojego kodu, jeśli nie będziesz trzymał się „uniwersalnego” języka. Jasne, nie wszyscy znają angielski, ale to samo dotyczy każdego języka.
• Pojedyncze słowa kluczowe niekoniecznie są jednym słowem we wszystkich językach, co komplikuje parsowanie. Nigdy nie sprawdzałem, ale mogę sobie wyobrazić, że istnieje spora ilość specjalnej obudowy, która poradzi sobie z pojedynczym, wielosłowowym słowem c ++ typu „long long”.
• Jeśli zaczniesz tłumaczyć słowa kluczowe, czy weźmiesz również pod uwagę ustawienia narodowe i sposób formatowania liczb? Na przykład przecinek i kropka jako separator dziesiętny. Lub wymagać, aby rzeczowniki niemieckie były pisane wielką literą?
• Zdecydowana większość tekstu w danym programie to zmienne, metody i nazwy klas, nie wspominając o komentarzach. Chociaż z pewnością istnieją biblioteki napisane w innych językach, konieczność utrzymywania tłumaczeń kodów źródłowych wszystkich bibliotek dla wszystkich użytkowników byłaby ogromnym obciążeniem dla większości programistów, nie wspominając o dodatkowej złożoności podczas dyskusji na temat takiego kodu.
• Kompilatory będą musiały zrozumieć wszystkie zaimplementowane języki. Być może nawet wiele języków w tym samym pliku. Niewielki wyczyn z pewnością dla komputera, ale dodatkowa praca. Być może skończysz z tym samym słowem kluczowym, co oznacza różne rzeczy w różnych językach lub terminy będą zbyt dwuznaczne, by dobrze je czytać.
• (ok, opinia) Z pewnością większość osób, które miały do ​​czynienia z dokumentami MS Office zaprogramowanymi i sformatowanymi w różnych językach, odrzuci ten pomysł jako nie warty kłopotów.

Osobiście podoba mi się, gdybyśmy mogli pracować z kodem w bardziej uporządkowany sposób, w edytorze, który faktycznie rozumiał kod jako taki, jaki jest, instrukcje, instrukcje itp., Które pozwoliłyby nam robić wiele interesujących rzeczy , może nawet obsługuje automatyczne tłumaczenie. Dla każdego, kto zastanawia się, o co mi gadam, sprawdź obraz Smalltalk i przeglądarkę refaktorów i wyobraź sobie, co mogłoby się stać, gdyby zyskał większą przyczepność.

Jeśli masz język zdefiniowany w kategoriach „znaczników symbolicznych” na jednym poziomie i „oznaczników znaczników powierzchniowych” na drugim, z dobrze zdefiniowanymi odwzorowaniami między nimi, z pewnością byłoby to możliwe.

Wyobraźmy sobie język, w którym masz if, while... do, switchi wszystkie inne słowa kluczowe zdefiniowane (jakoś) w standardzie, można wysyłać bibliotek systemowych w „formacie tokenized”, o kodzie lokalnym w formie pisemnej non-tokenized. Wtedy rzeczywisty kompilator działa na warstwie tokenizowanej i może być dobrze.

To jednak nie jest cała historia. Nadal trafilibyście w sytuacje, w których biblioteki pochodzą z miejsca, które nie jest „biblioteką standardową”, powiązaną z nazwami funkcji. A te nie miałyby kanonicznego odwzorowania między językami i wymagałyby tłumaczenia na język lokalny, aby były przyjemne w użyciu, lub kończyłyby się miszmaszem języków w kodzie źródłowym.

Wszystkie udzielone odpowiedzi to świetne odpowiedzi, ale i tak dam dwa centy.

Na początku obliczania technicznej, kulturowej i ekonomicznej dominacji USA i Wielkiej Brytanii logiczne było, które języki, które odniosły największy sukces, zostały utworzone przy użyciu angielskich słów.

Później, gdy oprogramowanie stało się branżą , stało się także przedsięwzięciem globalnym. Nie jest tajemnicą, że jest mniej programistów, niż potrzeba, więc firmy produkujące oprogramowanie, a zwłaszcza firmy definiujące branżę, takie jak IBM, zaczęły zatrudniać programistów ze wszystkich części świata: Rosji, Pakistanu, Indii, Francji, Niemiec, Izraela itp. głównie do programowania w już istniejących globalnych językach, które były już oparte na języku angielskim, a także do tworzenia nowych języków, a dla tego odmiennego źródła dla programistów już istniejący wspólny język był lepszy niż jakikolwiek inny język.

Ostatnio ruch otwartego oprogramowania i wolnego oprogramowania sprawił, że tworzenie oprogramowania stało się jeszcze bardziej globalne niż wcześniej. Niektóre otwarte projekty oprogramowania, w tym niektóre platformy programistyczne, języki i frameworki, to ogromne projekty z udziałem setek współpracowników.

W jakim języku osoba z Izraela będzie współpracować z osobą ze Sri Lanki? Najprawdopodobniej nie mówią ani nawet nie czytają ojczystego języka. Więc angielski przychodzi na ratunek.

Polub to, czy nie, angielski jest językiem globalnych przedsięwzięć . I nie dlatego, że Ameryka go popycha, ale dlatego, że świat to pociąga.

Parafrazując Jay Walker :

Twój język ojczysty jest tym, którego najczęściej używasz na co dzień i zawsze będzie w centrum twojego serca i mózgu, ale z angielskim jesteś częścią szerszej rozmowy.

Zobacz wideo „English Mania” .

Konkluzja:

Języki programowania, które używają różnych języków, będą nadal istnieć i będą wymyślane (jak Scratch oparty na tokenach graficznych), ale przynajmniej w najbliższej przyszłości będzie stosunkowo niewiele.

Angielski jest także językiem „bez akcentu”, a także nie masz dziwnych znaków, które wymagają kodowania innego niż ASCII. Jestem Włochem i czasami mam problemy z kodowaniem, jeśli używam włoskiego układu klawiatury lub znaków akcentowanych, takich jak àèéìòù. Ponadto „else” jest tłumaczone na „altrimenti”, „in” to „dentro” ... to byłoby frustrujące.