なぜもっと多自然言語のプログラミング言語がないのですか?


9

複数の自然言語で利用可能で拡張可能なプログラミング言語はありますか?

たとえば、英語バージョンのdo..whileループ、スペイン語バージョンのhacer..mientasループ、フランス語バージョンのa faire..pendant、オランダ語バージョンのdoe..terwijl

この種の実装について考えることができる唯一の「プログラミング言語」は、Microsoft VBAです。

おまけの質問:なぜ複数の言語で提供されるプログラミング言語が少ないのですか?


12
英語は、良くも悪くも、ほとんどのプログラミング言語のLingua Francaです。
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"-Javaインドネシア語プログラムは、インドネシア語のプログラマーだけが保守できるためです。
Robert Harvey、

5
@DavidArnoこのトピックは、英語圏以外の国の人々が英語でコーディングしていますか?それにリンクされた複数の質問
gnat

8
@MartijnBurgerがキーワードを翻訳することは、「巨大なタスク」である標準ライブラリを翻訳することと比較して、「小さな問題」です。そして、それが相互運用性の問題の原因にもなります。Javaは、コンパイルされたキーワードのスペルに依存しません。ただし、パッケージ、クラス、およびメソッド名のスペルに依存します。
Dan Getz

3
@DanGetz Java(およびおそらく他の言語)では、キーワードが予約されているという問題がまだあります。String for;クラスのエクスポートされたシンボルになるため、Javaのようにフィールドを定義することはできません。そして、それは私がフィールドに名前を付けることができなかったdoeことです。それはオランダ語バージョンでありpublic class Deer { String buck; String doe; }doeフィールドにアクセスできないためです。すべてのキーワードはJavaの予約語です。他の言語のキーワードと競合するフィールドに悪いことが起こります。

回答:


21

Excelの数式の関数名はローカライズされており、英語の表現またはローカルの同等の表現を使用できます。

これにより、地域やユーザー言語間を移動するときに、スプレッドシートが無数に破損する原因となりました。また、ローカルのドキュメントはローカライズされており、物事の英語名が記載されていないため、機能に関する情報の検索が難しくなります。逆に、ローカル名でSOを要求しても、ほとんどの読者にとって本質的に無意味です。

キーワードは不透明なモニカと見なされるべきであり、それはたまたま、それらを綴るのに使用される英語の単語の意味と一致するようなものです。キーワードの半分の意味がわからない、英語を話さないプログラマーがたくさんいます。


5
この答えが「Excel」という単語が表示される唯一の場所であり、翻訳された数式の壮大な失敗と考えられていることは驚くべきことです。どちらの引数も有効で非常に強力です。スプレッドシートは壊れ、ローカライズ版はコミュニティを断片化します。これには、ドキュメントとプログラム(コンパイラ)自体を翻訳するベンダーの努力は含まれていません。

1
スクリプトでキーワードを翻訳するのが難しいのはなぜですか?確かに、それらはすでに特別に扱われているので、比較的解析しやすいはずです。
SuperBiasedMan 2016

また、Excelは英語の文の構造を実行可能プログラムに変換しないため、実際には自然言語プログラミングシステムではありません。
アンダーソングリーン

16

