PHP vs. Ruby
Nein, hier folgt jetzt kein ausführlicher Artikel. Der Vergleich des ersten Eindrucks der jeweiligen Websites reicht völlig aus …
php.net vs. ruby-lang.org
Na, fällt euch was auf? Tja. Klarheit, Einfachheit und Schönheit sind im Vergleich zu PHP nicht nur Merkmale der Website zu Ruby, sondern genauso der Sprache selbst.
Den meisten Hype erfährt Ruby im Moment natürlich durch Rails, wovon mittlerweile jeder Webentwickler mindestens schonmal gehört haben sollte. Kein Wunder – wer einmal etwas ausführlicher den Code von z.B. WordPress und Mephisto vergleicht, der will (sofern er es mal gemacht hat) wahrscheinlich nie wieder PHP für eine neue Applikation benutzen.
Mein Tipp für alle, die in Ruby on Rails einsteigen wollen oder es auch schonmal kurz angeschaut, aber vorschnell wieder zur Seite gelegt haben: Schaut Euch unbedingt erst Ruby selbst an! In nichtmal einer Stunde lässt sich im Prinzip die ganze Sprache beherrschen (oder zumindest lesen), was das Verstehen von Rails extrem vereinfacht und Ochs-vorm-Berg-Effekte im Vorraus vermeidet. Besonders empfehlenswert ist dieses interaktive Tutorial, bei dem man in ca. 20 Minuten alle Bestandteile der Sprache benutzt und erlernt. Alles weitere (also z.B. die Namen der Methoden etc.) muss man dann bei Bedarf nur noch kurz nachschlagen, und Ruby on Rails wird danach wirklich zu einem gar himmlischen Vergnügen. Versprochen.
P.S.: Python bzw. Django hab ich mir noch nicht angeschaut, soll aber auch nicht schlecht sein. CakePHP ist natürlich auch ne Alternative zu Rails, aber es ist eben immer noch hässliches PHP.
Am 8. März 2007 um 00:05 Uhr
Danke für den Tipp — ich bin seit über 6 Monaten immer wieder ein bisschen am herumbasteln mit Rails, doch dabei ist es bisher geblieben. Einfach kein Rubyskill da ;-)
Am 11. April 2007 um 23:31 Uhr
mich würde ja schon interessieren, was du für ein problem mit php hast? scheinst ja eine richtige abneigung gg php zu haben… ;-)
ok, wenn ich ein framework (für welche sprache auch immer) einsetze, wird der code natürlich übersichtlicher und leserlicher, liegt aber meiner meinung nach nicht an der syntax der sprache (so viel zu hässlichem PHP), sondern daran, dass man bei der verwendung von frameworks meistens auf objektorientierung zurückgreift, wodurch man schon z.B. über die namen der objektmethoden weiß wie man ein objekt zu “bedienen” hat und was über den aufruf geschieht (klar, dass das einfacher zu verstehen ist, als wenn ich diese funktionalität erst selbst implementieren muss). und derjenige, der sich diese frameworks ausgedacht hat, muss auch mit hässlichem XXX programmieren – außer er benutzt ein framework um sein framework zu bauen ;-) wenn ich nur geringfügig über den tellerrand raus programmieren will, muss ich die sprache ja trotzdem wieder beherrschen und dann bist du bei “hässlichem ruby” bzw. “hässlichem python” angelangt.
python habe ich für webprogrammierung noch nicht verwendet, sondern bisher nur als scriptsprache für meine 3d-software. aber naja – habe mal gelesen dass die google-suche auf python basiert… daher wirds schon nicht ganz schlecht sein :-)
Am 12. April 2007 um 19:28 Uhr
Ich bin mir nicht sicher, ob du meinen Beitrag aufmerksam genug gelesen hast. Jedenfalls geht es grundsätzlich nicht um Frameworks, sondern um die Sprachen selbst, und da ist Ruby im direkten Vergleich nunmal kompakter, einfacher, schöner. Das hat rein gar nichts mit Rails zu tun, obwohl die Philosophie der Sprache sich durchaus auch im Aufbau des Frameworks widerspiegelt.
Wie dem auch sei, ich wüsste nicht wie man beim Erweitern des Frameworks zu “hässlichem Ruby” gelangen könnte, obwohl Schönheit natürlich im Auge des Betrachters liegt und somit jeglicher Diskussion entbehrt. Was ich für eine schöne Sprache halte, musst du ja nicht unbedingt mögen. Dass man im Vergleich zu PHP mit extrem viel weniger Zeichen auskommt, ist jedoch eine Tatsache.
Am 20. April 2007 um 10:36 Uhr
Gerade noch im weiteren Sinne zum Thema gefunden:
http://t-a-w.blogspot.com/2007/02/right-to-criticize-programming.html
Am 4. Mai 2007 um 23:38 Uhr
[...] [via Sebastian Kippe] [...]
Am 18. September 2008 um 16:35 Uhr
Es ist nicht alles Gold was glänzt.
Seit deinem Beitrag sind schon ein paar Monate vergangen … und wenn ich mir nun mal anschaue mit welchen Problemen z.B. Twitter (in Ruby programmiert) zu kämpfen hat, dann wird klar, dass Aussehen alleine im Programmierbereich “überhaupt nichts” aussagt!
Es kommt immer darauf an, für welche Art von Projekte man eine Programmiersprache einsetzen will und vor allem auch wie einfach man es haben will.
PHP ist immer noch Standard und so sieht es auch in Sachen Serverstrukturen aus. Es ist immer noch um einiges leichter einen PHP-Ready Server zu finden, als einen Ruby-Ready Server.
Bei kleinen Projekten macht Ruby eventuell schon Sinn (und genau deshalb schau ich es mir auch gerade an) aber wenn es was großes sein soll, dann würde ich die Wahl nochmal genau überdenken.
(genau deshalb habe ich diesen Artikel gefunden g)
Gruß,
Stefan
Am 18. September 2008 um 16:47 Uhr
Sorry, aber Twitter ist dann auch das einzige Beispiel, das Kritiker über die Dauer nennen konnten – dafür so oft, dass es jedem in der Community nur noch zum Hals raushängt. Man mag nicht 100x erklären, warum das nichts mit Ruby an sich zu tun hat.
Über den gleichen Zeitraum haben übrigens auch viele große Unternehmen die Vorteile der Sprache für sich entdeckt und es gibt mittlerweile genug Beispiele für die anstandslose Skalierbarkeit von Ruby. Außerdem gibt es mit Phusion Passenger a.k.a mod_rails mittlerweile ein kinderleicht zu installierendes Apache-Modul, welches das Hosting genauso einfach wie bei PHP-Projekten macht. Des weiteren arbeiten verschiedene Firmen an alternativen Interpretern und VMs, wie z.B. Sun an jRuby. Aber das nur am Rande.
Was ich sagen will: Hohe Performanz und Skalierbarkeit sind kein konkreter Vor- oder Nachteil der einen oder anderen Sprache, sondern ausschließlich durch eine durchdachte, auf das jeweilige Projekt zugeschnittene Architektur zu erreichen. Das betrifft sowohl Hardware als auch Software, und sowohl die Umgebung wie auch die Applikation selbst.