プログラミング言語は自然言語に似てきていますか?


27

言語学の文脈でプログラミング言語を勉強できますか?プログラミング言語は自然言語と同様の方法で自然に進化しますか?

プログラミング言語には完全な合理性と数学的な一貫性が不可欠ですが、人間にとって読みやすく快適なものにする必要があります(特に現代の言語)。

プログラミング言語は進化し、より言語的になり、より自然になりましたか?たとえば、マシンコード、パンチカード、およびアセンブリ言語は、RubyやPythonなどのより読みやすい言語に取って代わりました。

コンピューター言語がより自然になっていると言うとき、「英語で持っている単語」がより多く含まれているわけではなく、文法の複雑さと意味を表現する能力の点で、自然言語のようになっているようです(たとえば、合理的かつ人間が理解できる方法でデータベースからのクエリを雄弁に説明できること)。

皆さんはどう思いますか?プログラミング言語は自然言語のようになり、言語学の法則に適用できるようになりましたか?

あるいは、言語はスペクトル上に存在し、一方には極端に合理的な言語があり、他方には創造性があります。たぶん、プログラミング言語と自然言語は同一であり、両方ともこの言語の範囲内にあるだけです(その唯一の違いは、おそらく彼らが意味を与えようとしている「もの」であることです)。

人間の言語とコンピューター言語の分離(バベルタワー効果)の間に関係はありますか?同じ理由(すなわち、進化し続けるコンピューターシステム/文化システムなどのさまざまな問題を解決するため)で、それらはより多様になりますか?


3
短い答え:はい、はい。

17
簡単な答え:いいえ、ありません。


3
コンピューター言語は、数年前から自然言語(私が知っている)に向かって進化する特定の傾向を示していない数学的な表記法に似た簡潔さと精度でうまくいく傾向があります。また、生涯の最初の数年間、Haskellだけで乳児とコミュニケーションを取った場合、自然な言語の流encyさを伸ばすとは思いません。ですから、自然言語とコンピューター言語の間にはかなり鋭いコントラストがあると思います。おそらく、言語構築技術のより広範な普及により、「自然さ」が時間の経過とともにわずかに改善されたと思われます。

@ryanOptini:C#、JavaScript、Python、またはSQLは自然言語のように見えますか?それらはすべて英語のキーワードを使用していますが、自然言語形式に収束しているものはありません。COBOLが最も近いかもしれませんが、多くの人々がCOBOLをグリーンフィールドプロジェクトに使用しているとは思いません。
ジムG.

回答:


32

そうでもない プログラミング言語は、「私たちが英語で持っている単語」(sic)の意味でのみ自然言語に似てきました。

プログラミング言語の重要な特徴は、あいまいでないことです。プログラムを作成して実行すると、その動作は明確に定義された意味を持ちます。意図したとおりに動作するプログラム(難しい目標)を作成する場合、プログラムの動作¹を可能な限り予測可能にすることが重要です。プログラミング言語は、自然言語との大きな隔たりにおいて大きな違いはありません。

逆に、プログラミング言語と同じツールを使用して自然言語を分析する、反対側からのギャップを埋める作業が行われています。この分野は自然言語処理と呼ばれます。これらのアプローチは機械学習を支持してほとんど捨てられました。ここで直接関連するウィキペディアの記事の一節を引用します:

1980年代まで、ほとんどのNLPシステムは手書きのルールの複雑なセットに基づいていました。しかし、1980年代後半から、言語処理用の機械学習アルゴリズムの導入によりNLPに革命が起こりました。これは、ムーアの法則に起因する計算能力の着実な増加と、チョムスキーの言語理論(変換文法など)の優位性の漸進的な低下の両方が原因でした。言語処理。

プログラミングが進化する1つの方法は、ますます大規模なシステムを設計するときに、ソースコードが必ずしもそれらを理解するための良い方法ではないということです。たとえば、Intel CPUはManが設計した最も複雑なオブジェクトの1つであり、その「ソースコード」は単なるテキストファイルのコレクションではなく、それだけではありません。しかし、完全なデザインは、人間の言語に似たものにも進化していません。ここで適切な認知ツールや隠phorが何であるかはわかりません。まだ誰も知らないと思います。数世紀後に再び尋ねてください。

