この小さなプログラム[1]は自由時間で書かれているため、十分な時間はありません。
Haskellの実際の使用に関する印象を説明したいと思います。
ユーザーの対応
批判がありました。 しかし、それは喜ばしいことですが、実装言語については何も言われていません。 ユーザーは、あなたがあなたのプログラムを書いたものを気にしません。 Haskellを使用すると、出力はマシンコードの実行可能ファイルになります。 ユーザーは、インタープリターやバイトコード仮想マシンが必要ないことさえ喜んでいるでしょう。 また、このプログラムを実行するために異常なものをインストールする必要はありません。
インストールによって深刻な問題は発生しませんでした。 たとえば、Cookieが無効になっているなど、わずかな問題がありました。 または、64ビットシステムでは、32ビットシステム用にバイナリファイルが実行されました。
Haskellの問題
言語の問題
Haskellでのプログラミングには博士号が必要だと彼らは言います。 これは真実ではありません。 言語仕様と洗練されたライブラリを開発している人たちは本当にそれを必要としています。 しかし、言語の「ユーザーインターフェイス」は非常にシンプルで直感的です。 他のプログラミング言語については、教区学校の3つのクラスで十分です。
プロジェクトの作業中、言語に関連する問題は1つだけでした。 ある時点で、モナドのトランスフォーマーの大きなスタックに別のモナドを追加する必要がありました[2]。 これは重要なタスクであることが判明しました。 ircのHaskellistsのドキュメントと友好的なヘルプを読むことで、問題は夕方に解決されました。 正直なところ、この場所はもっと簡単にできますが、静的な型付けによってエラーのクラス全体から自分自身を守ることができたのはそのような実装でした。 詳細が興味深い場合は、別の投稿を作成します。
エントリーしきい値と学習曲線
Haskellに入るためのしきい値は非常に大きいという意見もあります。 そして、学習曲線が伸びすぎています。 この機会に、私は次のように言うことができます。
Haskellを学び始めたばかりの頃、私は1つの小さな問題を解決していました。 Haskellのソースコードには複数行がありません。 つまり、ソースに大きなテキストを追加して、有効な文字列定数を取得することはできません。
-- , text1 = " " -- text2 = unlines ["", ""] -- text3 = "\n\ \"
600行のプログラムを作成しました。これは、入力として特別なテキストファイルを受け取り、複数行の文字列定数を使用してHaskellでソースを生成しました。 これにより、Webアプリケーションの開発時にすべてのテキストをバイナリに直接埋め込むことができました。
Haskellをさらに研究すればするほど、このコードが非常に悪いことがわかりました。 状態モナドはなく、解析にparsecライブラリは使用されませんでした。 すべては、すべてのパラメーターを明示的に示し、単純な構成のみを使用した単純なコードで行われました。
しかし、このコードは2年経っても簡単に理解できました。 そして彼は完全に私に合った。 しかし、このユーティリティが必要なアセンブリのために、プロジェクトのリリースが近づいていました。 彼女をそのように見せることは恥ずかしかった。 それで、私は座って、30秒間パーセクで書き直しました[3]。
おそらく、スムーズな学習曲線で問題はありません。 異種のガイドでHaskellを学ぶ初心者でも、非常に実用的なコードを作成します。 そして、初心者が経験豊富なHaskelistsのチームに来ると仮定すると、彼はすぐに良いコードを書くと思います。 C ++などの成功した工業言語には、これに数年の経験が必要です。
他のシステムとの相互作用の問題
本当の困難は、Haskellが終わるところから始まります。 つまり、プログラムが厳しい外の世界と相互作用する場所です。 たとえば、オペレーティングシステムまたはユーザーのブラウザーとの対話。
Webアプリケーションの場合、これはWebページの作成とjavascriptコードの開発の通常の仕事です。 また、ブラウザー間の互換性の問題やその他のWeb開発の喜びも含まれています。
システム側では、個別の作業も必要です。 インストールスクリプト、初期化、システムの動的ライブラリとの相互作用。 これにはすべて、Linuxでのシステム開発と同じスキルが必要です。
図書館 ネイティブライブラリに加えて、Haskell用にライブラリライブラリの多数のラッパーが作成されています。 しかし、すべてではありません。 作業の過程で、実際に既製の実装がなかったため、PAMライブラリ[4]の周りに独自のラッパーを作成する必要がありました。 結局のところ、Haskellでコードへのインターフェイスを記述するのは非常に簡単です。
Haskellと比較した場合のPythonの支持者は、ほぼすべてのライブラリが既にPython用に作成されていると主張します。 しかし、ライブラリにアクセスするための既存のパッケージをゼロから書き直した1つのPythonプロジェクトに参加する必要がありました。 既存のコードはひどいものだったからです。 したがって、Pythonのこの利点はそれほど大きくありません。
それとは別に、Linuxディストリビューション用のパッケージを作成する問題に注意する価値があります。 それほど単純ではなく、パッケージングインフラストラクチャ全体が従来のコンパイラと言語に合わせて調整されています。 Haskellプログラム用のパッケージを作成するトピックは、別の投稿に値します。 HaskellプログラムがRed Hat Enterprise Linux 5などの実績のあるシステムでも構築されていることを嬉しく思いました。そこでPythonでアプリケーションを実行するには、Python 2.4で作業する必要があります。 または、新しいインタープリターをそこで実行して、インストールとサポートに関する問題をさらに増やしてみてください。
haskellが排除する問題
私は言語の公式ウェブサイトからの紹介から「なぜHaskell？」という段落を完全に再語するつもりはありません[5]。
この段落の言語の利点の短いリストを示します。
- プログラマの生産性が大幅に向上しました。
- より簡潔で理解しやすいコード、維持費が安い。
- バグが少なく、信頼性の高いプログラム。
- プログラマと言語の間の「セマンティックギャップ」が少なくなります。
- より速い製品リリース。
実践が示しているように、彼らは嘘をつかない。
しかし、自分でこのリストに別のアイテムを追加します。 Haskellプログラミングは楽しいです。 20世紀半ばのプログラマーは、おそらく、アセンブラーが最初に登場したときと同じ感情を持っていました。 作業の同じ単純化は、アセンブラーからフォートランへの移行にありました。
Haskellは、名前付きメモリ領域（変数）を管理する必要がなくなりました。 開発者は名前付きの不変値のみを取得します。 コンパイラーは、メモリー内の表現を処理します。 これは、プログラマーの作業の重要な自動化です。
さて、ビジネスがHaskellにもっと注意を払うまで待ちましょう。 本番環境でHaskellを使用するリスクがあるため、
[1] http://iptadmin.confmgr.org
[2] ソースへのリンク、認証機能の目的のコード
[3] http://patch-tag.com/r/etarasov/iptadmin/snapshot/current/content/pretty/util/ptmpl/src/Main.hs
[4] http://hackage.haskell.org/package/pam-0.1
[5] http://haskell.org/haskellwiki/Introduction#Why_use_Haskell.3F