長い間、私はHaskellが製品の実際のタスクでそれ自体をどのように示したかについての記事を書くことを約束しました。



追跡しなかった人々のために-2012年の初めにそれはロビー活動であり、Selectelのプログラマーは熱心にそれを紹介し始めました。 それから、「これがすべて」の使用方法に関するレポートを公開することを約束しました。



商業プロジェクトの製品は、「自分用」の小さなサンドボックスではなく、コンピューターサイエンスの学術的な実験でもありません。 これは、地獄、恐怖、そして死が存在する「党路線」のための果てしない闘争ですが、とにかくうまくいくはずです。 XML-RPCのInt64は文字列でエンコードされ（XML-RPCのintはint32に署名されるため）、ファイルから複数の証明書を読み取る際のopensslは最初の証明書のみを読み取り、boolでは「1」または「0」のいずれかを書き込む必要がありますが、 -「2」。これは、このようにしてのみエンコードする3番目のモードを思いついたからです-など。 など これらの条件では、言語の要件は、そのエコシステム、インフラストラクチャ、実世界に適応する準備の要件に徐々に発展します。



Haskellについては、プログラマーではなく、プロダクトオーナー、プロジェクトマネージャー、システム管理者の観点から書きます。 ですから、モナドを介してどれだけ優雅にセミグループ型を作成できるか、そして型を使用して型を介して型を導出するのがいかにクールであるかについて、心からの熱意を期待しないでください。



プロジェクトマネージャーの観点から見ると、プログラミング言語は、プログラミング言語とは完全に異なるいくつかのメトリックを使用して評価されます。 プログラマーにとって、言語とその機能はおそらく最も重要なものです。なぜなら、彼はほとんどの時間を費やしているからです。 チームの残りの部分では、ソースの外で何が起こっているかがはるかに重要です。 まず、ライブラリと適切なテクノロジーを検索し、次にメンテナンス、監視、実装、デバッグのタスクを検索します。



消費者のプロパティから始めましょう。

プログラム実行速度

Haskellプログラムは、python、php、ruby（およびその他のインタプリタ言語）よりも高速です。 Erlang / Java（およびその他のvmベースの言語）よりも高速です。 HaskellコンパイラーがCコンパイラーの結果よりも優れた結果を生成するいくつかのケースを見てきましたが、通常はCより遅いです。



Haskellパフォーマンスのすべての実用的なアプリケーション-目の後ろと耳の後ろ。



Python（これから徐々に移行しました）と比較した主な利点は、実行の優れた並列性です。 GILはなく、「ワーカー間の外部バランサー」も、デバッグベントの問題もありません。



Haskellにはフルタイムのグリーンレットがあり、オペレーティングシステムのスレッドをネイティブに使用しています。

実行可能ファイルサイズ

ほとんどの場合、気にしませんが、一部の場所の構成では混雑しており、22MBの実行可能ファイルの最小サイズは迷惑でした。 「cr屈な場所」が解決されると、サイズは具体的な役割を果たしなくなりました。 私たちの最大のサーバーは44MBを占有し、3ダースに動的にリンクしています。

メモリ使用量

（このセクションでは、「リソース」、つまり、RES列に対応する上部のコードではなく、データが保存されるメモリについて説明しています）。



コンピューターアルゴリズムでは、通常、使用されるメモリはO表記で計算されますが、重要な要因があります-プロセスが多く、それぞれがO（1）である場合、サーバー上で消費されるメモリ量はどれくらいですか？ それらの同じ「プレベニアン定数」は、突然役割を果たすようになります。



Haskellは、Pythonプログラムに匹敵するメモリを使用します。 デーモン（大量のデータを格納しない部分）は、9〜20メガバイトを占有します。 Pythonデーモンはほぼ同じです。



このパラメーターでは、HaskellはOCamlより少し劣っていること（そのため、戦闘サービスは1〜2メガバイトのメモリで生きることができます）、そしてもちろん、C（たとえばmoddは0.15MBしか消費しません）、Java / Erlangの状況よりもはるかに優れていると言わなければなりません。

実際の実行可能ファイル

