現代のプログラミング言語を構築するための非標準的なアプローチ

大学以来、私は定期的に既存の製品の品質をテストし、開発中の研究を行う時間を見つけています。 私の研究の1つは、現代のプログラミング言語の作成でした。 残念ながら、私はこの問題で成功しませんでしたが、記事で共有するドアを自分で発見しました。



この記事は非常に入門的で、「水っぽい」ものであり、技術的な詳細はありません。 以下では、キーワードが開発速度を過小評価する期間について、難しい議論を始めようとします。 この投稿の言葉を泥の中に踏みにじり、議論の中で真実を生み出すためには、著者の言葉を取るか、研究を行う必要があります。 実際、著者はこれを求めています。

現代のプログラミング言語には何か問題があります

退屈しないように、既存のツールの欠点ではなく、言語の欠けている繊細さに焦点を当てます（多くの場合、言語は特定の開発環境に強く関連付けられています）。 そのため、以下では、「誰も話さない」最も「不要で役に立たない」5つの項目を選択しましたが、説明します。 はい、著者は男であり、コメントでホリバーを愛していますが、控えることを求めています。



1.通常のプログラマーは、誰にとっても短くて理解しやすいコードを書きたいと思っています。 この傾向は、Pythonの出現で非常に顕著です。 Objective-Cと比較したSwift、C ++と比較したD、および最近登場した他の言語を見てください。 全員が視覚的に言語の構築を促進し、意味と目的を維持するよう努めています。 もちろん、これはどこでもうまくいくわけではありません。



2.企業では、テストに時間がかかります。 テスターが余分なコードを書くのを軽減するために使用される言語に近いテストを自動化するときが来ました。 開発環境がコードテストプロセスの一部を自動化できるように、最新の言語に組み込まれた単体テスト設計は、言語自体と一体になる必要があります。



3.これまで、プログラマーは以前に記述されたコードの移植性が低いことを観察してきました。 ライブラリ/フレームワークではすべてが問題ありませんが、モジュールとクラスは大量のコードで失われます。 OOP、AOP、または機能的なアプローチは、そのようなコードの再利用を改善しません。 この問題は、言語の使いやすさ、開発環境の機能、特定の開発者向けの環境など、包括的に解決できます。 知識のポートフォリオのように、あなたのコードはいつかドキュメントのあるフォルダのように移植可能になります。 それらを簡単に組み合わせ、分離し、コピーし、その組み合わせから新しいパッケージを作成できます。 一言で言えば、Javaクラスで最後まで完了していないすべてのものと、他の多くの場所です。



4.現代の言語では、コードの透明性が不十分です。 ライブラリが添付されていない場合でも、コードについてです。 この獣の内部で何が起こっているかを正確にどれだけ知っていますか？ 幸いなことに、問題は非常にまれです。 しかし、それらが発生すると、人々はバイトコード、スタックデバイス、およびJavaクラス変換のジャングルに忍び込み、一見正常なコードの問題の原因を見つけます。 この問題はまれで複雑であり（もちろん、言語が原因ではありません）、通常は修正できません。 ただし、問題の検索で到達できるコードの深さでは十分ではありません。 デバイスのデータ型の最も扱いにくいニュアンスとメモリ内の位置は、コードの外部に隠されています。 これは、高レベルの呼び出しからすべてのビットへのコードの透明性を高めて戦う必要があります。



5.ソースコード（実際にはロジック）が鉄のアーキテクチャから可能な限り独立しているとすばらしいでしょう。 今日、すべてのデータ型、言語、およびそれらの標準ライブラリはバイナリアーキテクチャに焦点を当てています。 これは素晴らしいことであり、絶対に正しいことですが、非標準の腺およびアーキテクチャの研究者に自由を与えるものではありません。 現代言語の構成は、10進数または3進数のアーキテクチャには適用されません。



これらおよび他の多くの、はるかに重要な、開発中に解決しようとしているタスク。

ΣLプログラミング言語

初めに、そのような名前が選ばれた理由に関するいくつかの事実。 当初、この言語はWL（白色光から）と呼ばれていましたが、有名な人は、その壮大なプロジェクトWolfram Languageでこの省略名を取りました。 だから私はWを90度回し、それが気に入った。 インターネットに尋ねた後、私は手紙を間違った方向に向けたと気付いた。 「シグマ」という名前の言語が1965年から90年代まで存在したという事実にもかかわらず、プロジェクトの名前を再度変更することは望みませんでした。



