アプリケーション開発への根本的なアプローチ

翻訳者から：2007年にWebエンジンを探して、私はLispの非常に興味深い珍しい方言に出会いました。 そして、いくつかの記事を読んだ後、その原則に魅了されました。 私の主な仕事はWebプログラミングとはほど遠いので、私はそれを専門的に使うことはありませんが、時々それに戻って少しの「嵐」になります。



この言語に精通している間、彼は事実上どこにもフラッシュせず、ロシア語ではほとんど情報がありません。 このギャップを埋めようとしましょう。 元の記事の日付は2006年であるにもかかわらず、このトピックは非常に重要です。

Nadezhda Zakharovaおよび素晴らしいサイトNotabenoidの翻訳にご協力いただきありがとうございます。

1.はじめに

私はフリーソフトウェアのコンサルタントおよび開発者として働いています。 20年間、パートナーと私は、画像処理、コンピューター支援設計、モデリングシステム、およびさまざまな金融およびビジネスアプリケーションなどのプロジェクトに取り組んできました。



これらのプロジェクトのほとんどすべてで、Lispを使用しました。 私の毎日の仕事は、顧客の要求に耳を傾け、ビジネスプロセスを分析し、顧客のニーズに応じてソフトウェアを開発することです。



通常、ERPやCRMなどのビジネスアプリケーションでは、これは絶えず変化するプロセスです。 新しいプロジェクトの開始時には、開発者も顧客も、必要なものや最終製品の外観を正確に把握していません。



これは、反復プロセス中に発生します（「極端なプログラミング」と呼ばれることもあります）。 クライアントはそれぞれの新しいバージョンを評価し、プログラムをさらに開発するための戦略について話し合います。 多くの場合、予期しない要件により、プロジェクトの大部分を書き直す必要があります。 これは、私が説明するプロセスが計画であるため、プロジェクトが不十分に計画されたことを意味するものではありません。 理想的な世界では、ソフトウェア開発は計画しているだけなので、コードを直接書くのに費やす時間はゼロになるはずです。



私たちは、プログラムにしたいことを直接表現できるプログラミング言語が必要です。 プログラマーがいつでもプログラムで何が起こっているのかを理解できるように、コードはできる限りシンプルであるべきだと考えています。



長年にわたって、 Pico Lispシステムは、Lispの最小限の実装から専用のアプリケーションサーバーへと進化してきました。 ラピッドプロトタイピングツールについて話しているわけではないことに注意してください。 開発の各段階で、結果はプロトタイプではなく完全に機能するプログラムになり、シリアル（おそらく最新）バージョンに成長します。 それどころか、開発環境を整然と保ち、アプリケーションのロジックとデータ構造を簡潔な表現で表現したいプロのプログラマーの強力なツールと言えます。



最初に、Pico Lispを紹介し、低レベルのPicoが他のLisp-sまたは開発システムと大きく異なる理由を説明し、次に高レベルでその利点を示します。

2.急進的なアプローチ

おそらく（Common-）LispコミュニティはPico Lispを喜ばないでしょう。なぜなら、それは伝統的になった信念や教義のいくつかを破壊するからです。 それらのいくつかは単なる神話ですが、Lispが過度に複雑で遅くなる原因になります。 Pico Lispの実際の経験は、軽量で高速のLispが多くのタイプの効果的なアプリケーション開発に最適であることを証明しています。

2.1。 神話1：Lispにはコンパイラが必要

実際、これは最も重要な神話です。 Lispグループの議論に参加した場合、コンパイラが主要な役割を果たしていることがわかります。 ランタイムとほぼ同義語のように思えるかもしれません。 コンパイラーがコードに対してどのようなアクションを実行し、どの程度効率的であるかが重要です。 Lispプログラムの実行が遅いと思われる場合は、より良いコンパイラが必要であると判断します。



解釈されたLispの考え方は古い妄想とみなされています。 Modern Lispにはコンパイラが必要です。インタプリタは便利な追加機能であり、アプリケーションのインタラクティブなデバッグに必要です。 すでにリリースの準備ができているプログラムを実行するには、速度が遅すぎて肥大化しています。



