今日、多くのシステムとプログラミング言語は「強力」と位置付けられています。 これは、これが悪いと言うことではありません。 私たちのほぼ全員がこれを前向きな機能だと考えています。 しかし、この投稿では、多くの場合、 それほど強力ではないプログラミング言語とシステムが必要になるという観点を伝えたいと思います。 しかし、続行する前に、明確にするつもりです。オリジナルの、私自身の考えはほとんどありません。 ダグラス・ホフスタッターの本、ゴッデル、エッシャー、バッハを読んだ後に生まれた一連の思考の概要を説明します。 また、フィリップワドラーの投稿と Scala会議のビデオは、以下に示す資料に大きな影響を与えました。 重要な考えはこれです：



表現力が高まるたびに、メッセージを理解したいすべての人に追加の負担がかかります。



そして、Pythonコミュニティにより近く明確になる例でこの点を説明したいと思います。



定義に関するいくつかの言葉。 多かれ少なかれ強力なプログラミング言語とはどういう意味ですか？ 投稿のフレームワーク内では、これはおおよそ次のように説明できます。コードを書いたり、システムにデータを入力したりする人の観点からは、「自由と、好きなことをする能力」。 これは正式な定義ではありませんが、「表現力」の概念とほぼ相関しています。 より正確には、多くの言語はチューリング完全性に関して同じレベルの表現力を持っています。 しかし、開発者は、より少ないコードで、またはいくつかの異なる方法で特定の結果を得ることができ、より多くの自由が得られるため、それらのいくつかをより強力なものとして選びます。



しかし、この自由度はそれほど単純ではありません。 任意の言語を使用するときに主張する「力」の各ビットは、誰かがあなたが書いたものを「消費する」ときに提供しなければならないリターンに等しい。 以下は正式にプログラミングに関連する例ですが、同時に魂の反応を見つけます。



誰かが尋ねます：「それでも問題ですか？」もちろん、あなたのシステムの結果を「消費する」ことができる範囲で。 ソフトウェアコンシューマ、コンパイラ、および開発者向けのその他のツールは「コンシューマ」として機能するため、ほとんどの場合、製品のパフォーマンスと正確さだけでなく、人も気にします。

データベースとスキーマ

「表現力」スケールの下位レベルは、プログラミング言語ではなくデータに起因するものです。 ただし、データと言語の両方が「誰かからのメッセージを受信する」と認識される必要があるため、ここでも同じアプローチが適用されます。



何年もの間、私はしばしば、あらゆる形式でテキストを入力するためのフィールドを作るように頼まれました。 エンドユーザーの観点からすると、このようなフィールドは最高レベルの「パワー」を体現しています。何でも入力できるからです。 そして、このロジックの枠組みの中で、そのようなフィールドは「最も役立つ」ものです。



しかし、フィールドにテキストを入力できるため、それは構造化にあまり役立たないので、最も役に立ちません。 そのようなフィールドでの検索でさえ、確実に機能しません-タイプミスの可能性と、いくつかのことを説明するさまざまな方法のためです。 データベースでの作業時間が長くなればなるほど、可能なすべてを厳密に規制したいという欲求が強くなります。 そして、私がこれをなんとかするとき、得られたデータからより多くの利益を引き出すことができます。 つまり、システムにデータを入力するソースの「パワー」（つまり自由）を制限すればするほど、このデータを「消費」する機会が増えます。



同じことがデータベース技術にも言えます。 非構造化（スキーマレス）データベースは、データ入力に十分な機会と柔軟性を提供し、その出力ではより役に立ちません。 Key-Valueストレージは「自由形式のテキスト」に似ていますが、同じ欠点があります。情報を抽出したり、データで何かをしたい場合にはほとんど役に立ちません。次に特定のキー。

HTML

