Geekly Articles each Day

2015年の一般的なLispエコシステムのステータス

翻訳者から：
Common Lispには80年代のライブラリはなく、他にもライブラリがないことをよく耳にしました。そのユーザーの多くは、DARPAカタコンベで人工知能に取り組んでおり、普通のプログラマーの日常のタスクをよく理解していない3.5人の教授です。 この記事は、古いライブラリに出くわすことはできますが、最新のアナログのみを使用する必要があること、既存のライブラリが開発中であり、新しいライブラリが常に登場していることを示しています。

この記事の著者であるFernando Borrettiは、Common Lispエコシステムへの積極的な貢献者であり、30以上のライブラリの著者であり、そのほとんどはWeb開発用です。

合格した読者はCommon Lispの状況に関する一般的なアイデアを得ることができ、興味のある人はコードを書くために必要なものと、試行タスクに必要なライブラリを理解でき、経験豊富な開発者は最新の開発について学び、コミュニティを支援できるライブラリを理解します初心者の質問に答える方法に関するヒントを入手して、このすばらしいテクノロジーへの関心を殺さないようにします。 行こう！



ユーザーと貢献者の観点から2015年8月のCommon Lispエコシステムについて説明します。

この記事の目的は、エコシステムの概要を提供し、各エリアでの統一を支援することです。

各アプリケーション領域について、エコシステムのこの部分を統合するための推奨事項と、将来の開発のための興味深い方向性が示されています。

アプリケーション開発



ウェブ開発



バックエンド



WSGI / Rackの類似物であるClackは、2009年から存在しており、十分にテストされており、本番環境で動作します。 3つのWebフレームワーク-Caveman2 、 Ningle 、およびLucerneはこれに基づいています。

Clackは、特定のサーバー実装に縛られることなく、ユーザーがWebフレームワーク（またはより優れたWebアプリケーションフレームワーク）を作成できるようにするHTTPサーバーの抽象化です。

Clackを使用することの重要性を過小評価することはできません。たとえば、Hunchentootなどのアプリケーションを直接ビルドする場合、Hunchentootに関連付けられます。Wooなどの新しい高速サーバーが表示される場合は、アプリケーション全体を書き換えて使用する必要があります。 Clackのプラグイン（ clack-errorsなど）を作成すると、Clackで作成されたフレームワークに関係なく、すべてのアプリケーションで自動的に使用できるため、無駄なコードの重複が減少します。

Clackを使用すると、HunchentootからWooへの切り替えと驚異的な加速の喜びは、 libevをインストールして1つの重要な引数を変更するだけのことです。

結論：

Hunchentootの直接使用を停止します 。 フレームワークの1つであるClackを使用します。

今後の作業：
主要部分は終了しました。今度は高レベルのものを作成します。 Djangoのように、Clackアプリケーションの拡張可能な管理フレームワークが良い例です。

フロントエンド



すべては、JavaScriptでコンパイルするCommon Lispの機能に関連しています。 Common Lispはかなり大きな言語ですが、いくつかのオプションがあります。



結論：

統合する最善の方法は、既存のCL-in-JS実装の1つを開発することです。

今後の作業：

CFFIに似ていますが、CL-in-JSの実装用であるため、ライブラリの新しいバージョンがリリースされたときにJavaScriptライブラリへのバインディングを書き換える必要はありません。

JavaScriptでCommon Lispをコンパイルするユーティリティは実装に依存せず、ParenscriptからJSCLまたは他の実装への移行を容易にします。

コマンドライン



長年にわたり、さまざまなユーティリティがこの分野に登場しましたが、その最後の、最大の衝動を受けたもの- ロズウェル -マネージャー/インストーラーおよびスクリプトランチャーの実装です。 その優れた機能の1つは、たとえばドキュメントを生成するために、小さなスクリプトを実行可能ファイルに簡単にコンパイルできることです。

また、 cl- travisのいくつかの問題を回避するためにTravisに実装（CL）をインストールするためにも使用されます。

結論：

cl-launchを終了し、 Roswellを使用します。

今後の作業：

その他のロズウェルスクリプト。

GUI



長い間、大きな懸念は完全なGUIソリューションの欠如でした。 これでCommonQtとQtoolsができました 。 1つ目は実際のアプリケーションで長年使用され、2つ目はそれを簡単にするレイヤーです。