反対の見方が正しいと確信しています。 （哲学的な観点だけでなく）一方で、コンパイルされたLispプログラムはもはやLispではありません。 これは、「コードとデータの形式的な同等性」という基本的なルールに違反します。 結果のコードにはS式が含まれておらず、Lispで処理できません。 ソース言語（Lisp）は別の言語（マシンコード）に変換され、異なるマシンでは避けられない非互換性があります。



実際には、コンパイラはシステム全体を複雑にします。 コンパイラのニーズを満たすために、マルチリンク戦略、型付き変数、マクロなどの機能が開発されました。 システムはインタプリタをサポートしなければならず、それに応じて2つの異なるアーキテクチャをサポートする必要があるため、肥大化しています。



しかし、努力する価値はありますか？ もちろん、実行速度は速く、コンパイラーの作成はトレーニングの目的には興味深いものです。 しかし、日常生活では、適切に設計された「通訳者」がコンパイルされたシステムをしばしば上回ることができると主張します。



あなたは、私たちが実際に「解釈」について話しているのではないことを理解しています。 Lispシステムは、渡されたデータをすぐにS式と呼ばれる内部ポインタ構造に変換します。 真の「解釈」は1次元の文字コードで機能し、これにより実行プロセスが大幅に遅くなります。 Lispは、これらのポインタ構造に従って、S式をすばやく「計算」します。 検索がないため、実際に「解釈」されるものはありません。 しかし、私たちはこのよく知られている用語を守ります。



S式としてのLispプログラムは、実行可能ノードのツリーを形成します。 これらのノードのコードは通常、最適化されたCまたはアセンブラーで記述されるため、インタープリターのタスクは、あるノードから別のノードに制御を移すことです。 これらの組み込みLisp関数の多くは非常に強力で多くの計算を行うため、ランタイムのほとんどはノード用です。 ツリー自体は一種の接着剤として機能します。



Lispコンパイラは、この接着剤の一部を削除し、一部のノードをプリミティブまたはストリーム機能に機械コードに直接置き換えます。 ただし、いずれの場合もランタイムの大部分は組み込み関数に依存するため、これらの改善は、たとえば各ノード（バイトコード）が比較的原始的な機能を持つJavaバイトコードコンパイラほど劇的ではありません。



もちろん、コンパイル自体にも多くの時間がかかります。 多くの場合、アプリケーションサーバーはLispソースファイルを1回の実行でオンザフライで実行し、実行されるとすぐにコードをすぐに破棄します。 そのような場合、コンパイラに基づいて最初に低速になったLispシステムのインタプリタ、またはコンパイラが費やす時間の増加により、全体的なパフォーマンスが大幅に低下します。



Pico Lispの内部構造は、もともと解釈を容易にするために設計されました。 それらは完全にCで書かれており、特に速度が最適化されていませんが、パフォーマンスが不十分という問題はありませんでした。 Pico Lispで書かれた最初の商用システムは、画像の処理とレタッチ、および印刷用のページレイアウトの作成を行うシステムでした。 1988年に作成され、12 MHzのCPUと8 MBのRAMを搭載したMac IIで使用されました。



もちろん、Lispコンパイラはなく、Cで書かれた低レベルのピクセル操作とベジェ関数しかありませんでした。それでも、最新のコンピューターよりも数百倍遅いコンピューターで作業しているとき、パフォーマンスについて文句を言う人はいませんでした。



興味のために、私はCLispをインストールし、例として簡単なテストを使用してPico Lispと比較しました。 もちろん、これは、テスト結果がアプリケーションサーバーとしての特定のシステムの有用性を示すことを意味するものではありませんが、これらのシステムのパフォーマンスのおおよそのアイデアを提供します。 最初は、単純な再帰フィボナッチ関数を実行しようとしました。

(defun fibo (N) (if (< N 2) 1 (+ (fibo (- N 1)) (fibo (- N 2)) ) ) )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

パラメーター30（fibo 30）でこの関数を呼び出すと、次の結果が得られました（テストはPentium-I 266 MHzラップトップで実行されました）。

ピコ（解釈）	12秒
CLispの解釈	37秒
コンパイルされたCLisp	7秒

CLispインタープリターはPico Lispのほぼ3倍遅く、コンパイラーはほぼ2倍高速です。



しかし、フィボナッチ関数は典型的なLispプログラムの良い例ではありません。 プリミティブストリームと算術関数のみで構成され、コンパイラによって簡単に最適化され、時間が重要な場合はCで直接記述できます（この場合、0.2秒しかかかりません）



