15


3

GUIデスクトップアプリケーション用のHaskellまたはD?

私はhaskellとそれに関連する多くのものがタイプエンジンとして好きで、Hackageの多くのパッケージ、素晴らしいコミュニティ、活発な開発などが好きです。

Otoh、私はHaskellが複雑すぎて(モナド、学界の専門用語がたくさんある…​)grok(C ++のバックグラウンドから来ている)を考えている私たちの計画されたプロジェクトをあきらめた経験があるので、開発者を私たちに連れて行くのが簡単かもしれませんDを使用する場合のオープンソースプロジェクト

データベースバックエンド(おそらくsqlite3)を必要とする一般的なデスクトップアプリケーションを開発し、いくつかの広範な計算タスク(エフェメリス計算)にC-libを使用し、Qtツールキットを使用する必要があります。未来。

ソースコードを簡単に文書化する能力とメンテナンスは重要な要素です。機能リストが長いため、自由な時間に開発することを考えると、必要なものをすべて書くのに長い時間がかかる場合があります。

Pythonと他のスクリプト言語はプロジェクトには遅すぎます。長年後にC ++に戻りたくありません。より高度なプログラミングをお勧めします…​詳細をあまり説明せずに、他のものを除外しました。 langauges(Go、Clojure、Java ..)もHaskell vs Dにリストをもたらします。

Dに関する懸念の1つは、QtDプロジェクトが中断されたことです。そのため、短期的にはDを適切なオプションとしてカウントできるかどうか、興味があります。

Linux / MaC / Windowsプラットフォームをカバーする一般的なプログラミング言語としてより適しているかもしれない長所/短所はありますか?

編集: postへのリンクを追加します要件について詳しく説明します。

7 Answer


11


ここでいくつかの要件をいじってみましょう、そして私はHaskellのケースを作成しようとします。 おそらくDファンや他の人が同じことをしようとするかもしれません。

  • デスクトップアプリケーション

そのため、Haskellは確かにデスクトップおよびサーバー側のアプリケーションに使用されます。 これらのツールは、http://haskell.org/platform [Haskell Platform]を使用するだけで、最新のすべてのデスクトップで使用できます。

  • データベースバックエンド

重要な用途を持つHas​​kellの有名なデータベースバックエンドは、http://hackage.haskell.org/package/HDBC [HDBC- *]およびhttp://hackage.haskell.org/package/sqlite[sqlite]です。 http://hackage.haskell.org/packages/archive/pkg-list.html#cat:database [その他多数]があります。