CommonQtを使用する際の最大の問題は、 Smokeが機能するための要件であり、特にLinux以外のシステムでは、ライブラリを機能させることが難しい場合があります。 これは、 qt-libsライブラリに依存するQtoolsのおかげで解決されます。 現在のプラットフォーム用のSmokeライブラリをダウンロードし、アプリケーションのカスタマイズと展開をはるかに簡単にします。

結論：

CommonQtに焦点を当て、 cl-cffi-gtkの改善を支援し、他のライブラリを廃止することを検討してください。

CLIMは興味深いものであり、ユーザーインターフェイスを作成する方法を模索する最後の試みでしたが、2015年には実行可能なオプションではありません。

今後の作業：

CommonQtおよびQtoolsの使用に関するその他のチュートリアルと例。

機械学習



CLMLは非常に用途の広いソリューションです。 Mathematical Systems Inc.によって開発されました。 、日本の会社。 Mike Maulはその後、それをgithubに移植し、コードを少しクリーンアップしました。 時系列チュートリアルが利用可能。

この分野のもう1つの候補はmglです 。これは、著者がヒッグスボソン機械学習チャレンジに勝つために使用したものです。

数値計算の分野では、私はいつもAntikライブラリに興味がありましたが、残念ながら、GPLの下で普及させるGNU Scientific Libraryに依存しています 。 mgl-matとLLAもあります。

結論：

LLAとmgl-matからの計算用パーツとCLMLとmglからの機械学習パーツを組み合わせることで、この分野のほとんどの問題を解決できます。

今後の作業：

CLMLにはおそらく、計算を操作するための多くのコードが含まれており、 SciPy型とNumPy型の別のライブラリに移動できます。

データベース



cl-dbiは、さまざまなデータベース固有のライブラリ（cl-postgres、cl-mysqlなど）へのユニバーサルインターフェイスを提供します。 SxQLは、安全で自動的にパラメーター化された SQLクエリを構築するためのDSLを提供します。

2つの等しく完全なORMがあります。このレビューの著者のCraneとcl-dbiの著者のIntegral です 。

結論：

cl-dbi以外の使用を禁止します。

今後の作業：

Oracleなどの他のデータベースのバインディングが存在します。 cl-dbiのドライバーを作成することは、統一を促進および支援する最良の方法です。

グラフィックス



グラフィックをプログラミングしたことがないので、この分野の知識はほとんどありません。 CEPLと姉妹プロジェクトのVarjoがあり 、 ビデオチュートリアルの優れたコレクションがあります。 もちろん、 cl-openglやcl-sdl2などの低レベルのライブラリがあります。

結論：

CEPLはほぼ完成しているため、使用を促進します。

今後の作業：

pgのような高レベルのOpenGLライブラリは素晴らしいでしょう。

この領域には、特にさまざまなメッシュや他の3D形式を操作するためのライブラリが多くあります。

競争力



cl-asyncは、おそらく競合に関連するあらゆるものに対する最も完全なソリューションです。 また、 Node.jsの背後にあるライブラリlibuvの上に構築されています。

この分野の他の注目すべきライブラリ：



軍団のような図書館は、特定の場合の競争を簡素化します。

結論：

今後の作業：

この分野には、新しいアイデアの余地がたくさんあります。

ファイル形式



Common Lispには、すべての一般的なファイル形式のライブラリがあります。



JSONライブラリに新しく追加されたのは、非常に高速なJSONジェネレーターおよびパーサーであるJonathanです。

結論：

XMLおよびJSONライブラリが多すぎるため、選択が麻痺してしまいます。

今後の作業：

YAMLパーサー。cl-yamlがlibyamlに依存しないようにするため、配布がはるかに簡単になります。

システムの相互作用



UIDFとASDFの互換性レベルには、ホスト名のクエリから外部プログラムの実行および環境変数の操作まで、あらゆる機能を移植するための膨大なユーティリティのセットが含まれています。

結論：

すべてにUIOPを使用します。 cl-fadを使用しないでください。 OSICATを使用しないでください。

今後の作業：

この分野で興味深いプロジェクトは、LLVM IRを文字列として、またはLLVM APIバインディングを使用して生成するDSLです。 これにより、信じられないほど強力なマクロシステムを備えたアセンブラー言語としてCommon Lispを使用できるようになります。 たとえば、高度に最適化されたSIMDベクトル化数値コードをJITコンパイルするには。

その他



ベンチマーク



HaskellでCriterionのようなフレームワークを作成することは、大きな前進です。

解析



ここでは、通常esrapを選択します。これは、Lispのような文法記述からパーサーを生成します。 この分野でさらに多様性が必要です。 最近、高速ベクトル解析ライブラリであるproc-parseがリリースされました。

