プログラミング言語の構文は実装に依存していますか？

しかし、私の質問はまったく無関係かもしれませんが、ほとんどのプログラミング言語と公式の実装との間のパターンを感じました。

PythonやLuaなどの解釈された（バイト解釈？）言語は、通常、非常に寛容で簡単な構文を持ち、一般に型がなく、開発者がソースコードに変数の型を明示的に記述する必要はありません。

C、C ++、Pascalなどのコンパイルされた言語は通常、厳密な構文を持ち、一般に型を持ち、ほとんどの場合より多くのコード/開発時間を必要とします

Java / C＃のように公式実装がJITコンパイルされている言語は、通常、上記の2つの間の優れた機能を備えた独自の妥協案です。

DやVala（およびJavaのGNU GJC実装）のような最新のコンパイル済みプログラミング言語の一部は、おそらくこの規則の例外であり、JavaやC＃などのJITコンパイル言語の構文と機能に似ています。

私の最初の質問は、これは本当に関連性がありますか？または、これはほとんどのインタープリター言語が簡単な構文を持っていることと単なる偶然の一致であり、JITコンパイルされた言語は中程度の構文と機能を持っています

第二に、これが偶然ではない場合、なぜそうなのですか？たとえば、たとえば、JITコンパイルしている場合にのみ、プログラミング言語で実装できる機能はありますか？

セマンティクスと構文の間には何の関係もありません。Schemeのようなホモイコニックコンパイル言語には、最小限の構文が付属しています。Forthのような低レベルのコンパイル済みメタ言語は、それよりもさらに単純です。一部の非常に厳密に型指定されたコンパイル言語は、簡単な構文に基づいて構築されます（ML、Haskellを考えてください）。OTOH、Python構文は、多くの構文規則の点で非常に重要です。

そして、はい、タイピングは構文とは何の関係もありません。それは言語のセマンティクス側にあります。ただし、すべてのタイピング情報がなければ解析することさえできないC ++のような異常なものでない限りです。

一般的な傾向は、あまりにも長く進化し、構文の逸脱に対する設計上の保護手段をまったく含まない言語は、遅かれ早かれ構文的憎悪に進化することです。

ほとんどこれは偶然です。

プログラミング言語は時間とともに進化しており、コンパイラーとインタープリターのテクノロジーは改善されています。基になる処理の効率（つまり、コンパイル時間、解釈のオーバーヘッド、実行時間など）も、主流のコンピューティングプラットフォームが成長するにつれて重要性が低下しています。

言語構文には影響があります。たとえば、Pascalは非常に慎重に設計されているため、シングルパスコンパイラを使用できます。一方、Adaはこれに注意を払わず、Adaコンパイラーは書くのが難しいことで有名です-ほとんどは複数のパスを必要とします。（私が何年も前に使用した非常に優れたAdaコンパイラは、8パスコンパイラでした。ご想像のとおり、非常に低速でした。）

Fortran（コンパイル済み）やBASIC（解釈済みまたはコンパイル済み）などの古い言語を見ると、非常に厳密な構文規則と意味規則があります。[BASICの場合、Billsの古いBASICではありません。その前に元に戻す必要があります。]

一方、APL（たくさんの楽しみ）のような他の古いものを見ると、これには動的なタイピングがありました。また、一般的に解釈されましたが、コンパイルすることもできました。

寛容な構文は難しいものです。それは、オプションのものや推論できるものがあることを意味する場合、その言語には十分な豊富さがあり、meansされる可能性があることを意味します。そして再び、BASICには、何年も前に「LET」ステートメントがオプションになったときがありました。

現在見られるアイデアの多く（たとえば、型なしや動的な型付け）は実際には非常に古く、1970年代または1980年代初頭に最初に現れました。それらの使用方法、およびこれらのアイデアが使用される言語は変化し、成長しました。しかし基本的に、新しいものの多くは、実際には新しい服を着た古いものです。

ここに私の頭の上のいくつかの例があります：

• APL：動的型付け。一般的に解釈されます。1960年代/​​ 1970年代から来ました。
• 基本：強力または動的な型指定。解釈またはコンパイル。1970年代以降。
• Fortran：強い型付け。編集済み。1960年代以前。
• Algol68：強い型付け。編集済み。1960年代。
• PL / 1：強い型付け。編集済み。1960年代。
• パスカル：強い型付け。編集済み。1970年代。（しかし、1980年代には、JITコンパイラに非常によく似たPシステムコンパイラがありました！）
• 初期のDECによるFortranやその他の実装の一部は、部分的にコンパイルされ、部分的に解釈されました。
• Smalltalk：動的型付け。解釈されるバイトコードにコンパイルされます。1980年代。
• プロローグ：より奇妙。機能的。コンパイル済み（Turbo Prolog、誰か？）。1980年代。
• C：強い（ハハ）タイピング。編集済み。1960年代..今日
• Ada：非常に強力なタイピング。編集済み。1980年代。
• Perl：動的型付け。（強力な構文）。解釈済み。1990年代（？）

続けられた。