一部には、Webの成功は、主要な技術であるHTMLとCSSの機能の意図的な制限によるものでした。 はい、これらはマークアップ言語であり、プログラミング言語ではありませんが、偶然ではありませんでした。 それは意識的に選ばれた概念であり、その創設者の一人はティム・バーナーズ・リーでした。 「1960年代から1980年代にかけて、コンピューターサイエンスはますます強力なプログラミング言語を作成するために多くの努力をしました。 しかし、今日では、それほど強力でないツールを選択する必要がある理由があります。 それらの1つは、言語が「弱い」ほど、保存されているデータを使用してより多くのことができるということです。 単純な宣言フォームを作成すると、誰でもこのフォームをさまざまな方法で分析するプログラムを作成できます。 一般的な意味で、セマンティックネットワークは、作成者が夢にも思わなかったこのようなデータ分析の機会を得るために、大量のデータを通常の言語に変換する試みです。



たとえば、WebページでRDFを使用して天気予報を表示する場合、ユーザーはこのデータを表に抽出し、何らかの方法で処理、平均化、グラフをプロットし、他の情報と比較できます。 これをJavaアプレットと比較してください。情報は非常に美しく表示できますが、分析することはできません。 検索ボットは、ページに表示される内容を理解しません。 Javaアプレットが何をするかを知る唯一の方法は、画面の前に座っている人の前で実行することです。



W3Cコンソーシアムは同じ立場を取りました： 「グッドプラクティス：World Wide Webで情報、リンク、またはアプリケーションを表現するのに適した最も強力でない言語を使用します 。 」



これは、 Paul Grahamのアドバイスにほぼ完全に反しています（「権力」の定義は多くの場合、形式的とは程遠いものであるという点に注意してください）。

MANIFEST.in形式のファイル

「実際の」プログラミング言語に移りましょう。 例として、distutilsおよびsetuptoolsツールで使用されるMANIFEST.inファイル形式を選択しました。 Pythonライブラリ用のパッケージを作成したことがある場合は、おそらくこの形式に精通しているでしょう。



実際、これはPythonのパッケージに含めるファイルを記述する非常に小さな言語です（作業ディレクトリから呼び出されるMANIFEST.inファイルに関連）。 例：

include README.rst recursive-include foo *.py recursive-include tests * global-exclude *~ global-exclude *.pyc prune .DS_Store
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ディレクティブには2つのタイプがあります。

• include（include、recursive-include、global-include、graft）
• exclude（exclude、recursive-exclude、global-exclude、prune）

疑問が生じます。これらの指令はどのように解釈されますか？ つまり、それらのセマンティクスは何ですか？

「 作業ディレクトリ（またはサブディレクトリ）からのファイルは、少なくとも1つのincludeタイプのディレクティブに一致し、excludeタイプのディレクティブに一致しない場合、パッケージに含める必要があります。」



この言語は宣言的であるようです。 残念ながら、そうではありません。 distutilsのドキュメントには、MANIFEST.inについて記述されています-ディレクティブは次のように理解する必要があります。

1. パッケージに含まれるファイルの空のリストから始めます。 より正確には、デフォルトのリストから始めます。
2. 順序に従って MANIFEST.inの指示に従います。
3. タイプがincludeの各ディレクティブについて、関連するすべてのファイルを作業ディレクトリからパッケージリストにコピーします。
4. 除外ディレクティブごとに、対応するすべてのファイルをパッケージリストから削除します。

この例は、この言語の命令的な性質を示しています。MANIFEST.inの各行は、そのアクションが副作用の存在を示唆するチームです。 これにより、上記の疑似宣言バージョンよりも言語が強力になります。 例を考えてみましょう：

 recursive-include foo * recursive-exclude foo/bar * recursive-include foo *.png
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これらのコマンドのリストの結果、pngファイル（foo / barの下）がパッケージに含まれています。 また、foo / barの上のすべてがパッケージに含まれているわけではありません。 宣言型言語を使用して同じ結果を達成することは、たとえば次のようにより困難です。

 recursive-include foo * recursive-exclude foo/bar *.txt *.rst *.gif *.jpeg *.py ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

命令型言語はより強力なので、それを選択する誘惑があります。 ただし、命令型にはいくつかの重要な欠点があります。

