Warum gibt es nicht mehr Programmiersprachen in mehreren natürlichen Sprachen?

9

Gibt es Programmiersprachen, die in mehr als einer natürlichen Sprache verfügbar und erweiterbar sind?

Zum Beispiel eine englische Version mit einer do..whileSchleife, eine spanische Version mit einer hacer..mientasSchleife, eine französische Version mit einer faire..pendantund eine niederländische Version mit einer doe..terwijl.

Die einzige Programmiersprache, die ich mir vorstellen kann, ist Microsoft VBA.

Bonusfrage: Warum gibt es so wenige Programmiersprachen, die in mehreren Sprachen verfügbar sind?

Martijn Burger
quelle
12
Englisch ist die Lingua Franca der meisten Programmiersprachen, egal ob gut oder schlecht.
Robert Harvey
13
That's a reason why the languages are in English, not why there are no other languages, for example no "Java Indonesian" or "C++ Swahili"- Weil Ihr Java Indonesian-Programm nur von indonesischen Programmierern gewartet werden kann.
Robert Harvey
5
@DavidArno Dieses Thema wurde zu Tode geprügelt. Codieren Menschen in nicht englischsprachigen Ländern auf Englisch? und mehrere damit verbundene Fragen
Mücke
8
@MartijnBurger Die Übersetzung der Schlüsselwörter ist das "kleine Problem" im Vergleich zur Übersetzung der Standardbibliothek , die die "enorme Aufgabe" darstellt. Und das würde auch Interoperabilitätsprobleme verursachen. Java hängt nicht von der Schreibweise der einmal kompilierten Schlüsselwörter ab. Dies hängt jedoch von der Schreibweise der Paket-, Klassen- und Methodennamen ab.
Dan Getz
3
@DanGetz Es gibt immer noch das Problem in Java (und wahrscheinlich in anderen Sprachen), dass Schlüsselwörter reserviert sind. Ich kann ein Feld nicht wie String for;in Java definieren , da dies ein exportiertes Symbol in der Klasse wäre. Und das würde bedeuten, dass ich auch kein Feld benennen könnte, doeweil das in der niederländischen Version ist und public class Deer { String buck; String doe; }das doeFeld nicht zugänglich wäre. Alle Schlüsselwörter sind in Java reservierte Wörter. In den Feldern, die mit Schlüsselwörtern in anderen langs in Konflikt stehen, würden schlimme Dinge passieren.

Antworten:

21

Die Funktionsnamen in Excel-Formeln sind lokalisiert, wobei Sie entweder den englischen Wortlaut oder das lokale Äquivalent verwenden können.

Dies hat dazu geführt, dass unzählige Tabellenkalkulationen beim Übergang zwischen Regionen und Benutzersprachen beschädigt wurden. Es macht es auch schwierig, nach Informationen über die Funktionalität zu suchen, da die lokale Dokumentation lokalisiert ist und die englischen Namen der Dinge nicht erwähnt. Umgekehrt ist es für die meisten Leser im Wesentlichen bedeutungslos, SO mit Ihren lokalen Namen zu fragen.

Schlüsselwörter sollten als undurchsichtige Moniker angesehen werden, die zufällig mit der Bedeutung der englischen Wörter übereinstimmen, mit denen sie geschrieben wurden. Es gibt viele nicht englischsprachige Programmierer, die nicht wissen, was die Hälfte ihrer Keywords bedeutet.

Lars Viklund
quelle
5
Es ist überraschend, dass diese Antwort der einzige Ort ist, an dem das Wort "Excel" erscheint, was als das epische Versagen übersetzter Formeln angesehen wird. Beide Argumente sind gültig und sehr stark: Tabellenkalkulationen werden unterbrochen , und lokalisierte Versionen fragmentieren die Communitys. Dies beinhaltet nicht die Bemühungen des Anbieters, die Dokumente und Programme (Compiler) selbst zu übersetzen.
1
Warum ist es so schwierig, Schlüsselwörter in ein Skript zu übersetzen? Sicherlich sollten sie relativ einfach zu analysieren sein, da sie bereits speziell behandelt wurden.
SuperBiasedMan
Außerdem ist Excel kein Programmiersystem in natürlicher Sprache , da es keine englischen Satzstrukturen in ausführbare Programme übersetzt.
Anderson Green
16

