Erlang は簡潔さの範囲のどこに位置するでしょうか?たとえば、簡潔さの低い Java/.net と、より簡潔な範囲の Ruby/Python の間でしょうか? 私は RSI の問題を抱えているので、健康上の理由から簡潔であることが特に重要です。
4 に答える
言語機能としての簡潔さは定義が不十分で、おそらく統一されていません。問題に応じて、さまざまな言語が多かれ少なかれ簡潔になる可能性があります。
関数型言語としての Erlang は、Ruby や Python よりも非常に簡潔です。具体的には、パターン マッチングはしばしば if ステートメントを置き換え、再帰およびリスト内包表記はループを置き換えることができます。
たとえば、Java には次のようなものがあります。
String foobar(int number){
if (number == 0) {
return "foo";
} else if (number == 1) {
return "bar";
}
throw new Exception();
}
一方、Erlang コードは次のようになります。
foobar(0) -> "foo";
foobar(1) -> "bar".
0 または 1 以外の入力の句がないため、固有の例外があります。これは、Erlang スタイルの開発に適した問題の原因となります。
一般に、変換として定義できるものはすべて、関数型言語に特によく一致し、非常に簡潔に記述できます。多くの関数型言語の熱狂者は、プログラミングの問題は変換であると述べています。
他のすべての新しいツール、DHT、ドキュメント ストア、mapreduce フレームワーク、hadoop、GPU、scala と比較して、erlang のスイート スポットを理解するには、時間をかけてコードを記述しなければなりません。アプリがスイート スポットの外にある場合、おそらくパラダイムと戦い、冗長なコードを記述することになりますが、サーバーとミドルウェアをシームレスに上下にスケーリングする必要がある問題に遭遇した場合、それは自然に流れます。(そして、そのスイートスポットでのscalaの台頭も避けられないと思います)
数年前の Tim Bray Wide Finder の実験 (大きな apache ログ ファイルの抽出) と、彼が erlang にどのように失望したかを調べるとよいでしょう。
本当に良いコードと悪いコードを比較することは避けられないことを考えると、Alioth の銃撃戦に多くのストアを配置することは一般的にお勧めしませんが、LOC の数を配置する必要がある場合は、erlang と C、Ruby など、何でも構いません。
https://benchmarksgame-team.pages.debian.net/benchmarksgame/faster/erlang.html
Erlang は、パフォーマンスと信頼性を実現したい場合は特に、驚くほど簡潔です。
Erlang は、Haskell と比較しても簡潔です。
http://thinkerlang.com/2006/01/01/haskell-vs-erlang-reloaded.html
そして、C++ と比較しても驚くほど高速 (かつ信頼性が高い) です。
(SLOC が 18 倍少ないことは驚きではありません)。
とにかく、それは常にあなたの好みとあなたが達成したい目標に依存します.
Erlang を使用すると、Java や Python での私の経験と比較して、非常に少ないコード行で機能を実現できます。過去に私に近づいたのは Smalltalk か Scheme だけでした。オーバーヘッドはほとんどありませんが、通常、モジュール、関数、変数、アトムの識別子を話す傾向があります。コードが読みやすくなります。そして、通常、中括弧、および角括弧がたくさんあります。したがって、キーボードのレイアウトによって、どれだけ快適になるかが決まります。試してみてください。
ミュー