Offizielle Ruby FAQ

Wenn Sie Fehler melden oder Verbesserungen für diese FAQ vorschlagen möchten, besuchen Sie bitte unser GitHub-Repository und öffnen Sie ein Issue oder einen Pull Request.

Wie schneidet Ruby im Vergleich ab mit…?

Wie vergleicht sich Ruby mit Python?

Python und Ruby sind beides objektorientierte Sprachen, die einen reibungslosen Übergang von prozeduralen zu objektorientierten Programmierstilen ermöglichen. Smalltalk hingegen ist rein objektorientiert – man kann nichts tun, bis man Objekte, Vererbung und die umfangreiche Smalltalk-Klassenhierarchie verstanden hat. Durch das Bereitstellen von prozeduralen Trainingsrädern "korrigieren" Python und Ruby eines der Merkmale, die Smalltalk möglicherweise vom Mainstream ferngehalten haben. Die beiden Sprachen unterscheiden sich dadurch, dass sie diese Lösung aus entgegengesetzten Richtungen angehen.

Python ist eine hybride Sprache. Sie verfügt über Funktionen für die prozedurale Programmierung und Objekte für die objektorientierte Programmierung. Python überbrückt die beiden Welten, indem es ermöglicht, dass Funktionen und Methoden durch den expliziten self-Parameter jeder Methoden-Definition konvertiert werden. Wenn eine Funktion in ein Objekt eingefügt wird, wird das erste Argument automatisch zu einer Referenz auf den Empfänger.

Ruby ist eine reine objektorientierte Sprache, die sich als prozedurale tarnen kann. Sie hat keine Funktionen, nur Methodenaufrufe. In einer Ruby-Methode ist der Empfänger, auch self genannt, ein versteckter Parameter wie this in C++. Eine def-Anweisung außerhalb einer Klassendefinition, die in Python eine Funktion definiert, definiert in Ruby tatsächlich eine Methode. Diese Ersatzfunktionen werden zu privaten Methoden der Klasse Object, der Wurzel der Ruby-Klassenhierarchie. Prozedurale Programmierung wird auf die andere Art gelöst – alles ist ein Objekt. Wenn der Benutzer Objekte noch nicht versteht, kann er einfach so tun, als wäre def eine Funktionsdefinition und trotzdem nützliche Arbeit leisten.

Rubys objektorientierte Reinheit bietet eine Reihe von Funktionen, die Python fehlen oder die es noch entwickelt: eine einheitliche Typ-/Klassenhierarchie, Metaklassen, die Möglichkeit, alles zu unterklassifizieren, und eine einheitliche Methodenaufrufung (nicht dieser Unsinn von len() ist eine Funktion, aber items() ist eine Methode). Ruby unterstützt, wie Smalltalk, nur Einfachvererbung, hat aber ein sehr mächtiges Mixin-Konzept: Eine Klassendefinition kann ein Modul enthalten, das die Methoden, Konstanten usw. dieses Moduls in die Klasse einfügt.

Ruby bietet, wieder wie Smalltalk, Closures und Codeblöcke und nutzt sie mit demselben guten Effekt. Die Ruby-Klassensammlungen und Iteratoren sind hervorragend, viel mächtiger und eleganter als die Ad-hoc-Lösungen, die Python sprießen lässt (Lambdas und Listenkomprehensionen).

Rubys Syntax und Designphilosophie sind stark von Perl beeinflusst. Es gibt eine große syntaktische Variabilität. Anweisungsmodifikatoren (if, unless, while, until usw.) können am Ende jeder Anweisung stehen. Einige Schlüsselwörter sind optional (z.B. then in einer if-Anweisung). Klammern können bei Methodenaufrufen manchmal weggelassen werden. Der Empfänger einer Methode kann in der Regel weggelassen werden. Viele, viele Dinge sind direkt von Perl übernommen. Eingebaute reguläre Ausdrücke, $_ und Freunde, Here-Dokumente, die Unterscheidung zwischen ein- und doppelt geführten Strings, Präfixe wie $ und @ zur Unterscheidung verschiedener Arten von Namen und so weiter.

Wenn Sie Perl mögen, werden Sie Ruby mögen und sich mit seiner Syntax wohlfühlen. Wenn Sie Smalltalk mögen, werden Sie Ruby mögen und sich mit seinen Semantiken wohlfühlen. Wenn Sie Python mögen, werden Sie vielleicht von der riesigen Differenz in der Designphilosophie zwischen Python und Ruby/Perl abgeschreckt oder auch nicht.

Ruby ist viel komplexer als Python, aber seine Funktionen hängen größtenteils gut zusammen. Ruby ist gut durchdacht und voller cooler Ideen, die man für P3K nutzen könnte. Ich bin mir nicht sicher, wie viele Python-Programmierer sich davon angezogen fühlen werden – es hat mich (noch) nicht überzeugt. Aber es ist ernsthafter Studie würdig und könnte eine echte Bedrohung für Perl darstellen.

Gepostet von John Dell’Aquila in comp.lang.python, 17.11.2000. Mit Erlaubnis reproduziert.