ほとんどの居心地の良いソフトウェア環境（jvm、python、beam.smp、php、perl、.netなど）には、かなりのインフラストラクチャ（インタープリター/仮想マシンの実行、適切な場所での多数のファイルなど）が必要です。 「ユーザーから2つの番号を受け取り、それらをデータベースに書き込み、プロジェクト管理者にその金額を表示する」プログラムを作成すると、すべてが問題ありません。



ただし、シングルモードで実行するプログラムを作成する必要がある場合があります。 または、initの代わりに。 または、init自体から。 またはsuidで。 または他の方法で、居心地の良い実行環境を展開する場所がないようにします。



Haskellは実行可能ファイルを生成します。 本物のELF。 静的または動的にすることができます。 それは素晴らしいことです。



2番目の重要な要因：起動速度。 多くの場合、プログラムは開始および終了します。 python（および他の多くのインタープリター言語）では、特に大量のインポートにより、起動時に100500の異なるファイルがスキャンされ、起動時に100〜200ミリ秒の遅延が発生します。 Haskellでは、ldはPythonやPHPよりも何倍も速く動作するため、この値ははるかに小さくなります。



ps / top出力についても同じことが言えます-Haskellプログラムは、プロセスリストの「単なるプロセス」のように見える通常の実行可能ファイルであり、ファイルを起動するpythonのようではありません。



これにはマイナスがあります：突然の32/64ビットは異なる実行可能ファイルであり、libffi5またはlibffi6はすでに特定のディストリビューションまたは同じバージョンのアプリケーションの「相互互換性」を妨げる大きな違いです配布キット。

モニタリング

Haskellプログラムはオペレーティングシステムに「ネイティブ」であるため、特別な監視機能はありません（比較のため、Javaマシンには独自のインジケータがあり、監視する必要があります。Erlangには独自のインジケータがあります）。

コード品質

すでに作成されたプログラムを操作する場合、興味のあることが1つだけあります。それは、すべてがクラッシュ、ビープ音、および台無しになる頻度です。 だから、Pythonと比較して-比類ないほど少ない。 はい、適切なファイル処理を行うと、トップレベルにリークした例外をキャッチできますが、この可能性は非常に小さいです（すべてのプログラムで使用中に一度見たことがあります）。



愚かな間違いの可能性ははるかに少ないです。 そして、「かなり」と言うとき、これは理論上ではなく、実際には、つまり、HaskellとPythonで同じ人によって書かれた同じ製品を観察することです。



Pythonは、他の動的に型付けされた言語と同様、継続的な時限爆弾です。 すべての悪い状況を明確に考えなければなりません。さらに、小さなローカルエラーや過失に対して誰も保証しません。 エラーは、実行時に表示されるか、pass：（さらに悪い）を除いて暗黙的に非表示にすることができます。 タイプ 'NoneType'のオブジェクトにはメソッドがありません-それだけです。 また、このエラーがまれな分岐にある場合、コードが長い間「安定してよく表示され」、一般に300日間の稼働時間が経過すると、鉱山が完全に遅くなり起動します。



残念ながら「すべてのコードをカバー」するテストは、「すべての可能なタイプの入力データ」（突然動的なもの）をカバーせず、入力エラーをまったく保存しません。



Haskellでは、このようなエラー、「おお、このブランチで確認するのを忘れた」または「戻り値の型を混ぜた」レベルのエラーはプログラムに表示されません。 プログラマーは、これらのエラーのほとんどをコンパイル段階でキャッチできる便利な型システムに加えて、配列や一時変数のインデックスに気を取られることなく主要なものを書くことができる言語でこれを主張しています。 彼らはよく知っています。



見つかったエラーの分析の経験から、私たちが遭遇したエラーのほとんどは、TORのエラー（つまり、謙虚な使用人のエラー）か、プログラマーがTKを誤解したものであると言えます。 しかし、ローカルの間違いや物忘れではありません。



これは逆説的な結論につながります：動的型付けを使用する言語では、NoneTypeが突然クロールアウトした次の場所が修正されたため、Haskellでプログラムのバグを修正することは難しく、Haskellでは、アルゴリズムを処理する必要があります他の人々が宣誓することでTKの明確さが欠如していることに。

ライブラリの成熟度

