Clojureを使用する方が適切な場合は？ [閉まっている]

StackOverflow https://stackoverflow.com/questions/1800896

  •  05-07-2019
  •  | 
  •  

質問

私はLispとSchemeで開発していますが、Clojureについて読んでいたので、知りたいのですが、どの場合にLispやSchemeを使うよりもそれを使うほうがよいでしょうか？ありがとう

役に立ちましたか？

解決

＆quot; ClojureはJVMで実行されます＆quot; Javaライブラリの宝庫全体を入手できることを意味します。 SwingできれいなGUIを作成し、ApacheのWebクライアントまたはサーバーコードを使用して、既製の数独ソルバーを接続できます。

Clojureのもう1つの大きな利点は、非常に洗練された並行性サポートであり、約3種類のフレーバーがあります。計算集中型の並列化可能なタスクがある場合、Clojureを使用すると簡単です。まあ、簡単です。

更新：別の引数。 Clojureは非常に機能的であるため、機能的に考えて記述させるようにしたい場合はプラスになります。

他のヒント

この質問に答えることは不可能です。 CLとSchemeのほぼ100％の時間でClojureを使用する必要があります。しかし、それはあなたが私に耳を傾けるべきだという意味ではありません。他の人は、反対のことが正しいと主張することができます。

私にとって、Clojureの構文名と関数名は見た目が美しいです。特定のJavaライブラリは、データの改ざん、Webプログラミング、およびGUIの処理で非常に貴重です。関数型プログラミングは挑戦的で楽しいものです。 Clojureの欠陥は重要ではなく、私の目には利点があります。他のLispのある種の耐えられない欠陥は「修正」されています。 Clojureでは、新しいものであり、下位互換性を無視できるためです。並行性に対する斬新で間違いなく強力なアプローチがあります。 Clojureコミュニティは活気があり、歓迎されており、素晴らしいです。これはすべて、Clojureやその他のLispについての私と、私が大切にしていることについて語っています。

ClojureやJavaには存在しないCLおよびSchemeのライブラリがあります。 Clojureが [] や {} などの構文を過度に使用する方法を嫌い、どこでも括弧を使用したい人がいます。 CLOSスタイルのOOPまたは多くの可変データ構造が必要な場合は、別のLispが間違いなく優れています。 JVMは重量がありますが、重量が大きすぎて荷物が多すぎる人もいます。多くのJavaが（設計により）Clojureにリークし、これは一部の人々の感性を損ないます。 STMと不変のデータ構造にはオーバーヘッドがあり、特定の処理（数値の処理など）が遅くなったり、エレガントになったりします。 Clojureは新しく、特定の分野ではまだ荒いですが、他の分野では急速に変化し進化しています。 Clojureはまだ時の試練に合格していませんが、他のLispはすでに合格しています。 Clojureは「標準」ではありません。また、実装によって定義されている言語が魅力的でないと感じる人もいます。等々。これらはどれも私には関係ありませんが、あなたにとってはそうかもしれません。

これはほぼ完全に主観的です。どの言語を使用すべきかは、すでに知っていること、何を学ぼうとしているのか、どのライブラリを使用したいのか、どのエディターやツールに慣れているのか、どの言語の欠陥を抱えて対処したいのか、そして許容できない欠陥、および作業をより速く、より安く、より楽しく、または目的を達成するために役立つもの。

基本的に、あなたが暖かく、あいまいに感じるものは何でも。それらすべてを学んだ後、自分の好みに基づいて情報に基づいた選択を行い、好きな方を使用してください。すべて良いです。

いつ？できるだけ。 どうして？不変のデータ構造-それらは本当に優れています。 その他の理由もたくさんあります。

Clojureは次の場合に使用する必要があります

  • 既存のJavaコードを使用する必要があります。
  • あなたはlispにアレルギーのある人と仕事をしています（「ボス、clojueと呼ばれるJava並行ライブラリを使用したいのですが、これをスキームで書き直したいのです」」[1]
  • マルチプロセッサシステム用にプログラミングします。

スキームは次の場合に優れています：

  • コードが正しいことを証明する必要があります。 Clojures（javaを呼び出す）は妨げますが、これを妨げません。
  • あなたは、Javaにアレルギーのある人と仕事をしています。
  • JVMがまったくない（十分に新しい）プラットフォーム向けに開発している

[1]はい、これは悪い悪い悪い理由です。私たちが住んでいる世界は...

ABCL （Armed Bear Common Lisp）およびいくつかのScheme実装（KAWA、SISC 、...）もJVMで実行されています。

Generally Common Lispはさまざまな「フレーバー」で利用可能です-ABCLはその1つです。その他のC、ネイティブコードへのコンパイルには、広範な開発環境、またはロジック言語やデータベースなどの特殊な拡張機能があります。