前世紀、特に1960〜1970年代には、英語以外のプログラミング言語になりました。フランスでは、フランス風のキーワードを備えたPAFLSEがありました。WW2ドイツはK.ZuzeによるPlankalküllを持っていました。ソビエト連邦では、A.Ershovがロシア語のキーワードを使用していくつかの言語(例:Rapira)を設計しました。IIRC PAF(私が赤ん坊の頃に亡くなった父親が1960年代初頭に設計および実装したもの)は、英語(またはロシア風またはドイツ風)のキーワードで販売することもできます。また、APLなどの一部の言語には、キーワードがまったくありませんでした。他の言語(PL / I)は予約されていませんキーワード。そして、あなたは(例えば、今日、Cには、プリプロセッサの技術とキーワードを再定義することができ#define si if#define sinon else....フランスの学生のために、同様のマクロベースのトリックは、PL / I、あるいはCommon Lispの中で可能です)。

しかし、IT主に英語圏の国(米国)で開発されました。そのため、プログラミング言語とその実装には、英語の仕様とドキュメント、および英語のキーワードがありました。したがって、すべての開発者は技術的な英語を読める必要があり、プログラミング言語を「ローカライズ」することに付加価値はありません(他の場所で回答されているように、そうすることで他のソフトウェアの使用が難しくなります)。英語圏の国の現在の技術的および経済的優位性により、すべてのエンジニアが今日英語を読む必要があります(北朝鮮、中国語、またはイランのソフトウェアエンジニアでも、英語でドキュメントを読んだり、英語のキーワードと識別子でコードを読んだりできるはずです) 。したがって、プログラミング言語を「ローカライズ」するのに十分な付加価値はありません(おそらく、高校の子供たちに初等プログラミングを教えることを除いて)。

また、英語には多くの短いキーワードがあり(sinonフランス語からelse英語、またはmettreフランス語から英語で比較put)、英語でキーワードを使用することには小さな利点があります...

おそらく1世紀になると、中国がITの主要国になり、一部の中国語ベースのプログラミング言語が繁栄する可能性があります。その時何が起こるかわかりません。

PS。英語の優位性はITに固有のものではありません。英国がEUを離脱した場合でも(Brexitシナリオ)、事実上の公式のEC言語は英語のままで(EU加盟国の言語ではなくなります)、H2020 ICTプロジェクトは英語で記述されます。



ありがとう。ホモフォニックなフランス語のプラン
Calcul

わかりませんが、賛成したので、(alasのみ)ニュートラルになりました。良い答えだと思いました。
Mawgはモニカを2016

5
英語は、EU加盟国であるアイルランド共和国の2つの公用語の1つです。
マシューフリン

9

プロのプログラミング言語が翻訳されていないのには非常に理由があります。

1)労力:現代の言語を翻訳するのは大変な仕事です。Javaを例にとると、50個程度のキーワードを翻訳するのは簡単な作業ですが、何千ものクラスとメソッド、および関連ドキュメントで構成される完全な標準ライブラリも翻訳する必要があります。

2)互換性:基本言語と標準ライブラリが翻訳されていても、翻訳されていないサードパーティのライブラリとコードを使用することはできません。サードパーティのライブラリとコードは、言語を魅力的で有用なものにする主要な部分です。翻訳されたバージョンでは、各言語は各翻訳のエコシステムをゼロから開始する必要があります。誰もが悪くなるでしょう。

3)プログラマーはとにかく英語を知る必要があります。HTTP、CSS、HTMLなどの標準の多くは、とにかく識別子に英語を使用しています。単語が標準に組み込まれているため、これらは翻訳できません。

プログラマーはとにかく英語を知る必要があるので、プログラミング言語の翻訳バージョンを作成することには欠点と利点はありません。

とはいえ、プロのプログラマーではなくカジュアルなプログラマー向けの言語の場合、翻訳バージョンを作成することは理にかなっています。これはVBAの場合であり、AppleScriptは翻訳されたバージョンにも存在すると思います。


5

私は他の言語を知りませんが、BASICの非常に古い難解なバージョンを除いて、多くの奇妙な支持が得られる傾向があったため、ボーナスの質問に固執します。なぜ翻訳されたプログラミング言語が少ないのですか。

これは、コンパイラとライブラリの実装者が大きな必要性を感じていない複雑さを追加しただけだと思います。私の意見に貢献するいくつかの理由はここにあります。

  • 「ユニバーサル」言語にこだわらない場合は、コードの対象者を制限します。もちろん、誰もが英語を知っているわけではありませんが、同じことがすべての言語に当てはまります。
  • 単一の単語のキーワードは、必ずしもすべての言語で単一の単語であるとは限らないため、解析が複雑になります。チェックしたことはありませんが、C ++の単一のマルチワード型「long long」を処理するために、かなりの量の特別なケースがあると想像できます。
  • キーワードの翻訳を開始する場合は、ロケールと、数値の形式についても検討しますか?たとえば、小数点記号としてのカンマとピリオド。または、ドイツ語の名詞を大文字にすることを要求しますか?
  • 特定のプログラムのテキストの大部分は、コメントは言うまでもなく、変数、メソッド、クラス名です。他の言語で書かれたライブラリは確かにありますが、すべてのユーザーにサービスを提供するためにすべてのライブラリのソースコード変換を維持する必要があることは、ほとんどの開発者にとって大きな負担となります。
  • コンパイラは、実装されているすべての言語を理解する必要があります。おそらく、同じファイル内の複数の言語です。確かにコンピュータにとっては小さな偉業ですが、それでも余分な作業は必要です。おそらく、同じキーワードを別の言語で異なる意味で処理したり、用語が曖昧すぎて上手に読めなくなったりする可能性があります。
  • (わかりました、別の意見です)異なる言語でプログラムおよびフォーマットされたMS Officeドキュメントを処理しなければならなかったほとんどの人は、問題を解決する価値がないとして、その考えを却下します。