球状の真空プログラムは、球状の条件および真空でのみ機能します。 他のすべての人は、数百万の複雑なフォーマット、仕様、およびプロトコルがある現実の世界で働いています。 つまり、ライブラリが必要です。 数千人。



そして、驚くべきことに、Haskellにはそれらの多くがあります。 つまり、「彼らは戦闘コードを取り、書き始めた」という観点から-はい、ロギング、ssl、ready orm、regexp、ローカリゼーションのサポート、時間、httpサーバーなどを作成する必要がないからです。 ほとんどすべての準備が整いました。 不快な瞬間がありましたが。 たとえば、私たちはHaskellのbson / mongdbの実装を独立してサポートする必要がありました。これは、由緒あるTengenが彼のサポートを停止したためです。



...同時に、ほとんどのプログラムはCで記述されたライブラリにリンクされているため、Haskellプログラムもセフォールトから保護されていません。これは、ライブラリエラーか、このライブラリが間違って呼び出される原因となったプログラマ（およびこのコンパイラ自体もはや保護しません）。 いくつかの場所で、これにより純粋なHaskellでライブラリが書き換えられました（たとえば、この理由から、 Henを作成しました 。これは、Xenで作業するために必要なリクエストのサブセットを実装します。コミットは完全なサポートを歓迎します）。

コンパイル速度

これが問題になるとは思っていませんでしたが、プロジェクトを構築するのに30分かかりました。 多数のコアと超高速ストレージを備えた非常に昔ながらのハードウェア上。 個人的には、「すごい、私たちのプログラムはすでに30分もコンパイルされている」という誇りの最初の瞬間の後、バグ修正が小さく、シーンがこんにちはので、いらいらし始めました。

難易度の追跡

メンテナンスとは、関連する小さな変更を導入することです。つまり、「何が間違っているのか」という現地の明確化、つまり、生きている「自分の」プロジェクトのルーチンです。



それで、伴奏でそれはかなり不快になりました。 システム管理者にモナドコンピューティングを教えることもできることは明らかです。 しかし...まあ、あなたはポイントを得る。 必要に応じてシステム管理者がPythonコードを見つけて修正できる場合、コードはshaitan-arbaになり、それを変更するために特別な人が接続されます。診断スタイルでのみ問題について話す必要があります（「ここでは機能しません」 "）。 第一に、devopの相乗効果をいくらか損なう（チームの誰かがチームの2番目の部分の本質を理解していない場合、それは悪いことです）、第二に、コードに座っている人々の要件が非常に怒っています。



プログラマーの検索は、Haskellの謝罪者が別の言い方をしなかったかのように、問題です。 関数型プログラミングでは、特に「コマンド」とテンプレートhaskellを使用する場合、「再トレーニング」するオプションでさえ問題になります。 言い換えれば、言語は参入のしきい値を引き上げる追加の障害です。



労働市場におけるプログラマーの既知の不足の文脈では、これは障害です。 一方、そのようなものの存在は、「php + js、ここから正午まで」にうんざりしているプログラマを引き付けます。

開発スピード

確かに、私は一緒に働いたプログラマーを含む言語の謝罪者から多くのdigりを聞くでしょう。 しかし、客観的な現実：HaskellでのプロジェクトはPythonよりも遅く記述されます。 反論は、プログラミングスタイルの変更、詳細への注意などに私を導きますが、それでも、実践に基づく私の現在の信念は-Haskellでの新しい機能の実装の最終速度が著しく低いことです。 ああ。



これは、プログラムの作成後にPythonでまともなループを構成するあらゆる種類の愚かなバグをデバッグしてキャッチする時間によって部分的に補われますが、Haskellにはほとんどありませんが、これを念頭に置いても、それでも遅くなります。



プロトタイピングに関する同様の問題。 Pythonの基本的なプロトタイプが、ラボのインタラクティブな環境で行ったことをほぼコピーアンドペーストしているように見えても、Haskellでは通常、しばらくの間（タイプなど）消え去る、ある種の神聖なアクションです。結果につながります。 結果が「私たちが夢見ていたものとはまったく異なる」ことが判明した場合は、最初ではなく、ファイナルにより近いことが明らかになります。 したがって、ソリューションの検索における反復のコストが増加し、プロセス全体の柔軟性が低下します。