完璧なプログラミング言語に関する考え

この記事では、理想的な汎用プログラミング言語に関する私の考えを共有したいと思います。 まず第一に、C ++を置き換えることができる言語について。



プログラミング言語が私の趣味であり、ITに対する主な関心事であることがたまたま起こりました。 おそらく、どのプログラマーも、自分自身の理想的なプログラミング言語を作成したいと思うことがあります。 私にとって、これは単なる夢ではありません。実際、私は長い間、さまざまな言語ですべての情報を収集し、自分の言語を設計してきました。



さまざまなリソースで、このテーマの問題について定期的に発言しています。 この記事では、主な考えをまとめようとしました。 C ++の主な欠点、C ++と何らかの方法で比較できる他の言語の機能、および最も興味深い-言語ライブラリーのプログラマーのニーズを、Boostライブラリを例として使用して検討します。



この記事は、技術的な有用性を主張するものではありません（誰かにとって有用であれば、これは素晴らしいことです）。 この記事は、ディスカッションへの招待です。



C ++は理想からかけ離れています。 C ++プログラマなら誰でも同意するでしょう。



C ++の欠点は、何よりもまず、Cの重い遺産です：包含のひどいシステムとモジュール性の完全な欠如です。 ヘッダーファイルを含めると、基本的に、ファイルの内容全体がコンパイル単位に含まれます。 ヘッダーファイルにはお互いが含まれており、最新のライブラリには何万ものヘッダーファイルが含まれている可能性があるため...もちろん、これはコンパイル時間に影響します。 「プリコンパイル済みヘッダー」（pch）などのさまざまなハッキングソリューションが役立つ場合がありますが、実践が示すように、これらのソリューションは理想からはほど遠いものです。 たとえば、Visual C ++では、1つのソリューションの複数のプロジェクトに共通のpchを作成できません（通常、プリコンパイル済みヘッダーには、stl、boostなどの本当に一般的で不変のヘッダーが含まれています）。



そしてもちろん、プログラマーの特徴である内部完全主義は、そのような実装に強く抗議します。基本的には松葉杖であり、最初は正しくないアーキテクチャを支持します。

#define true false
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、「レキシカル」プリプロセッサ、Cの別のこんにちは、大きくてしっかりと成長したUnixのレガシー（はい、実際には別のプログラムであり、はい、たとえばm4などの代替プリプロセッサがありますが、今ではプリプロセッサは明らかに一部として認識されています言語）。 しかし、プリプロセッサタスク（より正確には、構文マクロのシステム）を解決する特定の機能セットが言語に必要であることは明らかであり、これは言語とは関係のない非標準のサードパーティプログラムであってはなりません。



そして、比較的新しい-テンプレートの完全なチューリングは、これらの同じテンプレートで地獄のようなメタプログラミング構造を生み出しました。 最初は、もちろん、テンプレート関数とクラスは、処理/保存されたデータのタイプに依存しない普遍的なアルゴリズムとデータ構造を記述するためだけに使用されると想定されていました。 素晴らしい使用！ しかし。



組み込みの構文マクロの欠如と機能に対する永遠の渇望により、プログラマーは、コンパイル時にコンパイラーによって実行されるメタタイプ、メタアルゴリズム、および計算を使用して、テンプレートに完全なメタ言語を作成することを余儀なくされました... 本質的に松葉杖であること以外は何もありません。



しかし、たとえば、キーワード（構造体）が意図された目的に使用されていない場合は不快です。 そしてもちろん、誤ったタイプミスのためにしばしば発生し、エラーごとに数十行（数百行ではないにしても）を要する不適切なエラーメッセージ...これは本当にひどいです。



もちろん、C ++には他にも十分な欠点があります-些細なことです。 いずれにせよ、それらの多くは次世代のアプリケーションプログラミング言語であるJavaとC＃で考慮されます。 ところで、私の好みでは、C＃は他の多くの言語の機能を最も動的かつ有機的に吸収します。 これは、美しくバランスの取れた言語の素晴らしい例です（したがって、新しい言語を設計するときに見ることができる素晴らしい例です）。 しかし、JavaもC＃もシステムプログラミング言語ではありません。