シグマは、汎用プログラミング言語です。



シグマ言語の基礎は、既存のプログラミングパラダイムのほとんどを組み合わせたセットです。 セットは、オブジェクトよりもはるかに強力で柔軟です。 セットは、常にすべてのプログラミング言語でプログラマーと一緒にいました。 配列は、同じタイプの要素のセットです。 関数は一連の命令です。 構造/レコードは、データフィールドのセットです。 クラス/オブジェクトは、データフィールドと関数メソッドのコレクションです。 モジュール内の名前空間も、関数、クラスなど、このすべてのスタッフィングを含むセットです。 マットのようなセット。 セットを組み合わせて、いくつかのプロパティを設定できます。



一見したところ、これはJavaオブジェクトとクラスに非常に似ています。 実際、すべてがより複雑です。 配列について私が言ったことを思い出してください。 配列はセットです。 ここで、配列とその内容に対する操作を覚えておいてください。 オブジェクトまたはクラスの安全で制御された変更を想像してください。まるで配列を操作しているかのようです。 これで、セットをより完全に理解できました。



基本セットはクラシックネームソースであり、他のすべてのセットはそれから継承されます。



セットは要素のコレクションです。 セットは要素のコレクションのインターフェイスであると言う方が正確です。 要素は、関数、変数、その他のセットなどです。



内部設定は、実際には数学的な設定です。 一部のニュアンスを除き、セットにはセットのプロパティがあります。 または、明確にするために、セットは要素のコンテナです。 セットの説明は視覚的にクラスに似ています。 これにより、PLOから「継承」という用語を適用する機会が与えられます。 継承とは、新しいセットに要素セットを含めることです。 多重継承はセットの結合です。



セットがすべての言語にあることは注目に値しますが、クラスおよびオブジェクトのレベルでコンテナとして使用されたわけではありません。 少なくとも一般的な言語では、私はこれを見ていません。



数字に移りましょう。 通常、すべての数値はコンパイルプロセス中にコンパイラによって認識されますが、シグマでは、数値は言語の基本構造であり、ソースセットの存在のようにその存在は否定できません。 言語の利点として積極的に使用されています。 数字を示すためにアンダースコアが使用されます。



_ - ,

__ - ,

__._ - ,

__,_ - ,

_._ - ,

_,_ -







値の範囲を指定することができます。たとえば、__ [-10:10]は、-10から10までの値をとる整数です。



この言語には珍しいキーワード「me」があります。 これに代わるものですが、これについては後で説明します。



シグマコードの例：

 @binary //       binary { signed { //… } unsigned { //  -       bit: source { //source -   ,    _[0:1] value; state True is { //  -: true, TRUE, True, tRUE, ... me.value == 1; } state False is { me.value == 0; } // ,        operator := {} alloc(){} init(){} dealloc() {} } //bit } //unsigned alias bit signed.bit; alias ubit unsigned.bit; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ビットの値とそのステータスの説明に注意してください。 また、このコードを忘れないでください。戻ってきます。



この決定の理由は多くの人には明らかではありませんが、プログラマーはすぐにそのようなソリューションに慣れ、単純にそれを使用します。 問題はないようですが、実際には多くの問題がありました。 状態の説明を非常に明確で透明にするのに数ヶ月かかりました。 各言語での型の実装と条件付きifステートメントの操作について多くのことを話すことができますが、これは面倒です。



上記の説明は、プログラマーに対して透過的に説明される状態を明示的に紹介し、キーワードを使用して型にひそかに釘付けにされていません。 大まかに言って、このコードはそれ自体を文書化しています。 いつでも、特定の条件の意味を確認できます。その結果、ドキュメントの抜粋を覚えておく必要がなくなります。 Infinity、NaNなどの値を覚えていますか？ 現在では、このような設計で明示的に規定できます。



セット状態は、セットの特定の要素と目的の値との対応です。