1. 最適化の難しさ 。 MANIFEST.inを解釈し、パッケージに含めるファイルのリストを作成する場合、有効なソリューションは1つだけです。最初に、ディレクトリとサブディレクトリ内のすべてのファイルの変更不可能なリストを作成し、次にルールを適用します。 追加の規則に従ってファイルを出力リストにコピーし、除外の規則に従ってファイルからファイルを削除します。 このアプローチは現在Pythonで実装されています。
   
   
   
   ファイルが比較的少ない場合、これは有効なオプションです。 また、リストが数千のアイテムで構成されている場合、そのほとんどをパッケージから除外する必要があるため、最終的なリストの作成には多くの時間がかかります。
   
   
   
   この問題の解決策は明白なようです。一部のディレクティブによって除外されるディレクトリには移動しないでください。 ただし、これは、除外ディレクティブがすべての包含ディレクティブに続く場合にのみ可能です。
   
   
   
   この問題は理論的なものではありません。 作業ディレクトリ内のファイルの数が多いため、たとえばtoxツールを使用する場合、setup.py sdistおよびその他のコマンドを実行すると10分に達することがあります。 つまり、tox自体（setup.pyを使用）の動作は非常に遅くなります。 今、 私はこの問題を解決しようとしていますが、これを行うのは非常に難しいと思います。
   
   
   
   一見すると、最適化を行うことは可能です（すべてのディレクティブを追加した後に排他的なディレクティブを実行することにより、ファイルシステムをそれほど集中的に使用しません）が、これはすべてを著しく複雑にし、パッチは受け入れられそうにありません。 コードブランチの数が増えるため、多数のエラーが発生する可能性が高くなります。
   
   
   
   おそらく唯一受け入れられる解決策は、MANIFEST.inの使用を完全に放棄し、完全に空の場合にのみ最適化することです。
2. 「パワー」の裏側：MANIFEST.inファイルは理解しにくい。 まず第一に、言語の原則を習得することはより困難です。 装飾版の場合、ドキュメントは実際よりもはるかに短くなります。
   
   
   
   さらに、特定のMANIFEST.inを分析するときは、結果を表示しようとして精神的にコマンドを実行する必要があります。 都合の良い順序で行を配置する方がはるかに簡単です。
   
   
   
   これはすべて、パッケージの作成時にエラーにつながります。 たとえば、MANIFEST.inの先頭にあるglobal-exclude *〜ディレクティブは、名前が〜（一部のエディターの一時ファイル）で終わるすべてのファイルがパッケージから除外されることを意味します。 実際、このディレクティブは何もしません。 そして、以下のディレクティブのいずれかがパッケージにいくつかのファイルを含めようとすると、それらは誤って含まれます。 このエラーの次の例を見つけました（意図したとおりに動作しないディレクティブを除外します）。
   
   
   • hgview （ファイルの最初に配置した場合、機能しません）;
   • django-mailer （ファイルの先頭の壊れたグローバル除外ディレクティブ）。
3. 文字列の順序を変更するとパッケージの構成に影響するため、認識しやすくするためにMANIFEST.inで文字列をグループ化することはできません。

ルーティング

ルーティングはDjangoのコアコンポーネントの1つです。 これは、URLを解析し、指定されたURLのハンドラーに渡すコンポーネントです。 同時に、おそらく、URLからいくつかのコンポーネントを抽出します。



Djangoでは、これは正規表現を使用して実装されます。 子猫に関する情報を表示するアプリケーションがあり、子猫/ urls.pyファイルに次のコードが含まれているとします。

 from django.conf.urls import url from kittens import views urlpatterns = [ url(r'^kittens/$', views.list_kittens, name="kittens_list_kittens"), url(r'^kittens/(?P<id>\d+)/$', views.show_kitten, name="kittens_show_kitten"), ] ,  views.py  : def list_kittens(request): # ... def show_kitten(request, id=None): # ...
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

正規表現には、ビュー関数に渡されるパラメーターを取得するために使用される組み込みのキャプチャ関数があります。 cuteness.comでアプリケーションを動作させます。 次に、アドレスwww.cuteness.com/kittens/23がshow_kittenコードへの呼び出しを開始します（リクエスト、id = "23"）。



