Ruby: The Bad Parts [geschlossen]

Ich habe kürzlich Crockfords Buch "Javascript: The Good Parts" gelesen und eine der zugrunde liegenden Prämissen war, dass Programmiersprachen schlechte Sätze von Funktionen haben können, die Programmierer vermeiden sollten.

Ich bin ein Rubinist und obwohl ich die Sprache liebe, ist es immer wertvoll, eine Perspektive zu bekommen. Also, was sehen Sie als das schlechteste Merkmal (zB Methoden, Klassen, Methoden) in Ruby? Ich möchte hier keine Auseinandersetzung über die Vorzüge der Sprache selbst oder über ihre Geschwindigkeit usw. beginnen. Ich würde eher eine Diskussion darüber bevorzugen, welche Funktionen Sie aufgrund früherer Erfahrungen für gefährlich / lästig / schmerzhaft halten.

Sie sollten sich Python vs Ruby ansehen : Eine Schlacht zum Tod von Gary Bernhardt. Er macht das Zitat:

Genau die Dinge, die ich in Ruby als hässlich empfinde, ermöglichen erstaunliche Ruby-Software wie RSpec, die Python (bei der aktuellen Implementierung) niemals haben könnte.

Während er viel über Python spricht, berührt er eine Menge Dinge, die in Ruby nur seltsam sind. Eines der großen übergreifenden Themen ist das Patchen von Affen .

Ruby-Objekte (im Gegensatz zu Objekten in anderen objektorientierten Sprachen) können individuell geändert werden. Sie können Methoden immer auf Objektbasis hinzufügen. In Ruby können das Verhalten oder die Funktionen eines Objekts von denen der Klasse abweichen.

Obwohl dies viel Flexibilität bietet und einige der beliebtesten und kompliziertesten Juwelen von Ruby unterstützt, kann es Sie in den Hintern beißen, wenn Sie versuchen, ein Problem zu debuggen, ohne zu bemerken, dass eine Bibliothek irgendwo eine Kernmethode geändert hat.

Manche Leute denken nur an Rubin in Bezug auf Rubin auf Schienen und es ist irgendwie ärgerlich, weil die Sprache für sich ziemlich gut steht.

Ich denke, das Schlimmste ist open classes, dass Sie das Verhalten aller aktuellen und zukünftigen Instanzen der geänderten Klasse global ändern können.

Der problematische Teil dieser Funktion besteht darin, dass diese (globalen) Änderungen zur Laufzeit auftreten, wenn der Ruby-Interpreter auf die Definition stößt. Dies kann lange dauern, nachdem Sie bereits einige Objekte instanziiert haben, die nun plötzlich ihr Verhalten ändern.

In einer großen Codebasis kann dies zu sehr, sehr schwer auffindbaren Fehlern führen - zumal dies durch Rubys schwache Debug-Story (im Vergleich zu z. B. der CLR oder JVM) und die Verwendung anderer Funktionen (z. B. eval) in diesem Kontext verstärkt wird Es ist ziemlich schwierig, den Ort zu finden, an dem diese globale Veränderung stattgefunden hat. dh wenn Sie bereits den Punkt erreicht haben, an dem Sie vermuten, dass die „richtige“ Klasse die Störung verursacht hat! Nach meiner Erfahrung beginnt man normalerweise mit einer wilden Gänsejagd, da die Probleme anfangen, an einem Objekt aufzutauchen, das den wirklichen Täter benutzt.

