Dies ist eine (n) historische Frage, keine Frage zwischen zwei Sprachen:
Dieser Artikel von 2005 berichtet über das Fehlen eines zentralen Rahmens für Python. Für Ruby ist dieses Framework eindeutig Rails. Warum ist das historisch gesehen für Ruby passiert, aber nicht für Python? (oder ist es passiert, und dieses Framework ist Django?)
Auch die hypothetischen Fragen: Würde Python beliebter sein, wenn es ein gutes Framework hätte? Wäre Ruby weniger populär, wenn es kein zentrales Framework hätte?
[Bitte vermeiden Sie Diskussionen darüber, ob Ruby oder Python besser sind, was einfach zu offen ist, um zu antworten.]
Bearbeiten: Obwohl ich dachte, dass das offensichtlich ist, sage ich nicht, dass andere Frameworks für Ruby nicht existieren, sondern eher die große in Bezug auf Popularität ist Schienen. Außerdem sollte ich erwähnen, dass ich nicht sage, dass Frameworks für Python nicht so gut (oder besser) sind wie Rails. Jeder Rahmen hat seine Vor- und Nachteile, aber Rails scheint, wie Ben Blank in einem der folgenden Kommentare sagt, Ruby hinsichtlich der Popularität übertroffen zu haben. Auf der Python-Seite gibt es dafür keine Beispiele. WARUM? Das ist die Frage.
Wie ich es sehe, hat Rails Ruby auf die Karte gesetzt. Die einfache Tatsache ist, dass Ruby vor Rails eine kleine esoterische Sprache war, mit sehr wenig Adoption. Ruby verdankt seinen Erfolg Rails. Als solches hat Rails einen zentralen Platz im Ruby-Ökosystem. Wie es heißt, gibt es andere Web-Frameworks, aber es wird sehr schwierig sein, Rails als Marktführer zu überholen.
Python andererseits hatte eine sehr unterschiedliche Annahmekurve. Vor Rails war Python weit verbreiteter als Ruby und hatte daher eine Reihe konkurrierender Web-Frameworks, von denen jedes langsam seine Interessengruppen aufbaute. Django hat einen guten Job dabei gemacht, die Unterstützung zu konsolidieren und der Führer in der Python-Web-Framework-Welt zu werden, aber es wird niemals das One True Framework sein, einfach wegen der Art, wie sich die Community entwickelt hat.
Die wirkliche technische Antwort ist, dass es in Python drei Hauptansätze für die Web-Entwicklung gibt: Eine ist CGI-basiert, wo die Anwendung wie eine alte, einmalige Perl-Anwendung für CGI oder FastCGI, z. Trac ; dann gibt es Zope , das ist ein Bizarro-Overengineering-Framework mit einem eigenen DB-Konzept, einem seltsamen fehlgeleiteten Software-Entwicklungskonzept für das Internet usw. (aber Plone ist immer noch ziemlich beliebt); und dann gibt es Django (und Turbogears , usw.), die von der gleichen Philosophie geleitet werden, die nur die Werkzeuge benötigt, wie Rails (it kann argumentiert werden, wer zuerst da war oder wer es besser gemacht hat). Viele Leute würden wahrscheinlich zustimmen, dass der Django / Rails / CakePHP Ansatz besser ist als der ältere Ansatz, aber als ältere Sprache hat Python viel mehr Legacy-Frameworks, die immer noch versuchen, sich zu entwickeln und relevant zu bleiben. Diese Frameworks bleiben bestehen, da es bereits Entwickler-Buy-Ins für sie gibt. Zum Beispiel würden viele Leute im Nachhinein sagen, dass Zope (vor allem ZODB) ein schrecklicher Fehler war, aber Zope 3 ist viel besser als Zope 2, und es gibt bereits ganze Firmen, die mit Zope-Technologien arbeiten.
Rails war in seinem extremen "convention over configuration" -Ansatz etwas revolutionär, was es von so ziemlich jedem anderen unterscheidet und es zur "Killer-App" von Ruby machte, was viele Leute dazu brachte, Ruby überhaupt zu bemerken.
Die Frage ist also wirklich "Warum hat sich David Hansson entschieden, Rails in Ruby statt in Python zu schreiben?"
Denken Sie daran, dass Ruby schon lange existierte, bevor Rails erstellt wurde. Laut Wikipedia wurde Ruby Mitte der 90er Jahre gegründet. Rails gab es erst 2004. Ruby ist einfach die Sprache, die David Hansson für Rails verwendet hat.
Und ja, ich würde sagen, Ruby ist für Rails wie Python für Django .
Ich stimme Ned zu. Ich würde wetten, dass mehr als 90% der Ruby-Installationen zu keinem anderen Zweck als dem Ausführen von Rails dienen. Rails dominiert Ruby - es gibt keine einzige Anwendung, die Python dominiert, hauptsächlich weil die Python-Community etwas größer ist als die Ruby-Community.
Würde Rubin ohne Rails weniger populär sein? absolut.
Wäre Python mit einem echten Framework beliebter? Du meinst im Gegensatz zu mehreren? Vielleicht, wer weiß. In jedem Fall stimmen Django sehr gut überein.
Warum ist es Ruby seit jeher passiert? Weil DHH Ruby nach seiner eigenen Forschung ausgewählt hat.
Um zu der Antwort zu kommen, dass Rails aufgrund von "Konvention über Konfiguration" einen Durchbruch erzielt hat, gibt es noch einen anderen Grund und das ist, dass Rails die Meta-Programmierfähigkeiten von Ruby hervorragend genutzt hat. Ein Großteil der Magie von Rails, die dazu beigetragen hat, die Schmerzen bei der Entwicklung von Web-Apps zu beseitigen, kam durch den cleveren Einsatz der Ruby-Meta-Programmierung.
Ich würde zugeben müssen, dass Django im Grunde genommen das "Rails for Python" Äquivalent ist. Warum hat es so lange gedauert? Die einfache Antwort ist zu viele Optionen.
In Python gibt es viele Request / Response-Systeme, URL-Rewriter, ORMs, Templating-Sprachen usw., mit denen Sie einen Web-Stack in Dutzenden verschiedener Konfigurationen erstellen können. Pylons und TurboGears bieten einen zuverlässigen, vorhersagbaren Stack zum Erstellen von MVC-Web-Apps.
Was Django anders gemacht hat, war, dass sie alles eingekapselt haben. Anstatt die Komponentenroute zu gehen, bauten sie ein zusammenhängendes System auf. Sie bauten ihr eigenes ORM, ihre eigene Template-Sprache, ihr eigenes Middleware-System usw. Sie argumentierten, dass es für Python kein einheitliches System wie dieses gab.
Python ist kein One-Trick-Pony. Daher gibt es keinen einzigen "zentralen Rahmen" dafür. Viele Leute hörten zuerst von Python als "eine andere nette OO-Sprache" oder durch eine der vielen Anwendungen, in die es eingefügt wurde.
Um fair zu sein, Ruby ist auch kein One-Trick-Pony. Es ist nur so, dass viele Leute Rails als die "Killer-App" betrachteten, die sie dazu brachte, eine vorher nicht bekannte Sprache zu betrachten. Ich vermute, dass viele Leute noch nie von Ruby vor Rails gehört haben, aber das ist bei weitem nicht das Einzige, was Ruby tun kann.
Wenn Sie den Nachrichten gefolgt sind, haben Sie gelesen, dass Merb und Rails zusammengeführt werden. Dies ist ein guter Zug IMHO. Ich denke, das liegt am gemeinsamen Ziel der Entwickler: Sie wollen ein einfaches Framework für webdev, das mit einem OR-Mapper, Routing, einer Template-Sprache usw. ausgestattet ist, die für die meisten Aufgaben geeignet ist.
Sieh dir diesen Artikel auf an, warum wir Python-on-Rails nie sehen werden . Der Autor gibt einige der grundlegenden Gründe, warum Python niemals hatte und niemals ein zentrales Framework haben wird. Ich könnte hinzufügen, dass Java auch keines hat und aus den gleichen Gründen.
Nach Ansicht des Autors ist Rails streng an seine "Implementierung" gebunden, die Ruby ist. Rails wurde von vielen Entwicklern übernommen und Ruby war nur ein Teil davon. Rails funktioniert perfekt auf Ruby (oder Ruby Möchtegern wie Groovy), aber noch wichtiger, wie viele andere Antworten sagen, führte Rails den Weg zu Ruby Adoption.
Aus diesem Grund wird Rails-for-Python nicht funktionieren Arbeit oder zumindest was Menschen haben Fokussierung auf Schienen ist nicht richtig. Es geht nicht um die Umsetzung oder die Qualität der Rahmen, es geht um das Muster von Annahme. Es geht darum, die Rahmen vor und die Implementierung in den Rücken - auch wenn Das waren nicht die Rails-Entwickler Absichten (obwohl sie es vielleicht sind) schlau und das war ihre Absicht).
Im Grunde genommen kann man eine Gruppe sprachbegeisterter Leute nicht dazu bringen, sich um einen einzigen Rahmen zu versammeln. Auf der Java-Seite, während Spring sehr beliebt ist, ist es in Bezug auf Popularität in der Java-Community kein Rails. In einer reifen Community haben Entwickler ihre eigenen Ideen darüber, welche Metaphern funktionieren und nicht in einem Framework funktionieren. Dies ist der Grund, warum Rails zu Ruby führt und nicht umgekehrt (typischerweise meistens nicht in allen Fällen).
Tags und Links python ruby ruby-on-rails frameworks history