URLを特定の機能にルーティングできるようになったため、Webアプリケーションはほとんど常にこれらの同じURLを生成するように強制されます。 子猫のリストがあるページに、個人ページへのリンクを含める必要があるとします：show_kitten。 そして確かに、URLルーティング構成を再利用することでこれを行うことができます。



ただし、逆方向に使用します。 URLルーティングを実行する場合、次の手順を実行します。

 URL path -> (handler function, arguments)
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

生成するとき、ハンドラー関数と必要な引数を知っています。 そして、URLルーティングを完了した後 、ユーザーを目的のページに導くURLを作成する必要があります。

 (handler function, arguments) -> URL path
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

これを行うには、ルーティングメカニズムの動作を予測できる必要があります。 「今週末のインプットはどうなるのか」と尋ねます。Djangoの歴史のごく初期には、まだそのような機能はありませんでした。 しかし、ほとんどの場合、URLテンプレートの「方向を変更」できることがわかりました。 静的およびキャプチャされた要素を見つけるために、正規表現を解析できます。



URLルートの定義に使用される言語-正規表現-には特定の制限があるため、これが可能であることに注意してください。 これにはもっと強力な言語を使用できますが。 たとえば、次の機能を使用してURLを定義します。

• 入力としてURLを使用する
• 不一致の問題の場合、NoMatch。
• 偶然、それらは切り捨てられたURLとキャプチャされたパラメータのセットを返します。