D、Go、Rust、Swift、Nim、および比較的古いObjective C（その非常に興味深い機能-ランタイム）を参照する新しい（C ++に関連する）言語のグループがもう1つあることに注意してください。



これらの言語の何が面白いですか？



Dから始めましょう。この言語は「改善されたC ++」として開発されました。実際、多くの概念はより有能に作られています。 コントラクトプログラミングは慎重に実装され、FPがあり、メタプログラミングの特定の実装があります（しかし、もっとうまくやれます！）。 この言語はネイティブコードにコンパイルされます。つまり、「体系的な」ふりをすることができます。 しかし、私はDですべてを覆い隠す機能を強調しません。 それでも、言語は「ハッキング」の蓄積という点でC ++のパスをたどっているように見えますが、これはコンパイラコード（私は定期的に行っています）を調べるときに特に顕著です。



行く 良い点としては、インターフェイスの構造型付けがあります。 機会は非常に興味深いです、私はそれを使いたいだけです...



言及する価値があるもう1つのことは、継承の代わりに埋め込みです。 あなたはそれを見たとき、あなたは思う-しかし、それはCに戻ってくるはずです！ 実装は非常に簡単です。それにもかかわらず、このソリューションはどれほどエレガントに見えますか。 言語に組み込まれたマルチスレッドのサポートも楽しいです。



錆。 主な機能は、コンパイル時のスマートポインターとチェックのすばらしいシステムです。 はい、完璧な言語を取り入れる価値はありますが、多くの人はシステムが複雑すぎると不満を述べています。 実際、余分なものは何もありませんが、古典的なポインターを拒否することはありません（ちなみに、Rustでは破棄されず、単純に安全ではありません）。 これを組み合わせることができますか？ できます。 可能性については何も悪いことはありません;それらの不在はひどいです。



そして、Objective Cに言及したいと思います。言語はかなり古いですが、OSXの世界に精通していない人は、その中に多くの興味深いものを見つけるでしょう。 これはOOPの特別な実装です。特に、メソッド、セレクター、メタクラスのシステムを直接呼び出す代わりにメッセージを送信します。 Smalltalkからこの言語に移行したことにより、これらの機能により、コンパイルされた言語で多くの驚くべきことを行うことができます。これらは、解釈されたスクリプトでのみ実現できます。 私の意見では、素晴らしい機会です。



次の興味深い質問は、言語の機能とライブラリに入れることができるものとの関係です。 そのため、長い間、最も強力なユニバーサルプログラミング言語であったのはC ++でした（そして、今でも、すべての短所にもかかわらず、おそらく残っています）。 代替手段はありませんでしたが、C ++自体は長い間かなりゆっくりと開発されており、プログラマーは常により多くを求めています！ いずれにしても、さまざまなライブラリが出現し、開発され始めました。 標準ライブラリがすでに存在しているという事実にもかかわらず、他の多くのライブラリとフレームワークは、多くの場合、その機能をクラスで複製しました。 顕著な例は文字列です。 C ++には標準の文字列（std :: string）があるように見えますが、ほとんどありません-ほぼすべての大規模なライブラリには独自の文字列の実装があります。 CString（MFC / ATL）、QString（Qt）、TString（VCL）、wxString（wxWidgets）。



同じ運命がさまざまなコンテナ（動的な配列とリスト）、さまざまな階層の基本クラス（オブジェクト-標準ライブラリにはこのようなものがないことを認める必要があります）に影響を与えました。 私は、ほとんどすべての小さなプログラム（ライブラリーでさえも）に見られる単純型の再定義について話しているのではありません。 あらゆる種類のUINT、uint、u32、DWORD、uint32_tを思い出してください...しかし、言語の設計を研究するための最も興味深いオブジェクトは、おそらくBoostライブラリ（ Boost Incubatorおよびその他の非公式の拡張機能にある公式の部分とUnder Constuctionステータスのライブラリの両方）です。 彼女に戻ります。



C ++は次のように見えると言えます：小さな言語コア、小さな標準ライブラリ、および互いに交差し、部分的に標準ライブラリと交差し、言語機能のエミュレートから適用されたタスクまでのさまざまな責任を捕捉する多くのサードパーティライブラリ。 多くのライブラリはカーネルのみに依存しています。 このようなもの：







