Ein neuer Blick auf Rails und Ruby

Drei Entwickler, die Ruby und Rails verwendet haben, geben hier ihr ungefiltertes Feedback ab. Hier ist zu lesen, was die Entwickler, die alle hoch geachtet werden, zu sagen haben.

Sterling Camden

„Ich programmiere fast täglich in Ruby. Es ist meine bevorzugte Sprache für Hochleistungsscripting (im Wesentlichen alles, was sh nicht so leicht kann) und hat Perl mehr oder weniger in meinem Werkzeugarsenal ersetzt. Ich mag Ruby als Sprache, weil es objektorientiert ist, wenn ich es brauche, und nicht objektorientiert, wenn ich es nicht brauche. Ich kann mich an Vorgaben nach dem Muster von FP halten – oder ich kann cheaten und Vorgaben machen, wenn das die angemessene Lösung für das Problem zu sein scheint. Das Prinzip der geringsten Überraschung bedeutet, dass Ruby im Wesentlichen eine menschliche Sprache ist, manchmal sind die genauen Regeln schwierig zu artikulieren, doch sind sie normalerweise so, wie man es in jeder bestimmten Situation erwarten würde.

Ich habe ein wenig mit Rails gearbeitet, aber nicht annähernd so viel wie mit Ruby ohne Rails. Ich fand den Einstieg in Rails einfach, aber es war viel schwieriger, es gründlich zu lernen. Viel vom Verhalten von Rails scheint sich hinter den Kulissen abzuspielen. Das steht im Gegensatz zu meiner Erfahrung mit Django, das mir extrem transparent implementiert zu sein scheint. Meine Analyse ist hochgradig unwissenschaftlich und ist möglicherweise durch den Punkt meines Lernens gefärbt, an dem ich den einzelnen Frameworks begegnet bin. Ich muss mir Rails noch einmal ansehen, um meine Kenntnis auf Version 3 zu aktualisieren (gerade auf FreeBSD portiert, ich verstehe!) – dem Vernehmen nach sind manche Dinge bei dieser Version viel vernünftiger implementiert.“

Chad Perrin

„Es war zwar Rails, das zuerst mein Interesse auf Ruby lenkte, doch blieb ich bei der Sprache. Tatsächlich dauerte es nicht lange, bis ich Rails komplett aufgab, weil Rails für den überwiegenden Teil meiner Arbeit – selbst für Web-Entwicklung – das falsche Werkzeug war. Jemand anders mag andere Erfahrungen gemacht haben.

Ruby ist eine extrem flexible Sprache mit einem Objekt-Modell, das sich sehr natürlich anfühlt und das ich immer in Reichweite habe, mit ordentlicher Unterstützung sowohl für Metaprogrammierung wie für funktionelle Programmierung sowie einer ausgezeichneten Community von kompetenten Entwicklern dahinter. Zu den vielen Gründen, aus denen ich es verwende, zählen die Weise, in der es elegante Einfachheit und Klarheit des Codes fördert, und die Tatsache, dass Programmieren in Ruby so etwas wie ein erfreuendes Erlebnis ist.

Ehrlich, wegen Ruby bin ich ein glücklicher Programmierer. Mit Ruby kann ich wirklich eleganten Code schreiben, der sich wie Poesie liest, und es ermuntert mich, elegante Lösungen zu schreiben, die magisch erscheinen, ohne die Pflegbarkeit von gut geschriebenem Code einzubüßen, der leicht zu verstehen und zu durchdenken ist.

Natürlich ist es keine perfekte Sprache. Sein größter Fehler ist wahrscheinlich seine Geschwindigkeit, die alles andere als spektakulär ist. Meistens, wenn es ein Problem mit der Geschwindigkeit gibt, stelle ich fest, dass der Algorithmus, den ich gewählt habe, ein viel größeres Problem ist als die Sprache, doch wenn ich etwas Schnelleres brauche, wähle ich einfach eine andere Sprache. Natürlich sollen neuere Versionen von Ruby die Ausführung erheblich beschleunigen, so dass Ruby wahrscheinlich zumindest mit Python gleichzieht, doch habe ich v1.9 noch nicht wirklich ausprobiert.

Anders als bei Sterling hat es für mich Perl noch nicht ersetzt. Ich habe Verwendung für beide, und meine Ansicht bezüglich der Brauchbarkeit von Perl wurde nicht dadurch geschmälert, dass ich Ruby verwende. Jede Sprache gibt mir etwas, was die andere nicht kann, und ich behalte beide in meinem „Werkzeugkasten“, um sie bei passender Gelegenheit zu verwenden.“

Mathew O’Hare
„Das Rails-Framework ist eine große Hilfe bei der Web-Entwicklung. Ich komme von der Anwendungsentwicklung her, daher betrachte ich etwas Neues von der Entwicklerseite aus. ActionPack (die View- und Controller-Komponenten von Model View Controller) stellt eine bildschirmorientierte Entwicklungsplattform bereit. Ich ordne meine Bildschirme um verschiedene Positionen von Geschäftsdaten an. ActionPack unterstützt natürlich alle grundlegenden Aktionen in Bezug auf Daten. Dadurch wird es zum Kinderspiel.

Lassen Sie mich ein Beispiel für eine Bücherbestandsanwendung geben. Wir machen eine Controller-Klasse für Bücher. In der Klasse erstellen wir öffentliche Methoden für die Anzeige, das Löschen, Bearbeiten und Hinzufügen von Büchern. Das wird in einem nativen Ruby-Script geschehen. Dann erstellen wir eine Ansicht für jede der Methoden (indem wir Ruby weitgehend genauso verwenden, wie man eingebettetes PHP verwenden würde). Rails wickelt alle URLs, Datenbank-Aktualisierungen und viele der Sicherheitsangelegenheiten ab.

Das einzige Problem, das ich mit Rails habe, ist die ActiveRecord-Klasse. Das Paradigma von Rails ist, die meisten Datenbank-Aktionen in Code abzuwickeln. Ich bin ein Datenbank-Purist, daher würde ich zugunsten der Sicherheit der Daten die Datenbank-Engine mehr Arbeit machen lassen. Doch ist dies ein niedriger Preis für all die Vorteile, die das ActionPack als Teil des Rails-Frameworks bietet.“

Fazit

Nach der Lektüre der Feedbacks dieser Entwickler scheint es, als sei Ruby selbst der Gewinner, während Rails nicht für jeden etwas ist. Interessant ist, dass die allgemeinen Einwände von Sterling und Mathew darauf zielen, dass Rails ihnen die Kontrolle nimmt. Es bleibt spannend, ob Rails 3.0 mit seiner Betonung der Erweiterbarkeit, Modularität und größeren Kontrolle für die Entwickler die Meinungen der Entwickler über Rails ändern wird.