言語比較は意味がありますか?[閉まっている]


8

Bjarne Stroustrup博士の著書D&Eによると

何人かのレビュアーから、C ++を他の言語と比較するように依頼されました。これは私がやらないことに決めました。これにより、私は長年にわたって強く支持されてきた見解を再確認しました。主要なプログラミング言語を適切に比較するには、多くの人が費やす意思があるよりも多くの努力が必要であり、幅広いアプリケーション分野での経験、切り離された公平な視点の厳格な維持、公正さの感覚が必要です。私には時間がないので、C ++の設計者として、私の公平さは完全に信頼できるものではありません。

-C ++の設計と進化(Bjarne Stroustrup)

あなたは彼のこの声明に同意しLanguage comparisons are rarely meaningful and even less often fairますか" "?

個人的には、XとYを比較することには意味があると思います。 :-P

人々はどう思いますか?


1
プログラマーが物事のビジネス面について考えることを余儀なくされるとき、非常に多くの仮想的なプログラミングの質問はなくなります。何か新しいものを開発するために一連の言語を選択する場合、それらを比較することを強制されているのではありませんか?既存の経験、ライブラリ、安定性、将来の展望は重要ですが、言語機能も重要です。特に、株主やビジネス関係者が、A、B、Cを選んだ理由を知りたい場合は、あえてPythonがアセンブリと変わらないことを伝えれば、ASMで同じ速度で機能を書くことが期待されます。
ジョブ

その下では、BjarneがC ++とObjective-CおよびEiffelとの比較について話していると思います。言語にはまったく異なる設計目標があったため、1つのクラッジが完全に必要になる場合があります。
Macneil、2010年

回答:


13

プログラミング言語を比較するのが大好きです!

私はジャワをほんの少しの雨の暖かい風と比較します

C#を美しい春の日と比較して、空を幸せに保つのに十分なふわふわの白い雲を

ガラス張りの部屋でCとハンマーを比較する

クリスタルの世界でC ++を大ハンマーのバッグと比較する

私はVBを浴槽に沈む古いワインドアップグッズと比較します

PL / 1を床にボルトで固定した錆びたアンビルと比較します

それらを何と比較しますか?


これまでにそれを愛する!Perl、Python、Ruby、Clojure、Scalaなどはどうですか?
ジョブ

2
@ジョブPerlをキーボードのくしゃみと比較します。コメント欄に自由に追加してください。
スティーブンA.ロウ

2
「Lispは、爪切りが入ったボウル1杯のオートミールのようなものです。」-ラリー・ウォール
仕事

「スキームはエキゾチックなスポーツカーです。高速です。マニュアルトランスミッションです。ラジオはありません。EmacsLispは1984年のスバルGL 4WDです。「常に目の前にある車」です。Common Lispは、ハウルの動く城です。」-Steve Yegge
22:34