Im vorigen Jahrhundert, insbesondere in den 1960er und 1970er Jahren, waren dies einige nicht auf Englisch basierende Programmiersprachen. In Frankreich hatten wir PAF & LSE mit französisch aussehenden Schlüsselwörtern. WW2 Deutschland hatte Plankalküll von K.Zuze. In der Sowjetunion entwarf A.Ershov einige Sprachen (z. B. Rapira ) mit russischen Schlüsselwörtern. IIRC PAF (entworfen und implementiert von meinem verstorbenen Vater, als ich ein Baby war - Anfang der 1960er Jahre) konnte auch mit englisch (oder russisch oder deutsch) aussehenden Schlüsselwörtern verkauft werden. Und einige Sprachen, z. B. APL , hatten überhaupt keine Schlüsselwörter. Andere Sprachen ( PL / I ) hatten nicht reserviertSchlüsselwörter. Und man kann Schlüsselwörter mit Präprozessor Techniken neu zu definieren (zB heute, in C #define si if& #define sinon elsefür Französisch Studenten ....; ähnlich Makro -basierte Tricks sind möglich in PL / I oder sogar Common Lisp).

Aber ITwurde hauptsächlich in einem englischsprachigen Land (den USA) entwickelt. Programmiersprachen und ihre Implementierungen hatten also englische Spezifikation und Dokumentation sowie englische Schlüsselwörter. Daher muss jeder Entwickler in der Lage sein, technisches Englisch zu lesen, und es gibt keinen Mehrwert, die Programmiersprache zu "lokalisieren" (und dies erschwert sogar die Verwendung anderer Software, wie an anderer Stelle beantwortet). Die derzeitige technische und wirtschaftliche Dominanz der englischsprachigen Länder erfordert, dass alle Ingenieure heute Englisch lesen (ich bin sicher, dass auch nordkoreanische, chinesische oder iranische Softwareingenieure die Dokumentation auf Englisch lesen und Code mit englischen Schlüsselwörtern und Bezeichnern lesen können). . Es gibt also nicht mehr genug Mehrwert, um eine Programmiersprache zu "lokalisieren" (außer vielleicht, um Highschool-Kindern elementares Programmieren beizubringen).

Englisch hat auch viele kurze Schlüsselwörter (vergleiche sinonauf Französisch mit elseEnglisch oder mettreauf Französisch mit putEnglisch), so dass es einen winzigen Vorteil bei der Verwendung von Schlüsselwörtern auf Englisch gibt ....

Vielleicht könnte China in einem Jahrhundert das dominierende IT-Land werden und eine auf Chinesisch basierende Programmiersprache könnte florieren. Wir wissen nicht, was dann passieren würde ...

PS. Die Dominanz des Englischen ist nicht spezifisch für die IT. Selbst wenn das Vereinigte Königreich die Europäische Union verlässt - das Brexit- Szenario -, bleibt die de facto offizielle EG-Sprache Englisch (was dann nicht die Sprache eines EU-Mitgliedslandes ist), und H2020- IKT-Projekte werden in Englisch verfasst.

Basile Starynkevitch
quelle
Plankalküll nicht vergessen !
Erik Eidt
Vielen Dank. Nicht zu verwechseln mit dem homophonen französischen Plan Calcul
Basile Starynkevitch
Ich weiß es nicht, aber ich habe es positiv bewertet, daher ist es jetzt (leider nur) neutral. Ich fand es eine gute Antwort.
Mawg sagt, Monica
5
Englisch ist eine der beiden Amtssprachen der Republik Irland, die EU-Mitglied ist.
Matthew Flynn
9

Es gibt sehr gute Gründe, warum professionelle Programmiersprachen nicht übersetzt werden.

1) Aufwand: Es wäre eine enorme Aufgabe, eine moderne Sprache zu übersetzen. Nehmen Sie Java - es wäre eine kleine Aufgabe, die etwa 50 Schlüsselwörter zu übersetzen, aber Sie müssten auch die vollständige Standardbibliothek übersetzen, die aus Tausenden von Klassen und Methoden sowie der zugehörigen Dokumentation besteht.

2) Kompatibilität: Selbst wenn die Basissprache und die Standardbibliothek übersetzt wurden, konnten Sie keine Bibliotheken und Code von Drittanbietern verwenden, die nicht übersetzt wurden. Bibliotheken und Code von Drittanbietern sind ein wesentlicher Bestandteil dessen, was eine Sprache attraktiv und nützlich macht. Bei übersetzten Versionen müsste jede Sprache das Ökosystem für jede Übersetzung von Grund auf neu starten. Allen würde es schlechter gehen.