Das Beste wäre also, entweder die Verwendung offener Klassen einzustellen ( #extendund die Änderungen in ein zu setzen, Moduleist meiner Meinung nach viel sicherer, einfacher zu verstehen und besser zu testen) oder wenn Folgendes nicht vermieden werden kann:

• Klassen nur mit neuem Verhalten erweitern (dh bestehendes Verhalten nicht überschreiben)
• haben eine definierte Stelle im Quelltextbaum, an der alle Erweiterungen mit offenen Klassen platziert werden müssen
• Verwenden Sie #evalund friends nicht, um offene Klassen zu erstellen
• Stellen Sie alle Verwendungen offener Klassen in ein großes, sichtbares Diagramm, in dem alle Entwickler sie sehen können - und machen Sie klar, dass alle Änderungen an ihnen „architektonische Entscheidungen“ sind, die sich auf die gesamte Codebasis auswirken (was sie tun) und nicht den Ort für nützliche schnelle Hacks für Ihre aktuelle Aufgabe

Größter Grund, warum ich Ruby nicht benutze: Es ist langsamer als Melasse im Januar am Nordpol während einer Eiszeit. Benchmarking von Sprachen ist eine ungenaue Wissenschaft, aber Ruby erscheint drastisch langsamer als selbst JavaScript und Python.

Wenn dies auf Ruby on Rails erweitert werden kann, dann:

1. Die Tatsache, dass die Datenbanklogik jeder einzelnen Tabelle einen auto_incrementPrimärschlüssel gibt, einschließlich Tabellen, die diese nicht benötigen und nicht benötigen sollten.

2. Die Tatsache, dass zusammengesetzte Schlüssel überhaupt nicht unterstützt werden.

Für Ruby wäre meine Beschwerde dieselbe wie für jede Sprache, bei der Sicherheit gegen Ausdrucksstärke getauscht wird. Es ist einfach, mit nur wenig Code viel zu tun, aber es ist genauso einfach, mit jeder Menge Code ein großes Durcheinander zu machen.

Ruby umfasst Metaprogrammierung (Reflektion, Selbstbeobachtung), Multiparadigma-Programmierung und Dynamik auf einer ungewöhnlichen Ebene. Es ist einfach, sich mit Kraft und Flexibilität in den Fuß zu schießen.

Lästig? Ruby hat die Fähigkeit, extrem lesbar oder unterbrechungsfrei zu sein. Ich habe Code gesehen, der aussieht, als gehörte er in ein Bash-Skript.

Schlechte Praktiken? Einige Rubinisten schätzen Klugheit über Weisheit. Sie schreiben und teilen Tricks, die ihre Klugheit demonstrieren, aber dies schafft unlesbaren und fragilen Code.

Nebenbei bemerkt: Javascript war von Natur aus eine Katastrophe, und das Buch "The Good Parts" versucht, seine verborgene Schönheit zu extrahieren. Perl, eine Sprache, die "Es gibt mehr als einen Weg, es zu tun" (dh Flexibilität) populär machte, hat ein ähnliches Buch in "Perl, Best Practices". Perls Geschichte basiert auf Experimenten und hart erarbeiteten Erfahrungen. "Best Practices" stehen für sein Wissen. Perl 6 wird meiner Meinung nach ein Neustart der Sprache sein, der auf diesen Kenntnissen und mehr basiert. Ruby kann unter ähnlichen Problemen leiden.

@James und for-Schleifen ... Wenn Sie eine for-Schleife in Ruby ausführen, wird ".each" aufgerufen. Daher ist "for" syntaktischer Zucker für Personen, die sich mit C-Schleifen wohler fühlen. Aber als Rubyist werden Sie ständig Iteratoren wie .map, .inject, .each_with_object verwenden. Sie müssen niemals eine for-Schleife mit so etwas wie "i = 0; i> 6; i ++" in Ruby schreiben, und am Ende verlieren Sie die Gewohnheit. @andrew ... beredtes Rubin unterstützt keine Schleifen.

Hier geht es mehr um die Programmierer als um die Sprache, aber warum hassen Ruby-Programmierer Schleifen so sehr?

Mir ist klar, dass Ruby:

someCollection.each do |item|
   ...
end

aber ich habe noch nie gesehen, dass in Situationen, in denen eine for-Schleife nicht genau das gleiche tun würde.

Ich habe mehrmals gefragt und nie eine gute Antwort auf diese Frage bekommen.

Wenn es nur eine Art Sache ist, bin ich froh, das zu akzeptieren, aber ich habe gesehen, wie Ruby-Programmierer sich wirklich darüber aufgeregt haben, und ich bin wirklich neugierig.

Ich würde generell Dinge vermeiden, die hinzugefügt wurden, um mit anderen Sprachen abwärtskompatibel zu sein. Zum Beispiel Perlismen und for x in y.