¹ むしろ、起こり得る状況の注釈が付けられた一連の可能な動作ですが、それはモデリングの間接的なステップを1つ追加するだけであるため、ここでは実際には関係ありません。


プログラミング言語に似た「自然な」言語を作成する試みは、あまり成功していないことは注目に値します。最も開発された例としてロジバンを参照してください。
ドゥーガル

CPUアーキテクチャとプログラミングの比較はやや不誠実であり、ハードウェア設計は常に2D配置とルーティングの問題を解決するために完全に異なる問題があるため、ほとんどテキストベースではありません。(ハードウェア設計が何かあれば、HDLを使用したテキストベースの設計に移行しています)
jk。

2

コンピューター言語は、数年前から自然言語(私が知っている)に向かって進化する特定の傾向を示していない数学的な表記法に似た簡潔さと精度でうまくいく傾向があります。

また、生涯の最初の数年間、Haskellだけで乳児とコミュニケーションを取った場合、自然な言語の流encyさを伸ばすとは思いません。ですから、自然言語とコンピューター言語の間にはかなり鋭いコントラストがあると思います。

おそらく、言語構築技術のより広範な普及により、時間の経過とともに「自然さ」がわずかに改善されたと思われます。実践者と優れたツールがありますが、これはエッジの周りの小さな効果であり、プログラミング言語から人間の言語への根本的な変換を表すものではありません。


2

この分野の興味深いケーススタディは、Perl vs Ruby(およびPython)です。Perlは90年代前半に開発されたスクリプト言語で、以前のUnixベースのスクリプト言語(bashなど)と比較して多くの機能を追加しました。著者のラリーウォールは、言語学のバックグラウンドがいくつかの言語機能に影響を与えたと記録している。

しかしPerlには扱いにくい構文とさまざまなレベルの批判を引き起こすその微妙な特異性で言語を英語のようにする多くの特別なケースがあります。コンピューター科学者によって開発されたRubyやPythonのような後のスクリプト言語では、構文の一貫性がはるかに高くなっています。主な問題は、自然言語には多くの曖昧性があることです(これは言語学の分野で研究されています)。したがって、自然言語はSiriのような将来の人間とコンピューターのインターフェースで重要な位置を占めますが、これらのインターフェースは本質的に曖昧性の問題にさらされます。

そのため、ここでは、コンピューター言語の進化が自然言語のアイデアから遠ざかった場合です。さらに、コンピュータープログラミング言語の一般的な歴史は曖昧さ(自然言語に非常に固有のもの)を除去するために開発および変更されたということです。これは、コンパイラーの歴史の早い段階(おそらく1970年代など)で理解されていませんでした。たとえば、Fortran言語の初期バージョンには、コンパイラーの実装に依存する曖昧な意味のステートメントがありました。構文解析に関連するCS言語理論の一部は、言語構文解析のあいまいさの発見に部分的に応じて開発されました。


日付が間違っています:Perlは1987年に、Bashは1989年にリリースされました。また、大文字の誤りのために投稿を読むのも面倒です。
tchrist 14

1

機械語は非常に正確ですが、人間が作成したテキストは通常​​、さまざまな方法で解釈できます(たとえば、詩的なテキストなど)。

ますます進化しているのはパターンマッチングです。たとえば、codeいコードを作成する場合、コンパイラはいくつかの可能な解決策を提案し、警告またはエラーをスローして自分自身を説明するのに役立ちます。(たとえば、一般的なコードパターンに基づく)

インタラクション/デザインパターンに関する特定の研究があります。T9とSWYPEでさえ、あなたを大いに助けてくれるパターン認識機能です(音声を録音してテキストに変換するプログラムもパターン認識機能です)。

もちろん、プログラムは正確なメカニズムに依存するものなので、正確な言語(自然ではない)が必要です。一方、Googleでの単純なWeb検索は非常に自然ですが、いくつかの単語を入力するだけで必要なものが得られます。

さまざまなタスクと目標にはそれぞれ独自の言語があり、それは単なる「単一言語の進化」ではなく、はるかに多くの言語があります。正確なタスクには正確な言語が必要であり、リラックスしたタスクにはリラックスした言語が必要です