• Nitpickersコーナー：多くのインタープリター言語は、ソースが読み込まれた/読み込まれた時点でトークン化または「バイトコンパイル」されます。これにより、インタープリターのその後の操作が非常に簡単になります。コードのバイトコンパイルバージョンを保存できる場合があります。できないこともあります。まだ解釈されます。

更新：十分に明確ではなかったため。

入力は大きく異なります。

コンパイル時の固定静的型付けが一般的です（C、Ada、C ++、Fortanなど）。これは、タイプのTHINGを宣言する場所であり、その方法は永遠に続きます。

また、動的型付けを行うこともできます。動的型付けでは、割り当てられている型を取得します。たとえば、PHPと初期のBASIC、およびAPL。変数に整数を割り当て、それ以降は整数型でした。後で文字列を割り当てた場合、それは文字列型でした。等々。

そして、たとえば、数値整数（引用符で囲まれた文字列）を変数に割り当ててから数値を追加するなど、本当に奇妙なことを実行できるPHPのように、緩やかな入力があります。（たとえば、 '5' + 5は10になります）。これは奇妙な国ですが、時には非常に便利です。

ただし、これらは言語に組み込まれた機能です。実装はまさにそれを実現します。

私はそれが他の方法だと思う：実装は構文に依存します。たとえば、構文がリフレクションを許可している場合、実装はそれをサポートするランタイムを提供する必要があります。

あなたの観察は主に歴史の結果であるという点で、私は一般的にすぐに同意します。とはいえ、根底にある推論は次のようなものに要約されます。

The more modern a language is, the more comfortable it should be to use.

（実際には引用ではなく、私自身の定式化です。）私がcomfortableここに書いているとき、私はあなたが呼んだものを参照しますbest features of both。より正確には、静的/動的タイピングや厳格/寛容な構文について賛否両論したくありません。代わりに、開発者に焦点を当て、言語で作業するときの快適さのレベルを高めることが重要です。

以前の回答で言及されていないいくつかの理由を次に示します。これらは、これらのことを観察する理由についてのアイデアを提供する可能性があります（すべての種類のプログラミング言語開発の歴史に基づいています）。

• 最近、何百ものプログラミング言語があります。新しいものが登場したら、どのようにして幅広い視聴者を見つけることができますか？これが主な理由であり、新しい言語が常に開発者の快適レベルを向上させようとする理由です。言語が古い言語と同じことができるが、はるかに簡単/簡単/よりエレガント/などできる場合。実際に切り替えることを検討してください。

• 学習曲線はそれと連動します。過去には、言語がほとんどなかったため、時間をかけて学習する価値がありました。それが多くの時間を投資することを意味したとしても。開発者が非常に迅速に学習できる言語を考え出せば、快適さが再び向上します。あらゆる種類の複雑さ（f.ex.、複雑で複雑な構文など）はこれに有害であり、したがって、新しい言語ではますます減少しています。

• 技術の進歩（ここでの直接的な歴史的理由）は、コンパイラビルダーが開発者の快適さにより重点を置くことができるようになった原因です。初期の頃は、コンパイラをまったく作成できて満足でした。ただし、それはしばしば、厳しい制限が行われることを意味します。技術的ノウハウが増加するにつれて、これらの制限を再び解除することができました。

そのため、一般的に、プログラミング言語とコンパイラーは、典型的なエンドユーザーアプリケーションと同様の開発を経験しています。

1. 初期段階：持っているのはクールなことですが、最先端のテクノロジーにより、快適さ/使いやすさ/その他が犠牲になります。
2. 技術的改善：これらのものをより堅牢、高速、簡単に構築できます。
3. ユーザーに焦点を当てる：ユーザーエクスペリエンスに焦点を当てたWeb2.0の動きと同様に、新しいプログラミング言語は開発者の視点に焦点を当てています。

特定のプログラミング言語は、コンパイラが実行時の決定を追加せずに実行可能コードに還元する方法を推測するのに十分なセマンティック情報を公開または制約する場合としない場合があります（「この変数はどんな型ですか？」など）この制約は必須、または簡単に決定できます。

コンパイラがよりスマートになると、それらの決定を公開または制約するように明示的に設計されていない言語であっても、最も可能性の高いパスの実行可能コードを生成するのに十分な情報を推測またはプロファイリングできる場合があります。

ただし、実行時にコード（evalString（））を作成または入力できる言語（およびコンパイラーが推測または推測できないその他のもの）では、事前に処理しようとしても、実行時にインタープリターまたはJITコンパイラーを使用可能にする必要がある場合がありますそれらをコンパイルします。

過去に、プログラミング言語とその実装は、インタープリターが4kまたは16kに収まるかどうか、コンパイラーが1分未満のCPU時間で終了するかどうかなど、ハードウェアの制約に適合するように進化していた可能性があります。マシンが高速化するにつれて、プログラマーがリターンキーを押すのと同じ速さで、以前に解釈されたプログラムを（再）コンパイルしたり、以前にコンパイルされたプログラムのソースコードを、少し古いハードウェアが最適化されたコンパイル済み実行可能ファイルを実行するよりも速く解釈することが可能になりました。