3
(Lispは(ある意味(少なくとも))(私の祖母(RIP))が(興味深い(通常は(および関連する)))接線で話しているようなものです
スティーブンA.ロウ

9

Stroustrupは完全に正しいと思います。2つの言語の技術的メリットを適切に比較するには、慣用的なコードを記述し、両方の言語で非常に生産性の高いプログラマーが通常使用するのと同じ設計パターンを使用するために、両方に十分に精通している必要があります。両方の言語についてそのレベルの知識を持っていない人は、あまり馴染みのない言語によって明示的に提供されていないものを見て、結果として問題があると思い込むかもしれません。

たとえば、Pythonを定期的に使用しない人は、Pythonユーザーがインデントのために定期的に問題を抱えていると想定するかもしれません。あるいは、Common Lispに精通していない人が洗練されたライブラリの欠如を検討するかもしれませんが、FFIがわずかな労力でCライブラリのラッパーを作成するのに十分強力であることを知りません。Rubyに慣れていない人は、静的型付けの欠如に気づき、型エラーが主要な問題であると想定するかもしれません。最後に、Haskellに精通していない人は、割り当ての欠如に気づき、状態を処理できないと想定するかもしれません。

現在、これらすべては、言語が実際には技術的なメリットのみで比較されることを前提としています。


その最初の文以外はすべて同意します。Stroustrupは、C ++を他のものと比較するのに適していません。ただし、+ 1は、2つを適切に比較するために両方を適切に理解する必要があることを示しています。
フランクShearar

6

言語はツールです。とは言っても、私は以前、本当に、本当にひどいツールを見てきました。頭が飛んで胃の中で別の大工を打つ傾向があるハンマーで作業したいと思う人はいません。同様に、同僚のハンマーがその形状になっていることに気付いた場合、おそらく彼らがそれを使用しているときにそれらを避けます。

それがどのツールであるかを本当に理解することも重要です。ドライバーとハンマーを同じ意味で使用することはできません(ただし、必死にしようとする人もいます)。地獄、すべてのハンマーを交換して使用することはできません。あなたはいくつかのもののためのそり、他のもののためのマレット、そしてさらに他のもののための鋲が必要です。不適切なツールを使用すると、せいぜい劣悪な仕事をしてしまい、最悪の場合、自分や同僚を傷つけることになります。

つまり、言語比較は職場の事故を防ぐことができるという点で有用です。比喩から上記を取り除く; 特定の言語がスレッジハンマー、スクリュードライバー、ドレメル、テーブルソーのいずれであるかを比較せずに知ることは困難です。物理的なツールとは異なり、一見しただけでは実際にはわかりません。あなたはそれが提供する機能について考え、(実際に書かれた大きなコードベースの重要な部分を読み込もうとすることによって)それを実際に見て、そして理想的には自分でそれを試してみる必要があります。PythonでCobolを作成するだけのミスを犯さないように注意してください(たとえば)。新しい言語を慣用的に使用する必要があります。つまり、上手に学習する必要があります。Bjarneが有用な比較のためにほとんどの人が十分な努力を払っていないと言っているのは、おそらくこれが理由です。

「私はBlubが好き」で始まり、「まあ、私はBlub ++が好き」と続く比較のタイプは完全に役に立たない。言語の選択が必要になった場合でも、特定のグループで最も説得力のある人や、広告予算が​​最大の言語会社がどれであるかがわかります。言語が何をすることができるか、どんなタスクが適しているか、そしてその欠点が不当な議論や個人的な偏見に頼ることなくどこにあるかを分析するなら、それは確かに役に立つかもしれません。


あなたは足であなたを撃つことができるハンマーを経験しましたか?

1
@トール:多くの銃にはハンマーがあります
スティーブンA.ロウ

@ThorbjørnRavn Andersen:私はそれほどひどい比喩を混ぜなかった:pいいえ、しかし私はハンドルがゆるいハンマーを使用した(2回目を振ったときに頭が飛んだ;だれにもヒットしなかったが、瓶を壊した)。重要なのは、ハンマーが貧弱であるというようなものであり、「ハンマーを比較してはならない」と言っても、それらがすべて同等または交換可能な場合にのみ、賢明なアドバイスです。
Inaimathi、2010年

ただし、他のハンマーとの比較に頼らずに、ハンマーが危険であること、またはハンマーの使用目的を説明することができます。
jhominal 2010年

3
ライブラリはツールに似ています。言語は、ツールを構成する素材のようなものです。私たちは通常、ハンマーとドライバーの両方を鋼で作ることを好みます。そして、多くの言語は錆びた鉄、ゴム、または遊び道具のように感じます。
MJP、2011年

4

それは、いくつかのまれな(そして-まれなことです-「太陽系の寿命の間に1回または2回起こる」例外)例外を除いて、それは通常、多かれ少なかれ強力なバリアントで言語戦争につながり、非常にまれにいくつかの実用的なままにしますそして有用な結論。

言語は道具であり、宗教ではありません。ハンマーをドライバーと比較するのではなく、自分のタスクと考え方、教育方法、必要な抽象化レベルに最も適合するハンマーを使用します。また、比較を行う方は、2つのうち少なくとも1つを知っている、または少なくとも2つのうち1つを好むという事実に偏っているため、それらを比較するための真に客観的な基準を見つけることは困難です(例外が存在します)。


2
ああ、でもハンマーとドライバーを比較するべきです。ペイントの缶を開けるのに役立つ2つの方法を他にどのように知っていますか?
Frank Shearar、2011年

@フランクハンマーを使用してペイントを開くことができますか?車を使ってきました。
Matt Ellen

@フランク-私は両方でペンキのバケツを開くことができると思います;)しかし、なぜわざわざ(それはとにかくネジが上に付いています)
Rook