ロギング



Common Lispにはlog4clやvomなどの優れたロギングユーティリティがあることを除いて、これについてはあまり言えません。

開発



型システム



繰り返しますが、ここで言うことは何もありません。ただし、Common Lispには非常に優れた型システムがあり、そのシステムは最大限に使用されていません。

結論：

CLOSには、Flavorsの現存するバージョンの中で競合他社はいません。これは、Common Lispでの実際の唯一のOOP実装です。

今後の作業：

私はよくtrivial-typesを見ます。これは多くの単純な型指定子を含むライブラリです。 このCDRを含むより大きなライブラリがあれば便利です。

テスト中



多くのテストフレームワークがありますが、主なものはFiveAM以降のProveです。

既存のライブラリの中で、Proveは良い候補です。 拡張可能なレポートジェネレーターは素晴らしいものであり、拡張性に対する一般的なアプローチにより、テストフレームワークの問題に対する優れたソリューションとなります。

その他の古いライブラリは、rtやlisp-unitなどのフレームワークに依存していますが、それらはもはや機能しません。

結論：

FiveAMおよびProve以外のテストフレームワークの使用を禁止します。

今後の作業：

現在の状況では、新しいテストフレームワークを書くと逆効果になります。 作業は、既存のものの統合に焦点を合わせる必要があります。

クラウドテスト



Common Lispは、 TravisやCoverallsなどのサービスの使用をサポートしており、それぞれクラウドでコードをテストし、カバレッジを追跡します。 このための2つの主要なライブラリはcl-travisとcl-coverallsであり、どちらも非常に使いやすいです。 私の経験では、Common Lispプロジェクトのカバレッジのテストと追跡は、Pythonプロジェクトの同じものよりも間違いなく簡単です。

結論：

cl-travisにはいくつかの問題があります。たとえば、実装をインストールするためにsudoが必要なため、Travisの新しいDockerベースのインフラストラクチャを使用できません。

Roswellはこの問題を解決するため、cl-travisでRoswellを使用することをお勧めします。 ここでは、RoswellとTravisの使用に関するチュートリアルを見つけることができます。

今後の作業：

Circle CIなどの多くのサービスのサポートは常に役立ちます。 チュートリアルも良い追加になります。

ドキュメント



Read the Docsスタイルのオンラインで自動的に更新されるドキュメントには、 docparserを使用してプロジェクトAPIの説明を引き出すQuickdocsがあります。

ドキュメントジェネレーターは意外と少ないです。 Codexを使用してドキュメントを生成します。 形式に依存しないドキュメントの内部表現を提供するライブラリであるCommonDocで記述されています。 CodexはSphinxに似ているように設計されています。ドキュメントは散文で書かれており、マクロを使用して、自動的に取得したAPIドキュメント（関数、マクロ、クラスなど）をテキストに挿入します。

結論：

READMEからQuickdocsを参照したり、新規ユーザーにアドバイスするなどして、Quickdocsの使用を促進します。

今後の作業：

CodexとCommonDocの作業を継続し、CommonDocの改善（主に新しい出力形式とマクロ）はCodexに反映されます。

Unicode



これは、ほとんどの実装で本質的に解決された問題です。 UTF-8以外のエンコーディングがインストールされていると、問題に遭遇する場合がありますが、これは、SBCLなどで簡単に修正できます。

(setf sb-impl::*default-external-format* :utf-8)


Cライブラリを操作した場合でも、他のUnicodeの問題に遭遇したことはありません。

結論：

ABCLなど、一部の実装はUnicodeサポートに遅れをとっています。

今後の作業：

Unicodeサポートは、 cl-unicodeライブラリを改善することで解決できます。

パッケージ管理



Quicklispは、 Common Lispの事実上のパッケージマネージャーです。 これで十分です。 動作するものを破壊しないでください。

結論：

すべて順調です。

今後の作業：

QuickdocsやqlotなどのQuicklispベースのユーティリティ。

ビルドシステム



ASDFは、Common Lispの事実上のビルドシステムです。 誰もが彼女を使用しています。

各プロジェクトには、システム定義と呼ばれる.asdファイルがあり、プロジェクトのメタデータ（作成者、メンテナー、ホームページなど）とそのコンポーネントを示します。