同じCコードを記述してから、いくつかの異なるコンパイラーでコンパイルすることができます(一部のコンパイラーにバグがない限り)、異なるアセンブリーが生成されてもコードの結果は同じになりますが、Web検索の場合は同じです異なる検索エンジンへのキーワードは、異なる結果をもたらします。


1

数年前、長男と私は、次の質問に答えるために、平易な英語のプログラミングおよび開発システムを開発しました。

  1. 低レベルプログラム(コンパイラなど)を高レベル言語(英語など)で便利かつ効率的に記述できますか?

  2. 自然言語は比較的「だらしない」方法で解析でき、それでも生産的なプログラミングに十分な安定した環境を提供できますか?

  3. 自然言語の考えを別の構文に変換する必要がない場合、プログラミングは簡単ですか?

直接の経験から、これらの3つの質問のそれぞれに「はい」と答えることができます。

私たちのパーサーは、人間の脳のように動作します。考えてみてください。父親は彼の赤ん坊の息子に言います:

「この瓶を吸いたいですか?」

そして、子供は聞いた、

「何とか、何とか、吸って、何とか、何とか、ボトルとか、何とか、何とか。」

しかし、彼は適切に反応します。なぜなら、頭の右側にあるボトルの「写真」が左側の「ボトル」という言葉につながり、首の後ろにある既存の「スキル」が首につながっているからです。用語「吸う」。言い換えれば、子供は自分が蓄積した写真(タイプ)やスキル(ルーチン)と自分ができることを一致させ、残りを単純に無視します。私たちのコンパイラは非常に同じことを行い、新しい写真(タイプ)とスキル(ルーチン)が定義されます-私たちではなく、プログラマーが、新しいアプリケーションコードを書くときに定義します。

典型的な型定義は次のようになります。

ポリゴンは、いくつかの頂点を持つものです。

内部的には、名前「ポリゴン」は、二重にリンクされた頂点のリストを含む動的に割り当てられた構造のタイプに関連付けられています。「頂点」は、他の場所(この定義の前後)で同様の方法で定義されます。複数形は自動的に理解されます。

典型的なルーチンは次のようになります。

x座標とy座標をポリゴンに追加するには:xとyを指定して頂点を作成します。頂点をポリゴンの頂点に追加します。

パラメーターと変数には正式名(固有名詞)は必要ないことに注意してください。これは、大きな洞察だと信じています。私の実世界の椅子とテーブルは(通常の会話では)「c」や「myTable」と呼ばれることはありません。単に「椅子」と「テーブル」と呼びます。同様に、「頂点」と「ポリゴン」はそのようなものの自然な名前です。

また、ルーチンおよび変数の「名前」(「x coord」など)にはスペースを使用できることに注意してください。これは21世紀ですよね?また、「ニックネーム」も許可されます(「x coord」の「x」など)。そして、その所有物(「ポリゴンの頂点」)は、「レコード」内の「フィールド」を参照するために非常に自然な方法で使用されます。

同様に、「与えられた」という言葉は、「使用」または「と」または他の同等のものである可能性があることに注意してください。可能な限り、残り。

最低レベルでは、次のようになります。

番号を別の番号に追加するには:Intel $ 8B85080000008B008B9D0C0000000103。

この場合、単一のルーチンに英語とマシンコード(16進数ではありますが)の最高と最低の両方の言語があることに注意してください。ここでの洞察は、(典型的な数学の本のように)プログラムは主に自然言語で書かれるべきであり、必要に応じて(そしてそれだけで)より便利な構文の適切なスニペットが必要です。

開発システムは、www.osmosian.com / cal-3040.zipから入手できます。サイズが1メガバイト未満の小さなWindowsプログラムです。「documentation」ディレクトリのPDFから始める場合、10ページ進む前に、シバン全体を再コンパイルします(Walmartの最下段のマシンで3秒未満で)。

質問とコメントはgerry.rzeppa@pobox.com宛に送ってください。


attempto.ifi.uzh.ch/site/descriptionで制御された英語を知っていますか?あなたはそれとInform7の間に座っているように見えるen.wikipedia.org/wiki/Inform#Example_game_2
ピートKirkham