Haskellでデータベース駆動型アプリを使用した他の商用グループには、次のものがあります。Galois(sqliteライブラリは上記にリンクされています)。ドイツ銀行(http://cufp.galois.com/2008/abstracts.html#PolakowJeff[talk]を参照);ハスラー芝設備(HDBCの本拠地)。

  • Cライブラリ(したがってFFIバインディング)

Haskellには、広く使用されている高レベルのFFIがあり、Haskell 2010の標準的な部分です。

  • Qtの使用

qtHaskellは商用アプリケーション向けに開発されたもので、たとえば JoyRide Labsの商用ゲーム。

  • ソースコード文書

Haddockは広く使用されています。 graphmodやhttp://hackage.haskell.org/package/SourceGraph[sourcegraph]などの他の分析ツールも、要件のドキュメント化に役立ちます。

  • メンテナンス

いくつかの商用ユーザーは、コードのローカルで安全な変更を簡単に行えるようにするため、長いプロジェクトサイクルにわたってアプリケーションのメンテナンスの負担を軽減するために、純粋で強力なタイプを挙げています。 純度はコンポーネント間の複雑さを軽減し、タイプはリファクタリングが適切であることを保証します。

  • その他の事実

コミュニティの規模-オープンソースのHaskellコミュニティは、他の大規模なFP言語(Erlang、Scala)に匹敵するようになりました。 商用ユーザーはGHCの直接的な開発に資金を提供し、長期的な可用性を確保しています。多くのhttp://haskell.org/haskellwiki/Haskell_in_industry[experience reports]から引き出すことができます。 ハッカーとCabalは、新しいオープンソースの作業を簡単に取り入れることでリスクを軽減し、時間を節約します。


6


あなたのコメントには警戒しています:

_ Pythonおよび他のスクリプト言語はこのプロジェクトには遅すぎます _

単純なスタイルで記述されたHaskellは、おそらくpythonよりも1桁も高速ではありません。 Haskellプログラムの詳細を細かく調べることで、低レベルのCプログラムと同じくらい高速にすることは可能ですが、それはトリッキーで、時間がかかり、例えば、多くの知識が必要です。 GHCのコード生成メカニズム。

あなたはすでにCバインディングを使用していると言いますが、速度は重要ですか? あなたがチェックしていないという仮定に基づいて多くの素晴らしいツールを捨てているのではないかと心配しています。 他の何よりも優れたライブラリサポートを備えたツールが必要なようです。

Scala、Scheme、C#/ VB.NET(モノ)はどうですか? HaskellとDにオプションを制限すると、どのような奇妙な基準が原因になるか想像できません。

とはいえ、Haskellは素晴らしい言語です。 それがあなたのプロジェクトに合うなら、それのために行きなさい。 同じ結果を得るために作業の10%を実行できる他のツールが存在する場合、Haskellを選択しないように、少し心を開いてください。


3


ガールフレンド、サンドイッチ、カーニバルなどのプログラミング言語ではありませんか? ゴミをなくすと、お気に入りは自分よりもあなたのことです。

HaskellもDもゴミではなく、両方ともあなたが言及するアイテムを処理することができるので(すぐに使えるQtサポートを除いて-絶対に必要な場合、Dは動作しないかもしれません)あなたとあなたの特異性に最適です。 各言語でプロトタイプを作成します。 sqliteからいくつかのデータを取得し、GUIで表示します。 まだ決定していない場合は、異なるOSで各プロトタイプをビルドして、クロスプラットフォーム開発が期待どおりであることを確認してください。

キャビアについて聞いたことを繰り返して、個人的な体験を共有することもできますが、気に入った場合は試してみてください。


1


最後に、gtk +およびwxWidget haskellバインディングは、qtバインディングよりも広く使用されている(おそらくバグが少ない)と聞いた。

ネイティブjava widgitまたはhttp://qtjambi.sourceforge.net/[qt java bindings-qtjambi]のいずれかのscalaについては、彼らのWebサイトを見ると、コミュニティによってかなりサポートされているようです(既に4.7ベータ版があります)。


1


私は最近、Haskellの学習を開始し、「Haskellを非常に有益に学習する」にある簡単な例のタイミングを測定しました。この例は、整数辺が400未満のすべての正しい長方形を書き出します(チュートリアルでは10未満でしたが、その理由はわかりました)。 WinGHCiのタイミングは34秒を超えていました(6コア3.3 Ghz AMD、64ビットWindows 7で)。もちろん、メモリ使用量は約6 GBでした。 比較のために、このプログラムをAda(トリプルネストループ)で記述し、タイミングは0.1秒未満でした。 恥ずかしさを大幅に減らし、Dを選択する必要があると思います。 DはAda / C ++と同じカテゴリーに属します(実際にはAdaから多くを借りています)が、多くの最新の機能と非常に優れた無料のコンパイラを備えています。 Dに関するAlexandrescuの最近の本があり、その大部分を読んだことで、Haskellの場合は数年ではなく、数週間で言語を完全に学習できることを証言できます。


-1


Pythonは遅く、C ++は見苦しいかもしれませんが、お気に入りのあいまいな言語で作業することを主張する人は、単独で作業する準備が必要です。

HaskellもDも、RailsがRubyに対して何であったかというキラーアプリを開発していると考えている場合を除き、プロジェクトに他の1人の開発者を引き付ける可能性はまったくありません。


-1


プロジェクトにDを使用しない理由を説明します。

システムのツールチェーンのステータスは怖いです。 WindowsとLinuxで動作しているように見えるコンパイラDMCが1つあります。 これは決してオープンソースにはならず、Digital MarsからではなくWalter Brightからのペットプロジェクトのようです。

gdcコンパイラはバグが多く、D 1.0でのみ動作します。2.0拡張のほとんどは利用できません。 このプロジェクトにはメンテナーがいないようで、GCCソースは完全に怪物ですので、このプロジェクトを引き継ぐ人がたくさんいるとは思わないでください。

llvmコンパイラはバグが多く、D 2.0のサブセットでのみ安定して動作します。 プロジェクトにはメンテナーがいるようですが、ゆっくりと進行しています。

また、32ビットIntel以外のサポートの状態は脆弱です。 私はamd64について確信が持てず、ARMのサポートを得る希望はないと思います。

これに基づいて、Dは、より大きなミッションクリティカルなアプリケーションを行う会社の言語選択の節約になるのに十分な開発者がいるという希望を失いました。 ツールチェーンと戦い、頻繁にC ++に戻ることを祈ります。

Haskellについてコメントすることはできませんが、プログラマーがHaskellの専門家になることを期待しないでください。 これが彼らの仕事を辞める理由かもしれない-それはきっと私にとっての理由だろう。