私にとって、これはCommon Lispの主な魅力的な機能の1つです。 Pythonのような言語では、各ファイルは必要なものをインポートし、プロジェクトはファイル間の依存関係の巨大なグラフになります。 ASDFでは、定義された順序でプロジェクトファイルをリストするだけです。 または、ファイル間の依存関係を指定して、ASDFに順序自体を計算させることができます。 一番下の行は、依存関係が明確かつ明確に表示されることです。

しかし、十分な動揺。 主なことは、誰もアナログを作成したくないからではなく、ASDFが数年前にすべての選択肢を破壊したためです。 そしてそれは良いことです。

結論：

すべて順調です。

今後の作業：

ASDFの追加コンポーネント、たとえばC / C ++ファイルのビルド用。 Lispライブラリが必要とする外部Cライブラリをロードするためのプラットフォームに依存しないパッケージマネージャは非常に便利です。

開発環境



SLIMEはEmacsに基づいたCommon Lispの開発環境であり、最も広く普及しています。 Emacsで作成されているという事実は問題です。なぜなら、新しいユーザーにSLIMEを使用するためにEmacsを学ぶ必要があることを伝えること（これは完全に真実ではありません）は、CLを学ぶための重大な人為的な障害だからです。

結論：

SLIMEを使用するには、侵入障壁を減らします。

今後の作業：

Emacs以外の環境では大きな害はありません。 Swankサーバーで動作するAtomのプラグインは非常に便利です。

おわりに



特定の問題



コミュニケーション



Common LispでWebアプリケーションを作成し、Clackを知らない人の数は多すぎます。 明らかに、優れたライブラリについて潜在的なユーザーに通知することには問題があります。

選択の麻痺



特定の領域でコードを記述するためにどのライブラリを使用するかを尋ねられた場合、その領域で最適なライブラリのみを推奨する必要があります。 「X、Y、Zも取ることができる」と言うことは、選択の逆説を悪化させるだけです。

誰かがグラフィカルインターフェイス用のライブラリを要求した場合、「 QtoolsでのCommonQt 」と答え、「しかしcl-cffi-gtkまたはLTKを使用することもできます...」を追加しないでください。

Webアプリケーションに何を使用するか尋ねられたら、Clackのフレームワークの1つへのリンクを共有してください。 Hunchentoot、Wookie、Woo、またはその他のサーバーについて話さないでください。

使用する開発環境を尋ねられた場合は、それらをSLIMEに向けてください 。 CLISPでのみ動作する2005年の泥だらけのプロジェクトについては話さないでください。

そして最も重要なことは、どの実装を使用するか尋ねられたら、 SBCLまたはCCLと答えてください 。 「まあ、埋め込みにはECLを、JVMにはたらくためにABCLを使用することもできます」と言わないでください。 それらは、初心者にクイックスタートを与えるためではなく、より狭いケースで使用するためのものです。

開発



Quicklispダウンロード



以下は、1月から7月までのQuicklispからの100の最も人気のあるプロジェクトのダウンロード総数です。



リポジトリ



Githubの新しいCommon Lispリポジトリのこのフィードを購読しました 。 また、 Newsbeuterデータベースへのクエリ用のコードをいくつか作成しました。

 (ql:quickload (list :dbi :yason :local-time :group-by)) (defvar *connection* (dbi:connect :sqlite3 :database-name (merge-pathnames #p".newsbeuter/cache.db" (user-homedir-pathname)))) (let* ((output (merge-pathnames #p"lisp-github.json" (user-homedir-pathname))) (query (dbi:prepare *connection* "SELECT pubDate FROM rss_item WHERE feedurl = ?")) (results (mapcar #'(lambda (result) (local-time:unix-to-timestamp (getf result :|pubDate|))) (dbi:fetch-all (dbi:execute query "http://planet.lisp.org/github.atom"))))) (with-open-file (stream output :direction :output :if-exists :supersede :if-does-not-exist :create) (yason:encode (mapcar #'(lambda (group) (list (local-time:format-timestring nil (first group) :format (list :year #\- :month #\- :day)) (1- (length group)))) (group-by:group-by-repeated results :keys (list #'identity) :tests (list #'(lambda (ab) (= (local-time:day-of a) (local-time:day-of b)))))) stream)))


2015年3月23日から2015年8月20日までに、882のリポジトリが作成されました。



謝辞



Unicodeサポートに関するコメントを寄せてくれたJavier Olaecheaに、 深町栄太郎とフランソワルネリドー 、そしてHaskellエコシステムの状態に関する最初の記事を寄せたGabriel Gonzalezに感謝します 。

Source: https://habr.com/ru/post/J265589/

More articles:


All Articles