私はこのアイデアが好きですが、まだいくつかのシンタックスフープがあります。たとえば、私や幾何学的なものをモデリングしている人は、X座標とY座標が別々に追加されるとは思わないと思うので、「x座標とay座標を追加するには...」は本当に奇妙に聞こえます。「xとyを指定して頂点を作成する」も同様です。実際にはほとんど英語のように読めるので、ほとんど許されます、それでも厳しすぎるようです。たぶん、私は人間や何かのように考えないことにあまりにも慣れているのでしょう、私は知らない。
cHao

1

人間の言語の分離は、孤立したコミュニティの(ダーウィン)の進化に由来します。プログラミング言語の分離は、技術的ニーズ、技術的イデオロギーの変化、技術的および理論的理解の変化、実装する技術的能力の変化から生じます。それはやや意識的なプロセスだと思います。

コンピューター言語は、自然言語に似ているでしょうか?おそらくある程度、ある程度まで。自然言語の複雑さの大部分は、新しい矛盾が発生している間に古い矛盾を次第に除去する可能性が高いにもかかわらず、ある時点で一貫した結果を生成する理由のないさまざまな同時進化現象に起因すると推測します。私は通時言語学の専門家ではありません。しかし、プログラミング言語でそのような複雑さが必要ですか。

あいまいさの問題は重要な問題ですが、ほとんどの人が述べているとおりではありません。言語はコミュニケーションの手段であり、そのコミュニケーションのコンテキストで分析する必要があります(マンマン、マンマシン、両方、場所間または時間、...簡単に言えば)。重要なのは、言語で明確なステートメントのみを作成できるかどうかではなく、意図したコンテキストでコミュニケーションが明確になることを常に保証できるかどうかです。よく知られ広く使用されているプログラミング言語が1つあり、あいまいなプログラムを作成できます(まあ、そうはなりましたが、しばらくの間最新バージョンを見ていません)。この場合、コンパイラはあいまいさを検出し、明確化を要求するのに十分なほど賢く、これをプログラムに組み込んであいまいさを排除できます。あいまいさの検出は、可能な選択肢の1つだけが意味を持つことを意味するのではなく、すべてが意味を持つことに注意してください。問題は、通信するエンティティの1つがあいまいさを検出できるかどうかです。これにより、送信者はそれを明確にできます。人間はこれが苦手ですが、コンピューターはかなり良いものです。

フォーマリズムとプログラミング言語は、より豊富で柔軟性のある構文を持つことができます。彼らがしない主な理由は単純な保守主義だと思います。使用される構文ツールは、当時のコンピューターの制限を満たすために、30年以上前に設計されたツールであることが非常に多くあります。解析の効率は、もはやコンパイルにおいてそれほど重要な問題ではなく、より強力な手法が順調に存在します。

興味深いことに、プログラミング言語の構文で最も広く使用されている基礎は、自然言語の研究、つまり文脈自由文法に由来しています。技術研究の多くは、60年代に理論的/技術的コンピューターサイエンスに移行し、80年代前半に自然言語の人々によってある程度再発見されました(簡略化しています)。それ以来、自然言語の構文は大きく進歩しましたが、コンピューターサイエンスは古い構文ツールにほとんど固執しているようです。自然言語の振り子は再び統計的手法に向かっていますが、構文の代数的アプローチは忘れられていません。おそらく、優れたアプローチは代数的手法と統計的手法の組み合わせから生まれます。

私の感覚では、重要な領域はセマンティクスであり、構文とセマンティクス間の移行です。プログラミング言語やフォーマルシステムの場合、多くの正確なテクニックがありますが、これはまだ自然言語のために形式化するのが非常に困難です。このゲームは自然言語でプレイされるにはほど遠いため、将来プログラミング言語にどのような影響を与える可能性があるかを言うのは困難です。

もう1つのポイントは、多くのプログラミング言語デザイナーが何かを証明しようとしている、または技術的イデオロギーを実施しようとしているということです。そのため、ユーザーは意図したパラダイムから逸脱することを防ぐために、非常に規範的な設計になります。残念ながら、これは創造性にとって非常に非生産的です。これまでに設計された最も創造的な言語は、最初のものでした:Lisp(1958)。それが許した自由と柔軟性は、かなりの創造性の源でした。代償は、自己規律と理解が必要だということでした。しかし、Lispは実際にはメタ言語であり、言語を作成するための言語でした。