3) Programmierer müssen sowieso Englisch können. Viele Standards wie HTTP, CSS, HTML verwenden ohnehin die englische Sprache für Bezeichner. Diese können nicht übersetzt werden, da die Wörter in den Standard eingebrannt sind.

Da Programmierer ohnehin Englisch sprechen müssen, gibt es nur Nachteile und keine Vorteile beim Erstellen übersetzter Versionen von Programmiersprachen.

Für Sprachen, die für Gelegenheitsprogrammierer im Gegensatz zu professionellen Programmierern gedacht sind, kann es jedoch sinnvoll sein, übersetzte Versionen zu erstellen. Dies ist bei VBA der Fall und ich glaube, AppleScript gab es auch in übersetzten Versionen.

JacquesB
quelle
5

Ich kenne keine anderen Sprachen außer möglicherweise einer wirklich alten esoterischen Version von BASIC, die mit vielen seltsamen Gefälligkeiten verbunden war. Deshalb bleibe ich bei der Bonusfrage: Warum gibt es so wenige übersetzte Programmiersprachen:

Ich glaube, dass es einfach eine zusätzliche Komplexität ist, für die Compiler- und Bibliotheksimplementierer keinen großen Bedarf sehen. Hier sind einige Gründe, die meiner Meinung nach dazu beitragen.

  • Sie werden die Zielgruppe Ihres Codes einschränken, wenn Sie sich nicht an eine "universelle" Sprache halten. Sicher, nicht jeder kann Englisch, aber das gilt für jede Sprache.
  • Einzelwort-Schlüsselwörter sind nicht unbedingt Einzelwörter in allen Sprachen, was das Parsen erschwert. Ich habe noch nie nachgesehen, aber ich kann mir vorstellen, dass es eine ganze Menge spezieller Gehäuse gibt, um mit dem langen Mehrworttyp "long long" von c ++ fertig zu werden.
  • Wenn Sie mit der Übersetzung von Schlüsselwörtern beginnen, werden Sie auch Gebietsschemas berücksichtigen und wie Zahlen formatiert werden? Komma versus Punkt zum Beispiel als Dezimaltrennzeichen. Oder müssen deutsche Substantive groß geschrieben werden?
  • Die überwiegende Mehrheit des Textes in einem bestimmten Programm besteht aus Variablen, Methoden und Klassennamen, ganz zu schweigen von Kommentaren. Zwar gibt es Bibliotheken, die in anderen Sprachen geschrieben sind, aber die Pflege von Quellcode-Übersetzungen aller Bibliotheken, um alle Benutzer zu bedienen, wäre für die meisten Entwickler eine große Belastung, ganz zu schweigen von der zusätzlichen Komplexität der Diskussionen um solchen Code.
  • Compiler müssten alle implementierten Sprachen verstehen. Vielleicht sogar mehrere Sprachen in derselben Datei. Eine kleine Leistung für einen Computer, aber trotzdem zusätzliche Arbeit. Vielleicht müssen Sie sich mit demselben Schlüsselwort befassen, das verschiedene Dinge in verschiedenen Sprachen bedeutet, oder Begriffe, die einfach zu vieldeutig sind, um gut gelesen zu werden.
  • (ok, meinungsbildend) Sicherlich werden die meisten Leute, die sich mit MS Office-Dokumenten befassen mussten, die in verschiedenen Sprachen programmiert und formatiert wurden, die Idee als nicht die Mühe wert abtun.

Persönlich würde ich es lieben, wenn wir strukturierter mit Code arbeiten könnten, in einem Editor, der den Code tatsächlich so versteht, wie er ist, Anweisungen, Anweisungen usw., die es uns ermöglichen würden, viele interessante Dinge zu tun , vielleicht sogar automatische Übersetzung unterstützen. Wenn Sie sich fragen, worüber ich plappere, schauen Sie sich das Bild und den Refactoring-Browser von Smalltalk an und stellen Sie sich vor, was daraus werden könnte, wenn es mehr Traktion bekommen hätte.

axl
quelle
3