Clojure OTOHは、遅延関数型プログラミングと並行プログラミングに重点を置いた新しいLisp方言です。著者（Rich Hickey）は非常に経験豊富なソフトウェア開発者であり（Common Lisp用のJavaおよび.netインターフェースも作成しています）、Clojureで素晴らしい仕事をしました。言語に誇大宣伝がありますが、チェックアウトする価値があります-それは間違いなく、近年開発された優れたLisp方言の1つです（NewlispやArcと比較して）。

多くの理由がありますが、いくつかは上で述べました。私の意見は：

  1. 既存のライブラリ。これはメリットですそのような。この機能を十分に賞賛することはできません。
  2. この言語は、 現在利用可能なハードウェア （マルチコア）と開発 今日使用されているパラダイム。並行性について推論するのは非常に簡単です。機能面も優れています。もちろん、Lispで関数型プログラミングを行うことができますが、知らないうちに、知らないうちに、意図せずにパラダイムを破ることは非常に簡単です。
  3. クロスプラットフォーム。私は同一を実行します Linux、Windows、および マック。たくさんのネイティブLispがあります プラットフォーム間で実行されますが、 すべての機能のサポート プラットフォームは少しむらがあり、あなたは 常に警戒する必要があります 不足しているものについて プラットフォームまたはその他。同様に、 必要なライブラリが常にあるとは限らない 一貫してサポート プラットフォーム。 ABCLおよびいくつかの JVM Scheme実装にはこれがあります 一貫したサポートもありますが、私は まだClojureを好む ポイント2。
  4. 言語の性質 コミュニティ。それに直面しましょう、たくさんの Common Lispコミュニティの時代 対処するのは厄介です。あれは Clojureの場合はまったくありません。 せずに便利なヘルプを取得するのは簡単です 軽desと卑劣さ 多くの場合、 Common Lispコミュニティ。私が持っているように 何回か自分で学んだ そんなに愚かな質問はありません あなたは礼儀正しく親切になりません Clojureコミュニティからの返信。

不満を言うことが1つあるとしたら、それはIDEのサポートです。たぶん、それは新しい習慣を学ぶことの問題かもしれませんが、ClojureよりもJava開発の仕組みを扱う方が私にとっては簡単です。 Clojure Box、NetBeasでenclojure、Intellij IDEAでLa Clojure、EclipseでCounterclockwiseを試し、使用しました。主にREPLから作業している場合はすべて正常に動作しますが、クラスファイルのコンパイルと実行については、すべて少し不器用です。

Clojureのサブセットは、 javascript

にコンパイルすることもできます

ClojureはJVM（およびCLR）で実行されるため、それがあります。

Clojureの設計は、いくつかのスタイルの並行プログラミングを安全に収容することに関係しており、他の言語で危険で、ガタガタで、しばしば壊れた並行性許容コードを誤って書くことを困難にします。問題領域に並行プログラミングが含まれる場合、並行性を管理するためのClojureの統合ツールの配列は、他のLispおよびSchemeで利用可能な実装固有または最小公分母のライブラリよりも適している可能性があります。

Clojureの最大の利点の1つは、Clojureで使用できるライブラリが豊富にあることです。 Lispの表現力を備えたJavaのパワーを持っていますが、それは悪い組み合わせです。 Clojureは、実世界の開発用に作成されているため、実世界の開発により適しています。 Clojureを使用すると、優れたライブラリ、優れた最新の機能、有用で志を同じくする人々の素晴らしいコミュニティを手に入れることができます。

Clojureはずっと優れた言語であると言わざるを得ません。これは非常に議論の余地のある発言であるため、ここではこれが単なる私の正直な意見であることを指摘します。

クロジュール岩。

私は常に新しい言語を学ぼうとしているので、Clojureを学ぶことに興味があります。しかし、SBCLや他のCommon Lispの実装は、Clojureよりはるかに高速ではありませんか？ Clojureアプリと、同じアプリのシングルスレッドSBCLバージョンとの間のパフォーマンスの違いを補うために、4個以上のプロセッサー（および合理的に並列化可能なタスク）が必要ではないでしょうか？

一般的な経験則として、私はこれらのいずれかが法案に適合する場合、他の言語よりもClojureを好む傾向があります。 （1）。ドメインモデルは、非常に再帰的および/またはグラフのように見える傾向があります。 （2）。マルチコアJVM環境（Elastic Beanstalkなど）を活用する機会があります （3）。データとコードの間にはあいまいな障壁があります（ノードが演算子または数値になるRPN電卓を考えてください）

これらは少し不自然に聞こえるかもしれませんが、私の仕事の多くは、ソーシャルネットワーク、何らかの制約ベースの最適化、またはセマンティックリレーションシップの構築を見るかに関係なく、グラフや情報の木を扱うことを伴います。私のお気に入りの言語であるRubyは、特に量的、再帰的、並行型の問題解決に関して、Clojureと比較して表現力と生の計算能力の組み合わせを提供できないことがわかりました。

ライセンス： CC-BY-SA と 帰属
所属していません StackOverflow
scroll top