Lispの未来
最近、私はよくLispの既存の方言と、私たちがどの方向に向かっているかについて考え始めました。 特に、私は別のLisp方言を書く可能性と、それが有用であるそれらの領域を考えました。
あなたがまだそれに慣れていないなら、Lispは素晴らしい言語のファミリーです。 その非常に最小限の構文により、非自明な構文や言語フレームワークの種類を気にすることなく、ほぼアルゴリズムのレベルで考えることができます。
市場の位置
従来、サポートされているライブラリが不足しているため、大学での教育にのみ役立つスキームがあります。CommonLispもあります。
Clojureは間違いなくこれまでで最も人気のある方言です。 一部の人々は、これが現時点で実用的な価値を持つ唯一のLispだと主張するでしょう。 多数のデータ型に構文シュガーを導入し、JVMとの統合に成功し、従来のLisp言語に特有の厄介な部分はすべてなくなりました。
ただし、Nuなど、他にもあります。Nuは、iOSやMac向けに何かを作成する場合に万能薬ですが、ポインターは好きではありません。 （ねえ、それはMacRubyのように見えます！）
しかし、なぜNuは離陸しなかったのですか？ そして、なぜCLとSchemeは死んだのですか？ なぜたった1つのClojureが勢いを得ているのですか？ 別のLisp方言で同じ成功を期待できますか？
呪い...そして祝福
間違いなく、構文はどこにも行きません。 S式はLispを非常に単純にし、マクロと呼ばれるクールな機能を使用できるようにしますが、これらのブラケットはすべてうんざりするものであり、Emacs + pardeitで動作しない限り誰もそれらを処理できません。 Lispの最大の長所は、おそらく彼の最大の弱点です。
しかし、移植性も忘れてはなりません。 標準ライブラリが存在しないため、Schemeだけでアプリケーションを作成する人はいません。 Clojureは、クロスプラットフォームであるだけでなく、組み込みの便利なクラスとサードパーティライブラリを備えたJVMに方向を変えました。 Javaのおかげで、JVMは全体的で安定したプラットフォームです。
しかし、プラットフォームについて何を気にしますか？
Nuは非常に興味深い方言です。 iOS / Macの開発プロセスをより簡単で楽しくするために作成されました。 Lispマクロのセットと、開発を開始するのに役立つ便利なツールのホストを提供します。
しかし、CocoaはプラットフォームではなくSDKです。 そうでなければあなたに言う人は誰でもあなたに何か（おそらくXcode）を売ろうとしています。 Mac / IOSアプリケーションでは、すべてがグラフィカルインターフェイスにあり、開発のあらゆる段階で必要なすべてのコンポーネントは、プラットフォームのフレームワーク内で既に提供されています（追加する必要があり、互いに密接に接続されています）。 必要なのは少し想像力です。
それで何が悪いのでしょうか？
Cocoaでアプリケーションを作成する場合、モデル、コントローラー、ビューを取得し、それらを最小量のObjective-Cコードで「接着」する必要があります。 したがって、Lispのすべての機能を適用する機会を失います。 Nuコードのほとんどすべての行（オフハンド-約95％）はObjective-Cコードを呼び出すことしかできないため、Lispの使用はばかげています。
さらに、ほとんどのAppleライブラリは、このタイプの開発のコンテキスト以外では意味を持ちません。 したがって、関数型プログラミングのパラダイムを効果的に使用するために実際には何もできません。また、Lispとの互換性を維持するためだけに、Appleの低レベルC関数を回避する必要があります。
Appleの「superglue」（Objective-Cについて）を使用して「自家製」の接着剤（Nu）を使用するのは無意味であることがわかりますが、それだけの価値はありません。 これは本質的に、SDKの問題です。Cocoaだけでなく、Androidなども同様です。
JVMは自由を提供します。 アーキテクチャは完全にあなたの指先にあります。 自分でモデルを作成します。 プレゼンテーションレベルは、アプリケーションのタイプ（サーバー、GUI、コマンドラインユーティリティなど）に応じて選択されます。 最初から最後まで完全に自由です。
適切なプラットフォームを見つける
しかし、これはJVMのユニークな機能ではありません。 C、C ++、Python、Rubyでも同じことが起こりますか？ 率直に言って、RubyまたはPythonに組み込まれたLispは冗長です。これらの言語を使用すると、必要な機能の90％を実装できるため、マクロのためだけに何かを発明する必要があります。
そしてもちろん、Lispなどのアルゴリズム言語とCなどの低レベル言語、またはC ++などのスパゲッティ生成言語との間には通常の互換性はありません。 誰かがメモリを解放します。なぜ、いつ、そして一般に、私の鶏はどこにいますか？ これはすべて複雑すぎます。
その他の潜在的なニッチ
ちょっと考えてみてください。RubyとPythonの道をたどり、独自の標準ライブラリのセットで解釈されたLisp方言を書きます。 最終的に、これらの2つの言語は非常に成功しました。
しかし、これらの言語にはそれぞれ独自のプログラミング環境（Emacsなし）があり、数週間で言語の専門家になるために誰でもすぐに習得できることを認識して、すぐに地球に降りてきます。 Lisp固有のS式では、これが許可されません。
あるいは、新しいLisp方言は、Goに進み、信じられないほど高速なコンパイルと実行時間を持つ静的言語になることができます。 しかし、これが最も重要だとは思いません。 コンパイル時間は0より小さくすることはできません。これは、おおよそRubyとPythonが存在する場所です。 そして理論的には、特定の状況（惑星が並んでいて、片足で3回ジャンプする）を除いて、ランタイムはjvmランタイムよりずっと小さくすることはできません。
予見可能な未来のために！
真実は、JVMがそれを行うレベルで、標準ライブラリ、サードパーティのサポート、拡張性、幅広い機能、コミュニティ、移植性を現在提供できるプラットフォームは他にありません。 Clojureは現在Lispの最高の化身であり、近い将来にそうなり続けるでしょう。