さて、別の見方をすると、プログラムは実際には数学的記述として見られる仕様の証明です(まあ、もう一度単純化しています)。一部の人々(参照は覚えていませんが、申し訳ありません)は定理証明器を使って、自然言語で数学者によって書かれたように見える証明を作成しています。だから、自然言語で書かれているように見えるプログラムを持つという考えは、まったくばかげているとは思わない。

ただし、数学者によって非公式に書かれた場合でも、数学的談話は通常の話や歴史書とはまったく異なることに気付くかもしれません。これは、話されている意味論領域である談話の関係する宇宙の大きな違いによるものです。したがって、自然言語のように見えるプログラミング言語を思い描くことができますが、談話の領域とそれ自体の望ましい特性である自然の制限があります。ほとんどの場合、それは本質的に表面的なまま、つまり、ほとんど構文的です。数学者は正式なシステムと政治について話すことができます。2つの談話が似ていないことを願っています。コンピューターは(まだ?)政治について話すことも、それを理解することもできません。彼らがそれをする日はもはやプログラミングではありません。

歴史を振り返ると、高レベル言語は最初から(FORTRAN)計算タスクを表現するためにより自然な形に近づく試みでしたが、これらのタスクは数学的または論理的であると理解されていました(Fortran 1957、Algol 1958、Lisp 1958 )、またはよりビジネス指向(Cobol 1959)。10年以内に、人々は近くの言語、手元の問題により良く適応する言語を心配し、extensible languages構文とセマンティクスの両方をカバーする、いわゆるの重要な研究がありました。問題をより自然に表現するための1つの主要な経路は、object orientation(時には他の名前で)出現したことです。親子関係を割り当てることは常に困難ですが、おそらく主にLispでの人工知能の研究と言語から生まれましたSimula 67(Algolファミリー)それ自体は、コンピューター上でシミュレートされる実際の問題をより自然に表現することを目的としていました。それはすべて歴史的に一貫しているようです。


0

質問は似ているという点で似ていますが、複雑さの点ではまったく異なります。主な違いは、自然言語は本質的にあいまいであることです(単語レベルでも)。言葉が何を意味するのかさえ明らかではありませんか?しかし、プログラミング言語の世界では、さまざまな定義デバイスが自由に使用できます。自然言語の構文解析とプログラミング言語の構文解析を見てください。サイズの違いは驚くべきものです。問題は、プログラミング言語の文法は正式なシステムであるということです。したがって、それらは数学的分析に適しています。あいまいさを処理すると、対応するプログラミング言語での解決策が簡単または単純になる多くの問題が発生します。

コンピューター科学者と「自然な」人々の間のギャップが縮まると、自然言語とプログラミング言語の間のギャップが縮まるかもしれません。


0

過去数年間、(E)DSLと流なインターフェイスへの関心は、Haskell、さまざまなスクリプト言語、C#、Java、さらにはC ++(さまざまな言語のoperator<<出力を行うため)。

ある程度まで、これらはコードがより自然に読めるようにします。groovyでのEDSLの例で説明します。groovy.timeのパッケージには、あなたが書くことができます

use ( TimeCategory ) {
    // application on numbers:
    println 1.minute.from.now
    println 10.days.ago

    // application on dates
    def someDate = new Date()
    println someDate - 3.months 
}

java.util.Calendarクラスを介してこれを行う場合、最初の例では次のように記述する必要があります。

void demo() {
    Calendar date = new GregorianCalendar();
    date.add(Calendar.MINUTE, 1);
    System.out.println(date);
}

0

コンピューター言語(昔の初歩的な機械言語でさえも)、主に仲間の人間とのコミュニケーションのためのものであり、人間によって定義され、機械に指示を伝えるために二次的にのみ使用されるため、人間の言語です。そのため、「自然」言語の進化とほぼ同じ方法で進化します(お気に入りの言語の「イディオム」を調べ、CがK&R Cから現在のISO-C 2011にどのように進化したかを確認してください。正確な意味を伝える必要があります(コンピューターはまだ理解できず、求められているものを修正することができません)、処理のしやすさにプレミアムがあります(したがって、C ++、PL / 1、またはAPLの文法や語彙ははるかに単純です)たとえば、自然言語としては英語はかなり単純です)。

数学または科学一般の形式主義、または青写真(本質的には2Dであり、他の1Dではありません)についても、ほぼ同じことが言えます。

弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.