個人的には、より構造化された方法でコードを操作できたら、コードを実際に理解しているエディター、ステートメント、指示など、多くの興味深いことを実行できるようになれば、それが大好きです、おそらく自動翻訳もサポートしています。私が何を非難しているのかと思っている人は、Smalltalkの画像とリファクタリングブラウザーをチェックして、より多くの牽引力を得た場合にどうなるか想像してみてください。


3

あるレベルで「シンボリックタグ」という用語で定義され、もう1つのレベルで「表面タグ指定子」と定義された言語があり、それらの間のマッピングが明確に定義されている場合は、確かに可能です。

ifwhile... doswitchおよびその他のすべてのキーワードが標準で(どういうわけか)定義されている言語を想像してみてください。ローカルコードが非トークン化形式で記述された「トークン化形式」でシステムライブラリを出荷できます。次に、実際のコンパイラーはトークン化されたレイヤーで機能し、状況は良好です。

ただし、これだけではありません。関数名でインターフェイスされた「標準ライブラリ」ではない場所からライブラリを取得した場合でも、最終的にはそうなります。そして、それらは言語間の標準的なマッピングを持たず、ローカル言語への翻訳を適切に使用できるようにする必要があるか、ソースコードに言語の寄せ集めが生じます。


2

与えられたすべての答えは素晴らしい答えですが、とにかく私の2セントをあげます。

米国と英国の技術的、文化的、経済的優位性を計算する最初の段階では、最も成功した言語が英語の単語を使用して作成されたものだけが論理的でした。

その後、ソフトウェアが業界になると、それは世界的な取り組みにもなりました。プログラマーの数が必要な数よりも少ないことは秘密ではありません。そのため、ソフトウェア会社、特にIBMのような業界を定義する会社は、世界中のすべての地域(ロシア、パキスタン、インド、フランス、ドイツ、イスラエルなど)からプログラマーを採用し始めました。主に、すでに英語ベースで、新しい言語を作成する、既存の世界的に成功した言語でプログラミングすることです。そのプログラマーの異なるソースにとって、既存の共通言語は他のどの言語よりも優れています。

ごく最近では、オープンソースとフリーソフトウェアの運動により、ソフトウェアの作成が以前よりもさらにグローバルな取り組みになりました。いくつかのプログラミングプラットフォーム、言語、フレームワークを含むいくつかのオープンソフトウェアプロジェクトは、何百人もの協力者が関与する巨大なプロジェクトです。

イスラエルの人はスリランカの人と協力するためにどの言語を使用しますか?ほとんどの場合、彼らはお互いの母国語を話したり読んだりしません。したがって、英語が助けになります。

好むと好まざるとにかかわらず、英語はグローバルな取り組みの言語です。アメリカがそれを押しているからではなく、世界がそれを引っ張っているからです。

ジェイウォーカーの言い換え:

あなたの母国語はあなたが毎日最も頻繁に使用するものであり、常にあなたの心と脳の中心にありますが、英語ではあなたはより広い会話の一部です。

ビデオ「English Mania」をご覧ください

結論:

さまざまな言語を使用するプログラミング言語は引き続き存在し、今後も発明され続けます(グラフィカルトークンベースのスクラッチのように)が、少なくとも予見可能な将来においては、比較的少数です。


-2

英語も「アクセントなし」の言語であり、ASCIIとは異なるエンコーディングを必要とする奇妙な文字はありません。私はイタリア人です。イタリア語のキーボードレイアウトやàèéìòùなどのアクセント付き文字を使用すると、エンコーディングエラーが発生することがあります。さらに、「else」は「altrimenti」に翻訳され、「in」は「dentro」です...イライラするでしょう。


9
ただし、これは循環的な推論です。英語がコンピューティングの共通語であるため、ASCIIが標準の文字セットになりました。
JacquesB 2016
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.