小さな言語コアは多くの言語機能をサポートしておらず、プログラマーに「言語機能のエミュレーション」を書くように促します。 多くのプログラマーがいるため、対応するエミュレーションも多数あります。 通常、これらは互いに互換性がありません。 かさばる（非標準および/または既存の言語機能の明白でない使用に基づいて構築されているため）; コンパイルとデバッグが難しく、実際には理解が難しい。 一方、小さなカーネルでは、言語に余分なものが含まれないようにすることができ、これは良いことです（さらに、システムプログラミングに必要です）。 論争？ 実際には決定的な矛盾。 これが私の完璧な言語組織図です。







中央には、コア言語のコアがあります。 その周辺は「言語拡張機能」であり、言語拡張機能は構文的にサポートされている特定の言語部分ですが、プロジェクトのアセンブリ中にオン/オフを切り替えたり、独自の実装に置き換えることができます。 さらに-汎用プログラミングに関連するすべてをサポートする標準ライブラリ。 およびその周辺-カーネル機能をエミュレートしようとしないが、純粋に適用された問題を解決するアプリケーションライブラリ。 アプリケーションライブラリは特定のものを実装する必要があります。 これは不可欠です-一般的なものと特定のものの違い。 グラフィックス、ネットワーク、鉄を使用します。 特定の数学、暗号、一部の特別な分野のアプリケーションライブラリ。 さまざまなファイル形式、データベース、さまざまなサービスで動作します...これらはすべて特定の適用領域であり、ライブラリの形式で実装する必要があります。 ただし、リフレクションまたはマルチスレッド、高階関数またはコルーチンは、言語の観点から基本的なものであり、言語でサポートされる必要があります（デフォルトの実装を別のものに置き換える機能を持つものもあります）。



Boostライブラリに戻ります。 Boostが、言語がプログラマーが望むよりもはるかにゆっくりと発展する方法の最も明確な例として話しましょう。 Boostライブラリのかなりの半分は、基本的に言語機能のエミュレーションです。 おそらくいつか、Boostライブラリに関する個別の記事を書くことになります。ここに、プログラミング言語にこれらの機能を直接含めるという文脈で、そこにあるものの簡単な概要を示します。 Boostにはライブラリの独自の分類があり、これにはまったく同意しません（ただし、分類の目標は異なります）。 一部のライブラリは、確かに「標準ライブラリ」グループに属します。 一部-一般的に適用されるライブラリ。 しかし、重要な部分は、まさに言語自体、コアに欠けているものです！ ここでは、ライブラリの区分や説明はしません（これは別の記事のトピック、またはいくつかのトピックです）。 代わりに、言語コアを参照するブーストライブラリのライブラリのリスト（不完全！）を提供します。

• 整数-整数型のメタ情報と特性
• 多精度-任意の精度の数値GMP、MPIR、MPFRを備えた作業ライブラリのラッパー
• any-ユニバーサルダイナミックタイプ
• optional-オプションのタイプ、多分; 理論的には、言語に組み込み、nullableと統合する必要があります
• バリアント-代数データ型（和型、タグ付きユニオン）
• プリプロセッサ-システムプリプロセッサでのメタプログラミング
• inentity_type-一意の型名を生成するためのヘルパー
• assign-コンテナの充填に関連する複数操作
• mpl-コンテナーとその操作を入力します
• フュージョン-タイプと値のコンテナー、およびそれらに対する操作
• tuple-タプル
• bind-関数の部分的な適用を使用して作成された機能オブジェクト
• 関数-関数オブジェクト
• lambda-ラムダ関数; ところで、いくつかの点でc ++ 11の優れたラムダ。
• local_function-ネストされた関数のエミュレーション
• signal2-シグナルとスロット
• コンテキスト-ストリーム（スタックとレジスタ）の状態の保存と復元
• コルーチン-コルーチンの実装
• foreach-収集サイクル
• パラメーター-名前付き関数の引数のエミュレーション
• scope_exit-言語コンストラクト、D言語ではスコープ（exit）、スコープ（success）、スコープ（failure）と呼ばれ、Go-defer
• type_erasure-ランタイムポリモーフィズムの代替実装
• predef-OS、コンパイラ、プラットフォームに関するメタ情報...、
• typeof-typeof / decltype演算子のエミュレーション
• エンディアン-異なるバイト順の数字を扱う