そのため、広範なリスト処理を実行する関数を使用して、別の極端なケースを取り上げました。

 (defun tst () (mapcar (lambda (X) (cons (car X) (reverse (delete (car X) (cdr X))))) '((abcabc) (bcdbcd) (cdecde) (defdef)) ) )
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

この関数を100万回呼び出すと、次のようになりました：

ピコ（解釈）	31秒
CLispの解釈	196秒
コンパイルされたCLisp	80秒

CLispインタープリターは現在6倍以上遅くなっていますが、驚いたことに、コンパイルされたコードでさえPico Lispより2.58倍遅いです。



たぶんCLispは遅いコンパイラを持っていますか？ そしておそらく、コードはいくつかのトリックで高速化できるでしょう。 しかし、これらの結果は、コンパイルのオーバーヘッドを正当化できるかどうかについて、まだ多くの疑問を残しています。 コンパイラーの最適化をいじるのは、アプリケーションのロジックに関して、そしてユーザーがまだ遅延に気付いていないとき、私が最後にやりたいことです。

2.2。 神話2：Lispには多くのデータ型が必要

上記の例で説明したフィボナッチ関数は、変数Nを整数として宣言することで高速化できます。 ただし、この例では、コンパイラサポート要件がLispにどの程度影響するかを示します。 データ型がハードコーディングされている場合、コンパイラはより効率的なコードを生成できます。 Common Lispは、リストに加えて、さまざまな整数型、固定/浮動小数点型、小数、文字、文字列、構造、ハッシュテーブル、ベクトル型など、多くの異なるデータ型をサポートしています。



一方、Pico Lispは3つの組み込みデータ型（数字、文字、リスト）のみをサポートし、これらの型でも問題なく機能します。 Lispシステムは、実行時にチェックする必要のあるオプションが少ないため、少ないデータ型でより高速に動作します。 これによりメモリの使用効率が低下する可能性がありますが、タグに必要なビットが少ないため、タイプの数を少なくするとスペースを節約できます。



3つのデータタイプすべてを使用する主な理由はシンプルさであり、シンプルさの利点は速度とメモリ補正の利点を上回ります。



実際、最下位レベルのPico Lispは、数字、文字、およびリストを形成するために使用されるセルの1つのデータ型のみを使用します。 小さい数字または最小文字は、1つのメモリ位置のみを占有し、必要に応じて動的に増加します。 このメモリモデルにより、効率的なガベージコレクションが可能になり、フラグメンテーションが完全に回避されます（たとえば、ベクターの場合）。



最高レベルでは、これら3つのプリミティブデータ型を使用して、他のデータ型をいつでもエミュレートできます。 そのため、リスト、文字列、クラス、およびシンボルを使用するオブジェクトを使用してツリーをエミュレートします。 パフォーマンスの問題はありませんが、なぜ複雑なのですか？

2.3。 神話3：動的リンクは悪い

Pico Lispは、動的な表面バインディングの単純な実装を使用します。 シンボルの値を格納するセルの内容は、ラムダ式またはバインディング環境に入るときに保存され、新しい値が設定されます。 戻ると、元の値が復元されます。 その結果、シンボルの現在の値は、レキシカル環境の静的チェックからではなく、履歴と実行ステータスから動的に決定されます。



おそらく、解釈されたシステムにとって、これは最も単純で最速の戦略です。 セル値を検索するには、検索は不要で（セル値へのアクセスのみが必要です）、すべての文字（ローカルまたはグローバル）は同じ方法で処理されます。 一方、コンパイラは字句バインディングのより効率的なコードを生成できるため、コンパイルされたLispコードは通常、いくつかのタイプのバインディング戦略をサポートすることで事態を複雑にします。



動的リンクは非常に強力なメカニズムです。 現在の値にはどこからでもアクセスできます。変数自体とその値は常に物理的に存在する「本物」であり、「見かけ」のものではありません（字句バインディングの場合や、ある程度は通過文字を使用します） Pico Lisp（下記参照））。



残念ながら、大きなリスクなくして大きなチャンスはありません。 プログラマーは、それらを利用して落とし穴を回避するために、基本原則に精通している必要があります。 ただし、Pico Lispが推奨する規則に従う限り、リスクは最小限に抑えられます。



動的リンクを使用した計算の結果がプログラマーの制御から外れる状況には、次の2つのタイプがあります。

1. シンボルはそれ自体と接続されており、シンボルの意味を変更しようとしています。
2. 現在のソースコードの環境では見えないパススルーコードによってシンボルの値が動的に変更される場合のfunarg（関数引数）の問題。

このような状況は、中継記号を使用することで回避できます。



移行文字とは、Pico Lispの文字列のように見える（文字列として使用されることが多い）文字であり、ソースコード（またはその一部のみ）を含む単一ファイルの期間だけ一時的にインターンされます。 したがって、Cプログラムの静的識別子に匹敵する字句能力を持ち、他のすべての点で通常の文字であるため、動作のみが完全に動的です。



したがって、ルールは単純です。関数が渡された変数の値を変更したり、渡されたLisp式の結果を（直接的または間接的に）計算する必要がある場合は常に、この関数のパラメーターを通過文字を使用して記述する必要があります。 実際の経験では、このようなケースは高レベルのソフトウェア開発プロセスではまれであり、主に補助ライブラリとシステムツールで発生することが示されています。

2.4。 神話4：プロパティリストが悪い

プロパティは、値/関数セルに加えて情報をシンボルに関連付けるためのエレガントでわかりやすい方法です。 データの量とタイプが静的に固定されていないため、非常に柔軟です。



多くの人は、プロパティリストは時代遅れで原始的であり、現代では使用できないと考えているようです。 代わりに、より高度なデータ構造を使用する必要があります。 これは場合によっては当てはまりますが、シンボル内のプロパティの総数によっては、回収のしきい値が予想よりも高くなる場合があります。



Pico Lispの以前のバージョンは、プロパティを保存するためにハッシュテーブルと自己バランスバイナリツリーを試しましたが、通常のリストがより効率的であることがわかりました。 システム全体の全体的な効果を考慮する必要があり、多数の内部データ構造（上記を参照）とより複雑な検索アルゴリズムの両方をサポートするためのオーバーヘッドは、単純な線形検索を使用するよりも大きくなることがよくあります。 また、メモリ効率の問題についても触れると、プロパティリストの利点が明らかに勝っています。



Pico Lispはプロパティをキーと値のペアのリストとして実装します。 速度の最適化を支持する唯一の譲歩は、「最近使用した」スキームです。これは、繰り返しアクセスを少し高速化しますが、これが実際に必要だったという具体的な兆候はありません。

プロパティに対するもう1つの引数は、宣言されたグローバルな可視性です。 これは、C構造体のグローバル要素またはJavaオブジェクトのインスタンス変数と同じ程度に当てはまります。



もちろん、グローバルシンボルでは、プロパティもグローバルですが、一般的なアプリケーション開発では、プロパティは匿名の文字、オブジェクト、または明確に定義されたコンテキストでのみ使用可能なデータベース要素に格納されます。 したがって、プロパティ「色」は、ある意味ではある意味で、別の意味ではまったく異なる意味で、相互干渉なしに使用できます。

3.アプリケーションサーバー

この単純なPico Lispマシンに基づいて、垂直構造のアプリケーションサーバーを開発しました。 データベースエンジン（PicoLispの永続（永続）オブジェクトのファーストクラスデータ型としての実装に基づく）と抽象グラフィカルインターフェイス（HTMLやJavaアプレットなどの生成）を統合します。



この統合システムの重要な要素は、個々のアプリケーションモジュールの実装に使用されるLispベースのマークアップ言語です。



データベース、ドキュメント、レポート、またはその他のサービスからの新しいビューがアプリケーションサーバーから要求されるたびに、Lispソースファイルがダウンロードされ、その場で実行されます。 これは、従来のWebサーバーでHTMLファイルを送信するURLリクエストに似ています。



しかし、このようなシナリオで評価されるLisp式には、通常、インタラクティブなユーザーインターフェースを構築して処理するという副作用があります。



これらのLisp式は、GUIコンポーネントの構造、ユーザーアクションに応じた動作、およびデータベースオブジェクトとの相互作用を記述します。 つまり、ソフトウェアモジュールの完全な説明が含まれています。 これを可能にするには、ローカリティの原則を厳守し、プレフィックスクラスとリンクサポートデーモンのメカニズムを使用することが重要であることがわかりました（最後の2つは別のドキュメントで説明されています ）。

3.1。 局所性の原理

先ほど述べたように、ビジネスアプリケーションの開発は絶えず変化するプロセスです。 Localityの原則は、このようなプロジェクトの開発に非常に役立ちました。 この原則では、1つのモジュールに関するすべての情報をこのモジュールとともに1か所に保存する必要があります。 これにより、プログラマはこれらすべてが保存されている1つの場所のみに集中できます。



もちろん、これはすべて明白なように見えますが、対照的に、ソフトウェア開発の方法論では、動作とデータをカプセル化し、それらをアプリケーションの他の部分から隠す必要があります。 通常、これにより、アプリケーションロジックは1か所（ソースファイル）に記述されますが、このロジックを実装するための関数、クラス、およびメソッドは他の場所で定義されます。 もちろん、これは良い推奨事項ですが、多くの問題をもたらします。これは、さまざまな場所に絶えず移動する必要があることから明らかです。複数の場所で同時に変更とコンテキストの切り替えが発生します。 関数が非推奨になった場合、一部のモジュールも期限切れになる可能性がありますが、削除するのを忘れています。



したがって、関数、クラス、およびメソッドの抽象的なライブラリの作成は普遍的であると信じています-可能な限り普遍的で、一定の時間とさまざまなアプリケーションであり、アプリケーションを作成するための高度な表現力を持つ厳格なマークアップ言語を構築するために使用されます。



この言語にはコンパクトな構文が必要であり、アプリケーションのすべての静的および動的な側面を記述することができます。 ローカルに、1つの場所で。 別のファイルで動作を定義する必要はありません。

3.2。 Lisp

そして、これが最初からLispが私たちに合った唯一の言語であると主張した主な理由です。



Lispだけが同じ方法でコードとデータを処理できます。これがPico Lispアプリケーション開発モデルの基礎です。 静的データと自由に混合され、実行時にどこかに転送されるか、内部データ構造に保存されるファンクションブロックと計算式を集中的に使用できます。



私たちが知る限り、他の言語では、少なくとも同じ単純さと優雅さでこれは不可能です。 ある程度まで、スクリプト言語を使用して、テキストの解釈された行を使用してこれを行うことができますが、この解決策は非常に限定的で厄介です。 そして、上で説明したように、コンパイルされたLispシステムは重すぎて柔軟性に欠ける場合があります。 これらすべてのデータ構造とコードフラグメントがシームレスに機能するためには、環境設定をバインドする必要なく式を評価できるため、動的なサーフェスバインド戦略が大きな利点です。



もう1つの理由は、Lispを使用すると、文字やネストされたリストなどの複雑なデータ構造を、明示的に宣言、割り当て、初期化、またはメモリから解放することなく直接操作できるためです。 これは、コードのコンパクトさと読みやすさに貢献し、プログラマーに強力な式ツールを提供します。これにより、他の言語で別のモジュールが必要な場合に、1行でさまざまなことを実行できます。



すべてに加えて、Pico Lispはデータベースオブジェクトと内部文字を正式に区別しないため、これらの利点はすべてデータベースの操作にも適用され、同じコードを使用して同じローカルコンテキストでGUIとデータベース操作を直接通信できます。

4.結論

Lispコミュニティは、「非効率的な」Lispの妄想に苦しんでいるようです。 これはおそらく、数十年にわたって「Lispが遅い」「Lispが肥大化している」という主張から自分たちの言語を守ることを余儀なくされたという事実によるものです。



これは部分的に真実でした。 しかし、今日のハードウェアでは、実行速度は多くの実用的なアプリケーションにとって重要ではありません。 そして、そのような場合、Cでいくつかの重要な関数をエンコードすると、通常この問題が解決します。



次に、より実用的な側面に焦点を当てましょう。 「古代の」Lispシステムがどれほどコンパクトで高速であるかに驚くかもしれません。 したがって、Lispを実際に「肥大化」させないように注意し、言語のコアをますます多くの機能で過負荷にする必要がありますが、プログラマに完全な柔軟性を提供する単純なソリューションを使用することを決定する必要があります。



Pico Lispは、「Less can more」の概念の証明と見ることができます。