LISPがもっと普及しないのはなぜですか？
SICPの動画でSchemeを学び始めました。次にCommon LISPに移動したいと思います。
言語は非常に興味深いようであり、その本を書いているほとんどの人々は、それが比類のない表現力を持っていると主張しています。 CLにはまともな標準ライブラリがあるようです。
LISPがもっと普及しないのはなぜですか？それが本当にそれほど強力である場合、人々はそれを至る所で使用する必要がありますが、代わりに、たとえばLISP求人広告を見つけることはほとんど不可能です。
しばらくは大した問題ではないので、かっこだけではないことを願っています。
表現力は必ずしも肯定的な言語特性ではありません企業環境では。 Javaは、習得が簡単で、書きやすく、読みやすいという理由もあって、非常に人気があります。平凡なプログラマは、たとえコードが冗長で洗練されていなくても、Javaで非常に生産的です。
さらに、表現力豊かな言語を悪用するのは簡単です。エキスパートJavaプログラマは、不十分に書かれたコードをすばやくリファクタリングできます。言語が表現力を増すほど、恐ろしいコードの理解とリファクタリングは困難になります。LISPマクロは良い例です。マクロは、右側の強力なツールです間違った手で行うと、混乱を招き、コードのデバッグが困難になる可能性があります。
LISPは危険な選択です上級管理職向け。問題が発生した場合、OracleやMicrosoftなどの大企業が支援する人気のあるオブジェクト指向言語を選択したことで、管理の責任を負う人はいません。人気のある、習得しやすい言語の経験を持つプログラマーを採用する方がはるかに簡単です。
より強力な言語を使用することをいとわない進歩的な企業でさえ、通常LISPを選択しません。これは、新しい言語の多くが、LISPから強力な機能を借用しながら、大衆のために学習しやすいままにして、妥協しようとするためです。 Scala and Rubyこのモデルに従います。悪いプログラマはすぐにそれらを拾い、Javaで行ったのと同じ平凡なコードを書き続けることができます。優れたプログラマは利用できます美しいコードを書くためのより高度な機能の。
括弧は問題ではありません。 Haskellは、非常に強力で表現力のある言語で、PythonまたはRuby= LISPと同じ理由の多くのために広く採用されていません。
これにもかかわらず、私は願っています...
Clojureは人気になる可能性があります。これはJVMで実行され、Javaとの相互運用性が高く、並行プログラミングがはるかに簡単になります。これらはすべて、多くの企業にとって重要なことです。
*これは、Java、Clojure、JRuby、Scalaの経験を持つプロのJVMプログラマとしての私の見方です。
LISPがもっと普及しないのはなぜですか？本当にそれが強力なのなら、人々はそれを至る所で使うべきです、
言語が技術的なメリットのために選択されていると信じるなら、あなたは心を砕く失望に陥っています。
このような決定は ストリッパーとステーキ に基づいて行われます。マイクロソフトはそれらを買う余裕があります。 Oracleはできます。 Sunは莫大なお金を費やしてJava=彼らは破産しました。2度。分散化された異種のボランティアコミュニティはこれに対抗できません。
しかし、代わりに、たとえばLISP求人広告を見つけることはほとんど不可能です。
おかしなことに、LISP企業は正反対のことを言っています。 （Haskell、ML、O'Caml、Forth、Smalltalkなども同様です）
私は実際の会社で働いた経験はありませんが、なぜLISPが使いにくかったのかはわかっています。
まず、これはこのブログ投稿を思い出します： http://steve-yegge.blogspot.com/2006/04/LISP-is-not-acceptable-LISP.html
私がLISPに関して抱えている主な問題は、「LISPに関する質問」です。私は通常、メインプラットフォームとしてLinuxで作業しますが、Windowsと互換性があるようにする必要があります。つまり、使用するテクノロジを評価するときに、根本的に異なる2つのオペレーティングシステムで作業するときに、それが私の生活を楽にする必要があります。この要件は好きではありませんが、要件である実際のプロジェクトで使用することは好きです。自分の個人的なサイドプロジェクトには、Windowsでのサポートが十分でない言語を使用しますが、大規模なソフトウェアプロジェクトを作成する機会がないため、必要な経験がありません。
関数型言語を学ぼうとしたとき、私は本当にCommon LISPを学びたかった。それは正しいことのように思えました。私は実際に組み込み関数を知らず、LISPで作業するためのプロジェクトが必要だったので、Practical Common LISPを出発点として読み始めました。 S式は美しく簡単でした。コードで何が起こっているのかがはっきりとわかったので、これらの括弧はすべて私にとって非常に美しいものでした。
それで私は本の外でLISPで私の最初のプログラムを書こうとします。コードの行を数え、コードの数から簡単な行を削除するコマンドラインツールが必要でした。最も便利なツールではありませんが、実行するのは楽しいです。これには、ファイルアクセス、少しの解析、およびカウントが含まれます。約1週間前に同じツールをPythonに実装しました。
コマンドライン引数にアクセスする必要があります。次に、コマンドライン引数を取得する標準的な方法がないことを学びます。これらはすべて非標準の機能です。クロスプラットフォームではありません。言語には多くのライブラリが組み込まれていないため、ほとんどの場合そこから悪化します。私は最終的にHaskellに切り替えてしまい、Common LISPにそれほど深く入りませんでした（そのため、私の不満は有効ではないかもしれません）。
この種の非標準的なことは、これまで常に私にとって苦痛でした。 C++にも同じ問題がありますが、Boostなどのライブラリを使用すると、これらの弱点を回避できます。
また、S式以外のすべてのLISP構文が少し見苦しいことも役に立ちません。
IMO、それは主に原因です：
- 貧弱なライブラリのサポート。確かに、今すぐQuicklispがあり、ライブラリを簡単にインストールできますが、ライブラリがまだかなり少ないことを補うものではありません。 Pythonと比較して、（特定の方言に関係なく）重要なLISPアプリケーションを作成することは、おそらく、少なくとも1つまたは2つのホイールの一部を再発明することを含む可能性が高いです。
- 開発ツールで採用されているモデルに精通していない。私が知っているほとんどの人は、SLIMEとEmacsを使用する必要があることにかなり脅されています。これは、EclipseとVisual Studioに慣れている人には理解できます。 Eclipseプラグインは2つあると思います。数年前にそのうちの1つだけを試しましたが、かなりバグがありました。 LISPエコシステム全体は、それが本格的なLISP実行システムの一部であった日々と、oh-it's-another-languageの最新の標準の一部であった日の中間で行き詰まっているように見えます。 LISPの学習は、新しい言語の学習に限定されるものではありません。また、まったく異なる働き方や考え方を学ぶ必要があります。趣味でやっている場合は問題ありませんが、それを行う価値があるかどうかは疑問です。ビジネス。
しかし、物事は少し良く見え始めていますが、特にClojureが周りにあります。
10億年前に大学でLISPを学びました。
LISPは、FORTHと同様、ロジックに最適です。しかし、ほとんどのプログラミングはロジックではなく、退屈な機械的な方法でデータを操作することです。たとえば、当時は数値出力を右揃えする方法がありませんでした。
LISPはネストされた機能に関するものであり、人々はそのように考えていません。彼らは、DO A、B、C、D、そしてEの観点から考えています。Aはしないでください。AはBとCを行い、次にDとEを行います。 「所得税申告書を提出する」などの事前定義されたタスクを除いて、人々は同時に考えるのではなく、順番に考えます。これが、今日、手続き型言語が主流となっている理由です。
その結果、コードJavaおよびCは英語に簡単に変換できます。LISPコードは変換できません。人間の言語はそのように構成されていません。
したがって、問題解決には最適ですが、プログラミングでは問題解決はそれほど重要ではありません。 LISPがひどく弱かったデータ入力、検証、出力フォーマット。
まだ言及されていないLISPの問題の1つは、平凡なプログラマーや初心者プログラマー（私のように、私は自由に認めます）にとって、LISPコードをどのように大きなプログラムに変換するかを理解するのが難しいことです。書くのは簡単ですが、設計するのは難しいです。コンセプトは特に難しいとは思いませんが、DIYの考え方は非常に強く、どこから始めればいいのか途方に暮れることがよくあります。
OOP JavaまたはC＃のような言語を使用すると、型システムを使用して機能するモデルに向かって後押しし、それを構築することができます。LISP（またはLua、またはそのことについてはJavascript）は、外に出て好きな方法で実行できるという考え方です。OOPが必要な場合は、独自のOOPシステムを作成してください！ OOP、または他の人のことを学ぶことは、使用可能なプログラムを入手する前の言語の新しい障壁です。さらに、私は常にOOPは実際にはそこにいないように感じます私が本当に欲しかったならそれを無視することができたので、ポイントは何ですか？
要するに、LISPでのプログラミングには多くの規律が必要であり、それを実現するのは非常に難しいと思います。強く型付けされた言語とOOP言語はどちらも一種の組み込みの規律を提供するため、プログラマは言語を微調整するのではなく、プロジェクトの仕上げに限られた準備を集中させることができます。
編集：ちょうど私を襲った類推として、それはあなたがいくつかの木工をする必要があり、2人があなたに彼らのツールボックスを提供するようなものです。ある人のツールはちょっと不器用ですが、基本的には少しの労力で仕事が完了します。もう1人は部品の大きなビンを持っていますが、それらの部品を組み合わせて、これまでにない最高のツールを作成し、グリップに完全に適した最高品質のツールにすることができると約束しています。最初に作成する必要があります。
私は同じことを長い間考えていましたが、LISPカンファレンスに行って、誰もがそれを採用できないようにしているこのLISPの「ダークサイド」とは何かを理解しようとしました。
完全なまともな答えは見つかりませんでした。
無知が人気の欠如の理由かもしれませんが、私をさらに困惑させるのは、LISP（たとえば、Google-Peter Norvigが彼らのために働いている）について確かに誰もがそれを使用していないということです。
私が思いつく唯一の部分的な説明は、LISPの優れたアイデアのほとんどが今では一般的であり、唯一重要な欠けているもの（非常に重要なIMO）はメタプログラミングの容易さです。
残念ながら、ニースになるためのメタプログラミングには同型の通常の言語が必要なので、他の言語にこの概念を取り入れるための簡単な方法はありません（私は、単純なテンプレートのみのバージョンではなく、一般的なメタプログラミングについて話しています）。つまり、基本的にはLISPによる構文へのアプローチが必要です。コードはデータであり、データはコードです。 ASTを操作する構文が豊富な言語でコードを記述することは、コードの記述方法とASTの記述方法の2つの言語を知る必要があるため、より困難です。 ASTは固定されており、多くの異なるノードタイプでも複雑で不規則です。LISPは、適度に規則的（かつ拡張可能）です。）ASTそしてすでに通常ASTを直接記述してコードを記述します。
また、メタプログラミングは本質的に困難であり（メタメタプログラミングはさらに難しいなど）、ほとんどのプログラマーとマネージャーは、「誰もその必要がない」という答えを好むようです。
特に悲しいことに、goのような「新しい」言語は、必要なときにテキストベースのメタプログラミング（外部コードジェネレーターがテキストファイルを書き込む）と「マジック」（つまり、コンパイラーがプログラマーができないことを実行できる）を使用することになった。
複雑さの問題の解決策は、強力なツールと教育だと思います。傾向は明らかに鈍いツールであり、問題が存在しないふりをしています。
CLでさえ、ライブラリのサポートがあまり良くないようです。少なくともLISPからPythonに切り替えた人々によると：
http://www.redmountainsw.com/wordpress/archives/reddit-switches-from-LISP-to-python
個人的には、Schemeをいくつか知っていて、それを楽しんでいますが、その言語で重要なプロジェクトを行うことは想像できません。
強力であることは、必ずしも広く使用されていることを意味しません。 「一般的なケース向けに最適化」という言葉を聞いたことはありますか？残念ながら、多くの人が平凡になる前に、一貫して保証されているかどうかは、多くの失敗が間にある大きなヒットよりも人々にずっと良いかどうかを伝えました。
これは、LISPの場合だけでなく、多くのテクノロジーにも当てはまります。 Unixのテキスト処理ツールawk、sed、Perlを上手に操作すると、プログラミングの日数を節約できます。残念ながら、他のツールでこの種のタスクを実行するのに何日もかかるのを見たことがありますが、これらのツールを使用して数分でより効率的に行うことができました。しかし、すべての人生をEclipseで過ごすと、これらのことの価値を認めるようになることは決してありません。あなたは可読性と保守性などを備えた巨大なプログラムを書くかもしれませんが、そのようなプログラムを書いていないのに書いていないということの要点は簡単に仕事をしたでしょう。
ツールを設計する際のもう1つの側面は、問題を解決するためにツールを直接使用することが、箱から出してすぐにどれだけ役立つかです。あまりにも一般的なものを構築してから、ライブラリやフレームワークを介してそれらすべてをヘッジするとは言えません。その方法で問題を解決するのは少し難しいです。優れたツールは、環境とその周りの問題とうまく調和します。 php、Perl、awkなどのツールは、トローリングやバッシングが無限に行われているにもかかわらず、関連性が高いままである理由です。これらは使いすぎて多くのライブラリやフレームワークが組み込まれた一般的な言語よりも多くの作業を行うためです。
同様に、Java/Pythonなどの言語が非常に優れていることがわかります。 Python特に優れており、学習と記述が簡単です。また、これらの言語は、データエンドポイントが標準である場合に非常に役立ちます。ある種のデータベースまたはXMLまたはその種のデータです。基本的に構造化データ。
LISPは長い間存在しますが、必ずしも普及しているわけではありません。ご覧のとおり、各ツールにはニッチがあります。そして、特定の問題をすぐに解決します。 LISPがうまく解決するように設計された領域や問題で、LISPはうまく機能していると思います。
IMO、それは主にタイミングの問題です。LISPは、ほとんどの人や用途にとって実用的になるよりもずっと前に古く（そして定義上、もはや刺激的ではありません）でした。 Clojure（一例として）の方がずっと良いチャンスです。その成功は、Java（およびJVMで実行される他のすべてのもの））との相互運用と同じくらい実用的であるよりも、新しく、ファッショナブルでクールであると見なされることに大きく依存します。