Wenn Sie eine Sprache haben, die auf einer Ebene als "symbolische Tags" und auf der anderen als "Oberflächen-Tag-Bezeichner" mit genau definierten Zuordnungen zwischen ihnen definiert ist, ist dies sicherlich möglich.

Stellen Sie sich eine Sprache , wo Sie Ihre if, while... do, switchund alle anderen Schlüsselwörter definiert (irgendwie) im Standard, können Sie Systembibliotheken in „Zeichen übersetzten Format“ Schiff, mit lokalen Code geschrieben in der nicht-Zeichen übersetzten Form. Dann arbeitet der eigentliche Compiler auf der Token-Ebene und möglicherweise sind die Dinge gut.

Dies ist jedoch nicht die ganze Geschichte. Sie würden immer noch in Situationen geraten, in denen Bibliotheken von einem Ort stammen, der nicht "die Standardbibliothek" ist und mit Funktionsnamen verbunden ist. Und diese hätten keine kanonische Zuordnung zwischen Sprachen und würden entweder eine Übersetzung in eine lokale Sprache erfordern, um gut verwendbar zu sein, oder Sie hätten eine Mischung aus Sprachen in Ihrem Quellcode.

Vatine
quelle
2

Alle Antworten sind großartige Antworten, aber ich werde trotzdem meine zwei Cent geben.

Zu Beginn der Berechnung machte es die technische, kulturelle und wirtschaftliche Dominanz der USA und Großbritanniens nur logisch, welche der erfolgreichsten Sprachen mit englischen Wörtern erstellt wurden.

Später, als Software zu einer Industrie wurde , wurde sie auch zu einem globalen Unterfangen. Es ist kein Geheimnis, dass es weniger Programmierer als nötig gibt. Daher begannen Softwareunternehmen und speziell branchenbestimmende Unternehmen wie IBM, Programmierer aus allen Teilen der Welt einzustellen: Russland, Pakistan, Indien, Frankreich, Deutschland, Israel usw. Hauptsächlich, um in bereits existierenden, weltweit erfolgreichen Sprachen zu programmieren, die bereits auf Englisch basieren und auch neue Sprachen schaffen, und für diese ungleiche Quelle von Programmierern war die bereits existierende gemeinsame Sprache besser geeignet als jede andere Sprache.

In jüngster Zeit machte die Bewegung für Open Source und freie Software die Entwicklung von Software zu einem noch globaleren Unterfangen als zuvor. Einige offene Softwareprojekte, einschließlich einiger Programmierplattformen, Sprachen und Frameworks, sind große Projekte, an denen Hunderte von Mitarbeitern beteiligt sind.

Welche Sprache würde eine Person aus Israel verwenden, um mit einer Person aus Sri Lanka zusammenzuarbeiten? Höchstwahrscheinlich sprechen oder lesen sie nicht einmal die Muttersprache des anderen. Englisch kommt also zur Rettung.

Ob es Ihnen gefällt oder nicht, Englisch ist die Sprache globaler Bemühungen . Und nicht weil Amerika es vorantreibt, sondern weil die Welt es vorantreibt.

Jay Walker umschreiben :

Ihre Muttersprache ist diejenige, die Sie jeden Tag am häufigsten verwenden und die immer im Mittelpunkt Ihres Herzens und Ihres Gehirns steht. Mit Englisch sind Sie jedoch Teil eines umfassenderen Gesprächs.

Siehe Video "English Mania" .

Endeffekt:

Programmiersprachen, die unterschiedliche Sprachen verwenden, werden weiterhin existieren und weiterhin erfunden werden (wie Scratch auf der Basis von grafischen Token), aber zumindest in absehbarer Zukunft werden es vergleichsweise wenige sein.

Tulains Córdova
quelle
-2

Englisch ist auch eine "akzentfreie" Sprache. Außerdem haben Sie kein seltsames Zeichen, das eine andere Codierung als ASCII benötigt. Ich bin Italiener und manchmal treten Codierungsfehler auf, wenn ich ein italienisches Tastaturlayout oder Zeichen mit Akzent wie àèéìòù verwende. Außerdem wird "else" in "altrimenti" übersetzt, "in" ist "dentro" ... das wäre frustrierend.

JoulinRouge
quelle
9
Dies ist jedoch eine Zirkelschlussfolgerung - ASCII wurde zum Standardzeichensatz, da Englisch die Verkehrssprache des Rechnens ist.
JacquesB