urls.pyは次のようになります。

 from django.conf.urls import url, NoMatch def match_kitten(path): KITTEN = 'kitten/' if path.startswith(KITTEN): return path[len(KITTEN):], {} raise NoMatch() def capture_id(path): part = path.split('/')[0] try: id = int(part) except ValueError: raise NoMatch() return path[len(part)+1:], {'id': id} urlpatterns = [ url([match_kitten], views.list_kittens, name='kittens_list_kittens'), url([match_kitten, capture_id], views.show_kitten, name="kittens_show_kitten"), ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

もちろん、match_kittenとcapture_idをより簡潔にすることもできます。

 from django.conf.urls import url, m, c urlpatterns = [ url([m('kitten/'), views.list_kittens, name='kittens_list_kittens'), url([m('kitten/'), c(int)], views.show_kitten, name="kittens_show_kitten"), ]
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

mとcが関数を返すことを考えると、この言語は正規表現に基づいて、実際よりもURLをルーティングするためにより強力であることが判明しました。 一致を検出してキャプチャするためのインターフェイスには、より多くの機能があります。たとえば、データベースなどでIDを検索できます。



しかし、この蜂蜜の樽にはタールも含まれています。URLを逆にすることはできません。 チューリング完全言語では、「そのような出力での入力データはどうなりますか？」と尋ねることはできません。理論的には、既知のパターンを検索するために関数のソースコードを表示できますが、これは完全に非現実的です。



また、機能が制限されている正規表現では、より多くのオプションを使用できます。 一般に、単純な式は一種なので、通常ベースのURL構成は逆になりません。 （ドットのみ）を独自の方法で元に戻すことはできません。 また、従来のURLを通常どおり生成する場合は、独自のソリューションが必要です。 もしそうなら。 それでも遭遇すると、Djangoは別の文字を任意に選択し、他のワイルドカードはそのように処理されません。 しかし、そのような文字はキャプチャされた文字の中だけで見つかるため、正規表現を逆にすることは非常に可能です。



したがって、URLルートを確実に逆引きする場合は、正規表現よりも強力でないものが必要になります。 かつては、それらが十分に強力であり 、その機能が冗長であることを認識していなかったために選択されました。



とりわけ、Pythonでは、そのようなタスク用のミニ言語を定義するのはそれほど簡単ではありません。 それらの実装と使用には、かなりの数のボイラープレートと詳細レベルが必要になります-正規表現のような「文字列」言語を使用する場合よりもはるかに多くなります。 ところで、Haskellのような言語では、代数的データ型の定義やパターンのマッチングのようなかなり単純な機能のおかげで、そのようなことははるかに簡単になります。

正規表現

前の章では、別の問題を思い出しました。 ほとんどの場合、正規表現の使用は非常に簡単です。 ただし、レギュラーシーズンに電話をかけると、必要かどうかに関係なく、すべての可能性がすぐに利用可能になります。 場合によっては、可能性のあるすべての一致を見つけるためにバックトラッキングを行う必要があります。 そして、それは、正規表現によって非常に長く処理される文字の組み合わせを意図的に作成できることを意味します。



ちなみに、これによりクラス全体のDoS脆弱性が発生し 、そのうちの1つがDjango- CVE-2015-5145で発見されました 。

テンプレート：Django vs Jinja

Jinjaテンプレートエンジンの作成者は、 Djangoテンプレート言語に触発されましたが、その哲学と構文を多少変更しました。



パフォーマンスは、Jinja2の主な利点の1つです。 ここでは、Pythonコードは、Djangoで行われているように、Pythonで作成されたインタープリターを実行するのではなく、すぐにコンパイルされます。これにより、パフォーマンスが5〜20倍向上します。



Jinjaの作者であるArmin Ronacherは、同じアプローチを使用してDjangoテンプレートのレンダリングを高速化しました。 このプロジェクトを提供して、彼はDjangoのAPI拡張機能がJinjaで実装されたアプローチを実装することを非常に難しくすることを知っていました。 Djangoでは、独自のテンプレートタグを使用できます。これにより、コンパイルとレンダリングの段階をほぼ完全に制御できます。 特に、 django-sekizaiではaddtoblockなどの強力なタグを使用できますが、一見するとこれは不可能に思えます。 しかし、そのような場合（まれに）より遅いバージョンが使用されたとしても、迅速な実装の利点があります。



多くのパターンに影響する別の重要な違いがありました。 Djangoでは、テンプレートのレンダリングプロセス中に、転送されたコンテキストオブジェクト（テンプレートに必要なデータを含む）を上書きできます。 テンプレートタグはコンテキストを設定できますが、それらのいくつか（たとえば、url）はまさにそれを行います。



これにより、Jinjaの例に従って、 Pythonでのコンパイルの大部分を Djangoに実装できました。



これらの両方のケースで、問題はDjangoエンジンのパワーであることに注意してください-コード作成者がJinja2では不可能なことを行うことができます。 その結果、高速コードをコンパイルしようとすると非常に大きな困難に直面します。



場合によってはテンプレートのレンダリング速度がプロジェクトの主な問題になる可能性があるため、これは非常に重要なポイントです。 このため、 多くの製品がJinjaに移行されました。 そして、これは不健康な状況です！



多くの場合、後知恵でのみ、最適化が困難になる原因を正確に理解することができます。 そして、言語にいくつかの制限を導入することは必然的に最適化プロセスの促進を必要とすると言うのはcです。 プログラマーと消費者向けの限られた機能の概念が非常にうまく実装されている言語があります！



Pythonのデータ構造はデフォルトで変更可能であるため、コンテキストオブジェクトを書き換え可能にすることは論理的であると言えます。 Python自体に私たちをもたらします...

Python

この言語の可能性の幅とは異なる方法で関連付けることができます。 たとえば、これがPythonコードに遭遇するすべての開発者とプログラムの生活をどれほど複雑にしているのか。



まず、コンパイルとパフォーマンスが頭に浮かびます。 制限がほとんど完全に存在しないため、特にクラスやモジュールの書き換えが可能になり、あらゆる種類の有用なことを実行できるだけでなく、パフォーマンスが大幅に低下します。 PyPyの作者は素晴らしい結果を達成することができましたが、このダイナミクスから判断すると、将来的に大きな成長を達成する可能性は低いです。 また、利用可能なパフォーマンスの向上は、メモリ消費の増加を犠牲にして達成されました。 Pythonコードを最適化できるのは特定の制限のみです。



この意見がある場合：PythonやDjangoにはまったく反対していません。 私はDjangoの主要な開発者の1人であり、ほとんどすべてのプロフェッショナルプロジェクトでDjangoとPythonを使用しています。 この投稿では、プログラミング言語の幅広い可能性によって生じる問題を説明したいと思います。



次に、リファクタリングとコードサポートについて説明します。 真面目なプロジェクトを作成する場合、確かに多くの時間がサポートに費やされます。 そして、これを迅速かつ最小限のエラーで行えることが非常に重要です。



同じPythonで、VCS（GitやMercurialなど）を使用しているときに、10行の関数を別の場所に移動すると、プログラム自体の観点から何も変わっていないにもかかわらず、20行の差分が得られます。 それにもかかわらず何かが変更された場合（機能が移動されただけでなく、変更された場合）、決定するのは非常に困難です。



毎回、これに直面すると、複雑さが生じます。なぜ、複雑な構造のコードを一連のプレーンテキストとして扱うのでしょうか。 これはある種の狂気です！



この問題は、 高度なdiff-toolsの助けを借りて解決できると思われるでしょう。 しかし問題は、Pythonで関数のシーケンスを変更すると、プログラムに実際に影響する可能性があることです（実行時に発生する変更を意味します）。



以下に例を示します。 以前に定義した関数をデフォルト引数として使用します。

 def foo(): pass def bar(a, callback=foo): pass
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

行の順序を変更すると、barの定義のfooについて、NameErrorエラーが発生します。

デコレータを使用します：

 @decorateit def foo(): pass @decorateit def bar(): pass
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

@decorateitで考えられる効果のため、これらの関数の順序を変更することはできず、プログラムが同じように機能することを確認してください。 関数の引数リストのコードを呼び出すことについても同じことが言えます。

 def foo(x=Something()): pass def bar(x=Something()): pass
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

クラス属性もスワップできません：

 class Foo(): a = Bar() b = Bar()
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

ここでは、Barコンストラクターで考えられる効果のため、bの定義はaの上に配置されています。 これは理論化のように思えるかもしれませんが、同じDjangoは、ModelフィールドとForm定義内で実際に使用して、基本フィールドコンストラクター内のトリッキーなクラスレベルカウンターを使用して、標準フィールド順序を確保します



Pythonでは、関数式のシーケンスはアクションのシーケンスであり、その結果としてオブジェクト（関数と引数）が作成され、いくつかのアクションがそれらで実行されるなどの事実に耐える必要があります 他の言語とは異なり、宣言の順序を変更することはできません。



これにより、コードを記述する際に最も幅広い可能性が得られますが、既成のコードを使用した操作の自動化に関しては好転できません。 リファクタリングは、言語の機能（「 ダックタイピング 」など）によって名前を変更できないため、恐れることなく実行することはほとんど不可能です。 また、「リフレクション」と属性（getattrなど）への動的アクセスの可能性があるため、通常は自動的に安全に名前を変更することはできません。



そのため、すべてのトラブルについてVCSやリファクタリングツールを非難しないでください。 それはすべて、Python自体の可能性の幅に関するものです。 コード内の構造の数が膨大であるにもかかわらず、あらゆる種類の操作に関してそれらを使用して行うことはほとんどできません。 そのため、詳細に調べてみると、行の順序に対するdiffの依存性はそれほど悪くはなりません。



今日では、コード内の定義の順序が重要になるため、デコレータをほとんど使用していません。これにより、消費者の生活が多少楽になります。 しかし、まれに、私たちのツールはまだ実用的ではありません。 一部の消費者にとっては、特定の標準的な状況を考慮して最適化を実行し、たとえばJITチェックを使用して障害を検出することができます。 しかし、他のツール（たとえば、VCSやリファクタリングツール）では、障害が発生した場合、実装に関する情報を収集するには遅すぎます。 問題を発見した時点では、すでに「破損した」コードをリリースしている可能性があるため、後で謝るよりも注意する方が良いでしょう。



理想的な言語では、VCSでdiff関数の名前を変更すると、「関数fooの名前がbarに変更されました」のようになります。 — , foo bar. « » . - Python .



, , . .



, , , . , , — . — . . , , (, ), .



, , VCS, . Lamdu , .

まとめ

( ), , : , , . , Slavery is freedom. , , .



, , , . , , VCS .



, .



, , . — , .



, , . , .