Ruby：悪い部分[終了]

私は最近、Crockfordの本「Javascript：The Good Parts」を読みましたが、基礎となる前提の1つは、プログラミング言語にはプログラマが避けるべき悪い機能セットがある可能性があることです。

私はルビイストであり、言語が大好きである一方、視点を得るには常に価値があります。それでは、Rubyで最悪の機能（メソッド、クラス、プラクティスなど）とは何だと思いますか？ここでの私の意図は、言語自体の長所や速度などについて議論を始めることではありません。むしろ、過去の経験に基づいて、使用するのに危険/厄介/苦痛と思われる機能についての議論を希望します。

あなたは見なければならない死にAバトル：Rubyの対Pythonのがゲイリー・ベルナールで。彼は引用する：

私がRubyで見苦しいと感じるのは、RSpecのような素晴らしいRubyソフトウェアを可能にするものであり、そのPythonは（現在の実装を考えれば）決してありえないことです。

彼は特にPythonについて多くのことを語っていますが、Rubyの奇妙な多くのことに触れています。大きな包括的な主題の1つは、サルのパッチングです。

Rubyオブジェクト（他のオブジェクト指向言語のオブジェクトとは異なります）は個別に変更できます。オブジェクトごとにいつでもメソッドを追加できます。Rubyでは、オブジェクトの動作または機能は、クラスによって提供されるものとは異なる場合があります。

これは多くの柔軟性を提供し、Rubyの最も人気のある複雑なgemの一部を強化しますが、どこかのライブラリがコアメソッドを変更したことを認識せずに問題をデバッグしようとすると、お尻に噛みつきます。

一部の人々はレール上のルビーの観点からのみルビーを考えていますが、言語がそれ自身でかなりよく立っているので、それはちょっと迷惑です。

最悪の機能はopen classes、変更されたクラスの現在および将来のすべてのインスタンスの動作をグローバルに変更できることだと思います。

この機能の問題のある部分は、Rubyインタープリターが定義を見つけたときに実行時にこれらの（グローバル）変更が発生することです。これは、動作を突然変更するいくつかのオブジェクトを既にインスタンス化してからかなり後になります。

大きなコードベースでは、これは非常に非常に難しいバグを見つける可能性があります-特にこれはRubyの弱い（たとえばCLRまたはJVMと比較して）デバッグストーリーとevalこのコンテキストの他の機能（たとえば）の使用により悪化するためこのグローバルな変化が発生した場所を見つけるのは非常に困難です。すなわち、トラブルを引き起こしている「正しい」クラスが疑われるポイントにすでに到達している場合！私の経験では、実際の犯人を使用してオブジェクトで問題が表面化し始めるので、通常は野生のガチョウの追跡から始めます。

したがって、最良の方法は、オープンクラスの使用を停止する#extendこと（および変更をaに配置することModuleは、より安全で、理解しやすく、テストしやすいことです）、または回避できない場合：

• 新しい動作でクラスを拡張するだけです（つまり、既存の動作をオーバーライドしません）
• ソースコードツリーに定義済みの場所があり、オープンクラスを使用するすべての拡張機能を配置する必要がある
• #eval友達を使ってオープンクラスを作成しないでください
• オープンクラスのすべての使用法を、すべての開発者が見ることができる大きな目に見えるチャートに配置します-そして、それらの変更は、コードベース全体（彼らが行う）に影響する「アーキテクチャ上の決定」であり、クイックハックの場所ではないことを明確にします現在のタスクのために

私がルビーを使わない最大の理由：氷河期の北極での1月の糖蜜よりも遅い。言語のベンチマークは不正確な科学ですが、RubyはJavaScriptやPythonよりも大幅に遅いようです。

これをRuby on Railsに拡張できる場合、次のようにします。

1. データベースロジックによって、すべてのテーブルにauto_incrementプライマリキーが与えられているという事実は、それらを必要とせず、持つべきではないテーブルも含みます。

2. 複合キーがまったくサポートされていないという事実。

単純なRubyの場合、私の不満は、表現力と安全性を犠牲にする他の言語と同じです。ほんの少しのコードで多くのことをするのは簡単ですが、どんな量のコードでも巨大な混乱を作るのは同じくらい簡単です。

Rubyは、メタプログラミング（リフレクション、イントロスペクション）、マルチパラダイムプログラミング、およびダイナミズムを一般的でないレベルで採用しています。パワーと柔軟性を備えた足で自分を撃つのは簡単です。

面倒？Rubyには、非常に読みやすい、または中断できない機能があります。Bashスクリプトに属しているように見えるコードを見てきました。

悪い習慣？知恵よりも賢明さを重視するRubyistもいます。彼らは自分の賢さを示すトリックを書いて共有していますが、これは読みにくくて壊れやすいコードを作成します。

余談ですが、Javascriptは設計上災害でした。「The Good Parts」の本は、その隠された美しさを抽出しようとしています。「それを行うには複数の方法があります」（つまり、柔軟性）を普及させた言語であるPerlには、「Perl、Best Practices」に似た本があります。Perlの歴史は実験の1つであり、経験を積んだ経験があり、「ベストプラクティス」はその知識を表しています。Perl 6は、その知識などに基づいて言語を再起動することになると思います。Rubyも同様の問題に苦しむ可能性があります。

@Jamesとforループ... ruby​​でforループを実行すると、「。each」が呼び出されます。したがって、「for」は、Cスタイルのループに慣れている人にとっては構文上の砂糖です。しかし、Rubyistとしては、常に.map、.inject、.each_with_objectなどのイテレーターを使用します。rubyで "i = 0; i> 6; i ++"のようなforループを記述する必要は決してないので、習慣を落とすことになります。@andrew ...雄弁なルビーはループを支持しません。

これは言語よりもプログラマーのことですが、Rubyプログラマーがループを嫌うのはなぜですか？

Rubyには次の特徴があります。

someCollection.each do |item|
   ...
end

しかし、forループがまったく同じことをしない状況で使用されるのを見たことはありません。

私は何度か尋ねましたが、これに対する良い答えは一度もありませんでした。

それが単なるスタイルのことなら、私はそれを受け入れてうれしいですが、Rubyプログラマーがこれについて本当にうまくいくのを見て、本当に興味があります。

他の言語との後方互換性のためだけに追加されたものは、通常避けたいと思います。たとえば、Perlismsおよびfor x in y。