現在、これはセットを使用した操作として実装されています。 状態は、セットからの特定の要素の固定コレクション、その静的サブセットです。 静的サブセットの各要素がセットの対応する要素と等しい場合、セットは記述された状態になります。 要素も設定できます/設定されます。 中括弧内の式を少し見てみましょう。

 state False is { me.value == 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

左側では、実行時の値（me.value）、右側では、説明で指定された静的セット（0）を使用します。 そのような表現がいくつかある可能性があります（もちろん、矛盾することは不可能です。もう一度me.valueを書くことは許されません）。



2つのセットの違いが作成されます。 それらが等しい場合、セットはそれ自体から減算されます（結果は空のセットです）。 条件演算子（および他の演算子）がこれとどのように機能するかについて質問が必要です。 ifステートメントは、空のセットをチェックします。 はいの場合、一連の命令が実行されます。



そして、ターゲットプラットフォーム用にコンパイルするとき、すべてが最適化されることを恐れないでください。 コードの一部は、ターゲットプラットフォームで定期的に比較されます。



この決定の主なマイナス点：同一以外の条件を処方することは不可能です。 たとえば、「me.value> = 0;」と書くことはできません。



コードでは、これはかなり馴染みがあります。 以下に、比較を記録するための4つのオプションと、ステータスを割り当てるための4つのオプションを示します。 すべては、ΣLの現在のバージョンに有効です。

 use binary; alias bit binary.unsigned.bit; bit b := 1; if (b == 1) { b := 0; } if (b == True) { b := False; } if (b is True) { b := binary.unsigned.bit.state.False; } if (b.state is True) { b.value := 0; }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

binary.unsigned.bitセットでは、比較演算子と代入演算子を実装する必要があります（後者は数値と状態の両方に対して）。 ルールは、優先度別の会話を示します。



今こそ、私があなたに覚えておくように頼んだ最初のコード例に戻る時です。



前の例では、実際のバイナリ鉄データの基礎となるビットについて説明しました（ よろしく、あなたの船長の証拠 ）。 このような記述的根拠に基づいたプログラムロジックは、完全にプログラマの力であり、鉄のアーキテクチャへの依存度が低くなります。 同時に、プログラマーは、プログラミング言語を変更したり、新しいキーワードを導入したりすることなく、鉄のアーキテクチャの基本的なタイプを実装する機会があります。 これは、そのようなコードをマシンのアーキテクチャまたはそのようなアーキテクチャのエミュレータにドッキングすることがより簡単になることを意味します。



バイナリマシン用のその他すべての種類の言語は、バイナリモジュールに基づいて派生しています。 たとえば、x86アーキテクチャの型の説明は次のように始まります。

 @x86 use binary; x86: binary { signed { byte {
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

10進数および3進数のアーキテクチャでも同様です。



「use」キーワードにも注意してください。使用後、通常の「import」、「using」、および「include」は、括弧の後に「begin」および「end」のように見えます。 著者は印刷するのが面倒で、急いでいた。 実際、著者はこのソリューションを本当に気に入っている多くの人々プログラマーを見ました。



この言語には他にも多くの珍しい解決策があります。 すべてに時間がある。 シグマは開発中であるため、現在この言語を仕事で試すことはできません。 おそらく将来、コミュニティの関心により、言語が出現し、そのニッチを占めるようになるでしょう。

meキーワードはself / thisなどを置き換えます。

このパートでは、おなじみのthis（またはself）キーワードを私に置き換えると、プログラミング中のタイピング速度と感触にどのように影響するかについて表面的に話します。



1つのキーワードを置き換えることは広大な砂漠の小さなオアシスであるということだけを予約してください。 つまり、このような置き換えは、調整された方法で開発速度に影響を与えないという結論に導きたいと思います。 これらのブロックの多くを1つのツールにまとめることによってのみ、開発の大幅な簡素化と高速化を実現できます。



テキスト入力を高速化するための置換は、ばかげたものに減らすことができ、プログラミング言語の場合、BrainFuckに似たものを手に入れることができます。 このため、さまざまな象形文字、ポンド記号などを使用してthisキーワードを置き換えるのはばかげています。 重要な注意：誰かにとって、そのような交換はばかげているように見えるかもしれませんが、この記事は彼らのためではありません。 さらに、キーボードでのそのような文字の入力は、常に提供されていて便利ではありません。



プログラミング言語の表現は、可能な限り明確で、明確で、短くする必要があります（そして、簡潔でわかりやすくエレガントに）。 可能であれば、人間が読めるフレーズを使用してください。 これにより、デザインを記憶し、新しい言語でより速く適応することができます。 ニクラウス・ワースは、そのような厳密で、明確で、人間が読めるプログラミング言語の成功例を示しました。 しかし、コードの書き込みと読み取りの速度には深刻な欠陥がありました。 簡単な例は、Pascalのbegin end構造です。 C言語の波括弧{}の後、書き込みの開始と終了は単純に使い果たされることに誰もが同意すると思います。 テクノロジー、過去の開発、最新のパディグに加えて、新しいプログラミング言語は上記を考慮すべきです。



その意味をゆがめないように、現代のthisを置き換えることができるのは、人間が読み取れる短いキーワードですか？ 新しい言語の著者として、この質問は私を悩ませました。 非常に弱いが、邪魔。 したがって、コメント欄にオプションを書いてください。多分あなたは「私の」を提案するでしょう、私はそれを拒否しました。



しかし、2つの有望な選択肢が思い浮かびます。非常に短いiと、より長い私です。 私の開発では、2番目のオプションに決めました。 このオプションは子猫のコミュニケーションに非常に似ていますが、真剣に、私は次の出版物のいずれかで私の選択を正当化します。



今世紀に誰かがプログラミング言語を開発するなら、i-methodを開発することを強くお勧めします。 これを使用すると、メソッドまたはフィールドへのアクセスポイントを削除して、ハンガリー語の表記とApple製品に似た名前iValueの問題を取得することができます。



そのような変更がプログラマーの速度にどのように影響するかという質問に戻りましょう。 あなたの謙虚な使用人を含む5人の仲間のプログラマーは、この重要でない実験を特別に行いました。 詳細を省略すると、明らかなことが確認されました。



連続印刷の速度の測定（実験開始から最初の6秒以内）で、私たちのチームは次の平均結果を示しました。



3 this.

3 self.

5 me.







次の数秒で、私のタイピング速度はこれと自己よりも大幅に進んだ。

タイピング速度の値は、同じフレーズを連続してタイピングすることに加えて、プログラマーの実際の仕事とは弱いつながりがあります。 そのため、すでに穏やかな環境で、意味のあるコードを書いている時点で、より重要な測定が行われました。 今回は急いでいる人はいませんでしたが、状況は日常業務に近いものでした。



結果は、平均して、自己とこれがプログラマーの仕事に同じ時間を費やすことを示しました。 したがって、自己とこれはほとんど競合できません。 作成されたセット（クラス/オブジェクト）が実装内で独自のメソッドを呼び出すことはほとんどなく、データフィールドにアクセスすることもめったにない場合は、私を使用しても利点はありません。 他のセット（主に独自のデータフィールドに頻繁にアクセスする）でコードを10個の自己またはこれが印刷されるごとに記述する場合、同時に最大16個のmeが印刷されました。 一部の同僚は、私を使用するとき、メソッドまたはフィールドの名前、つまり式にもっと焦点を合わせていると指摘しました：



me.valueResult += me.valueOne * me.valueTwo;







印刷時には、まるで私がまったくいないかのように読みました。



valueResult += valueOne * valueTwo;







彼らによると、これは自己とこれでは起こりませんでしたが、私は彼らを信じていません。 私の意見では、自己とこれはもちろん、コード行の中で、読むときに注意を引くよりも多くのスペースを消費します。 ちなみに、誰かにとってこれはプラスになります。 面白いマイナス-コードの読み取り速度が低下します。「self」と「zis」は「mi」よりもミリ秒長く読み取ります。 すべての楽しみは、コードの人間の理解の速度に本当に影響することです。



このような小さな交換が問題を引き起こさないことが重要です。 すべての被験者がmeキーワードを使用するように非常に簡単に切り替えたため、不快感を感じる人はいませんでした。 それどころか、誰もがこの交換が好きでした。



このトピックに興味がある場合は、作成するプログラミング言語に関係なく、同様の実験を必ず行ってください。 そのような実験から肯定的および否定的な経験だけでなく、気にしない人々の意見を集めることは興味深いでしょう。



いずれにせよ、プロジェクトを台無しにすることはほとんどありません。Ctrl+ Hの組み合わせに加えて、すべての「me」（先頭にスペースを入れて）を「this」に置き換えます。



読んでくれてありがとう。

忍耐と力があなたと共に来ますように！