これは完全なリストではないことを思い出させてください（そして、ここでBoost拡張ライブラリも見ていませんが、そこには多くの興味深いものがあります-たとえば、Contract、Hana、Introspection、Mirror、Reflection ...）。 すべてのライブラリから言語コアに含まれるべきではないことに注意してください。一般的な場合、カーネルに含めるのはごく一部の（そして多くのライブラリに共通する）部分だけで十分です。このリストの多くのライブラリはまったく必要ないことがわかります。 また、言語コアに含めることにより、さまざまな機能の既存の人為的な実装に課せられる制限の多くが回避されます。 代数的データ型、ユニバーサルダイナミック型any、オプション型、名前付きパラメーターなどの優れた機能は、もちろん、言語レベルで最適に実装されます。



それでは、言語拡張機能に移りましょう。 それは何で、なぜ紹介したのですか？

実際、このような「拡張」はC ++に何らかの形で存在し、それらを個別のグループとして選択する人はいません。 例は、C ++のメモリ割り当てシステムです。 言語カーネルインターフェイスは、新しい演算子および削除演算子です。 その構文は言語コアで明確に記述されており、そのセマンティクス（メモリ割り当てと解放）はドキュメントで明確に記述されています。 同時に、この言語は標準の実装を提供しますが、必要に応じてこれらの演算子をオーバーライドし、独自のメモリ割り当てシステムを作成できます。 2番目の例は、ランタイムタイプ識別、RTTIです。 この例では、拡張機能の切断性という別の側面を示します。



私はマイクロコントローラを使った幅広い経験があり、非常に少量のオンボードメモリではメモリを静的に割り当てるだけでした。「ヒープ」はなく、RTTIもありませんでした。



CoreとExtensionsの唯一の違いは、コア要素をオーバーライドできないことです。 したがって、条件付きifステートメントは明確であり、そのロジックはカーネルに接続されており、その実装を他のものに置き換える方法はありません。 拡張機能は構文レベルでカーネルに登録され、 特定のデフォルトの実装が言語で提供されます 。これはプログラマの95％に適しています。 残りの5％は、言語インターフェースに対応する実装を作成するか、特定の場合に完全に無効にするよう招待されています。



他のそのような拡張機能は

• ガベージコレクション（Rust-Gcを参照）
• 参照カウントによるメモリ管理（Rust-Rc、Arcを参照）
• 長い算術（ここでは、算術をリテラルレベルを含めて言語に統合することが重要です.128ビット数などの長い定数は、自然な方法で記述する必要があります-すべての実装で同じ数値リテラルの形式で！）
• マルチスレッド（go言語のgo演算子）
• リフレクション（はい、手動で実装する方法はたくさんありますが、コンパイラよりも優れています。とにかく誰もこのタスクを実行できません）
• 仮想性とマルチメソッド
• 信号とスロット
• オブジェクト型スピーカー
• 組み込みスクリプト
• rtti
• 例外処理（実装にはさまざまな方法があり、まったく必要ない場合もあります）
• 浮動小数点（はい、一部のマイクロコントローラーではFPUがなく、ライブラリは浮動小数点での動作をエミュレートします）

そして、おそらく私がすぐに思い出せなかったことのはるかに。



最後に、理想的なプログラミング言語のアイデアの根底にある1つの哲学的原則について説明します。 通常、フォーラムでのディスカッション中に、言語XにYの機能はないと言うと、「A、B、Cの機能を持ち、松葉杖D、Eをねじると、 F、それから私たちはほとんどYを得ます。はい、そうです。 しかし、私はこのアプローチが好きではありません。 そのようなプログラマーは、迷路を通る困難な道のりに満足すると想像できます。 迷路を通過することはできますが、曲線の経路は明らかではありません。 迷路の代わりに、任意のポイントから他のポイントまで直線に沿って進むことができる広々としたエリアが欲しいです。 まっすぐに。