1

言語を製品として扱い、すべての開発者を市場として扱う場合、いくつかの興味深い結論を導き出すことができます。

  1. 製品は常に競合するとは限りません。たとえば、Haskellは、Prologと同じ問題を解決しないAssemblyと同じ問題を解決しないJavaと同じ問題を解決しません。1人の開発者がさまざまな状況でこれらの言語をすべて使用する場合があります。比較は、優位性のための競争を意味します。したがって、競合しない言語を比較しても意味がありません。
  2. 市場での可視性は、その製品がすでに誰かにとって有用であることを証明していることを意味します。つまり、RubyとPythonを好きなだけ比較できます。どういうわけか、それは誰かの心を変えるようには見えません(またはそれが起こったとしても、同じ数の人々が他の方向に心を変えます)。重要な点では、RubyとPythonは同等です。これは、2つの大手ソーダ会社が自社の製品を「科学的に」比較しているようなものです。1つの研究はコカコーラが優れていることを示し、もう1つの研究はペプシが優れていることを示しています。データが信頼できるとしても、それは何も意味しません。私たちは皆、それらが完全に優れたソーダ(プログラミング言語)であることを知っています。
  3. 言語比較はオタクマーケティングの一種です。比較を開始するための完全に客観的な場所があった場合、それらは有用かもしれません。もちろんありません。比較を行うのに面倒な人は、既存のバイアスを確認しようとしています。彼らは言語を売ろうとている。繰り返しますが、C ++が非常に悪い、VBが非常に悪い、またはErlangが非常に悪い場合、なぜ人々はそれらを使用していますか?あなたはあなたが望むすべての主張をすることができます、しかしそれはそれらが有用であるのを止めません。私たちの仮定は、人々が前に真実を見るには馬鹿であるということですが、真実は「市場」が私たちが理解するよりも複雑である可能性が高いです。比較は、比較される製品についてよりも、比較を行う人についてより多くを教えてくれます。

0

Stroustrupは完全に正しいです。

ほとんどの「言語比較」は、特定の結果を念頭に置いて実行されます。つまり、一方が他方よりも「優れている」ことを「示す」ことです。

多くの場合、これは両方の言語でコードを記述し、生成された実行可能ファイルのパフォーマンスを測定し、一方の言語を高度に最適化し、もう一方を意図的にパフォーマンスの低下に対応させることを意味します。これは、「Javaが遅い」という神話が永続する方法です。それを「証明する」ための「テスト」は、Javaコードの実行のパフォーマンスではなく、JVMの起動時間を測定するために意図的に書かれています。たとえば、単純な数学演算を100回ループして、JavaとC ++でそれを行い、最適化をオンにしてC ++バージョン、最適化フラグなしのJavaバージョンをコンパイルしてから、両方の実行可能バージョンを実行します。Javaクラスは、JVMの起動時間のために、C ++実行可能ファイルよりもはるかに長く実行されます。これは「Javaが遅い」ということではありません ただし、JVMの起動時間は、Javaが実行中の非常に短いプロセスに適したツールではないことを意味します(インタープリター言語や、ランタイムのロードを必要とするその他のものではありません)。テストが適切に作成され、コードベースとコンパイラシステムの両方が同等レベルの最適化を使用して数時間にわたって実行された場合、結果はかなり異なります(おそらくかなり似たパフォーマンスを示しています)。

そして、それはほんの一例です(私がたまたま知っています)。


0

プロジェクトマネージャーは、ソフトウェアをコーディングする言語を選択するためにいくつかの比較を行う必要があります。基準は技術的ではないかもしれません:

  • タスクに適した言語ですか
  • 言語はすべてのターゲットプラットフォームで使用できますか
  • コンパイラーの品質、信頼性、コスト
  • その言語を知っているプログラマーはいますか?彼らは有能で高価で創造的ですか?

1
新しい、より高度な言語に精通しているプログラマーは少ないかもしれませんが、彼らは非常に能力がある傾向があります。
kevin cline
弊社のサイトを使用することにより、あなたは弊社のクッキーポリシーおよびプライバシーポリシーを読み、理解したものとみなされます。
Licensed under cc by-sa 3.0 with attribution required.