Habe mich heute beim Durchblättern der bekannten OpenSorceDVD geärgert, dass in der Rubrik Programmierung wie selbstverständlich Ruby-Komponenten verfügbar waren, aber von Python keine Spur.
Gibt es einen Weg, dass auf diese DVD auch mal was für Python draufkommt (außer dort schon vorhandenen Editoren, die auch Python-Syntax farblich unterstützen)?
Und falls kein Weg dorthin führt wäre es doch eine schöne Hilfe, wenn wir gemeinsam mal eine PythonDVD als iso-Datei kreieren könnten. Damit ein Einsteiger mal ein richtiges "SuperStartpaket" mit wichtigen Modulen und Lesestoff zum Einstieg in die Hände bekommt?
Oder gibt es das alles schon und ich bin bloß noch nie darüber gestolpert?
wie Python voranbringen?
Wenn man dem TIOBE Index glauben darf, ist Python zwar die sechstbeliebteste Programmiersprache und damit fast doppelt so beliebt wie Ruby, aber bei Python fehlt irgendwie die Leuchtturm-Anwendung, wie es Rails in der Ruby-Welt ist. Es gibt einen Haufen Python-Web-Frameworks, aber so richtig überzeugend finde ich keins. Und ich glaube, genau so ein Zugpferd würde Python unheimlich gut tun!
Als Rails-Konkurrenten kämen wohl im Wesentlichen Django, TurboGears und Pylons in Frage. Bei allen drei stört mich, dass die Domain-Objekte nicht im Mittelpunkt stehen und sowas wie Validierung auf der Darstellungsebene geschieht. Djano hat noch dazu eine ORM-Lösung, der ich wenig vertraue. Pylons ist technisch interessanter, aber es ist einfach nicht besonders bedienungsfreundlich. TurboGears spielt nach einem guten Start praktisch keine Rolle mehr, weil das Projekt keine klare Linie hat.
Auch wenn es schon viele Python-Frameworks gibt, könnte das Python-Universum ein richtig sauber konzeptioniertes, von Grund auf neu geschriebenes Framework gut vertragen; vielleicht auch mit ganz neuen Ansätzen wie dem vonWicket.
Und wenn Python ein medienwirksames Zugpferd hat, kommen die Python-Sachen auch ganz von alleine auf solche DVDs.
Als Rails-Konkurrenten kämen wohl im Wesentlichen Django, TurboGears und Pylons in Frage. Bei allen drei stört mich, dass die Domain-Objekte nicht im Mittelpunkt stehen und sowas wie Validierung auf der Darstellungsebene geschieht. Djano hat noch dazu eine ORM-Lösung, der ich wenig vertraue. Pylons ist technisch interessanter, aber es ist einfach nicht besonders bedienungsfreundlich. TurboGears spielt nach einem guten Start praktisch keine Rolle mehr, weil das Projekt keine klare Linie hat.
Auch wenn es schon viele Python-Frameworks gibt, könnte das Python-Universum ein richtig sauber konzeptioniertes, von Grund auf neu geschriebenes Framework gut vertragen; vielleicht auch mit ganz neuen Ansätzen wie dem vonWicket.
Und wenn Python ein medienwirksames Zugpferd hat, kommen die Python-Sachen auch ganz von alleine auf solche DVDs.
-
BlackJack
@deamon: Dem möchte ich widersprechen. Wenn man die eine, tolle Leuchtturmanwendung hat, dann kann Python genauso gut mit der zusammen wieder in die "Bedeutungslosgkeit" fallen. Ich denke es ist besser, wenn es sich einfach auf breiter Front immer mehr überall einschleicht. Python ist für so ziemlich alles geeignet, was nicht gerade superviel Rechenleistung braucht, und selbst da kann man mit Modulen in C oder Fortran noch etwas machen, um wenigstens die übergeordnete Steuerung in einer angenehmen Hochsprache zu implementieren.
Ich kenne Rails nicht aus eigener Erfahrung, aber ich habe schon öfter gehört, dass man, wenn man "Rails lernt" nicht unbedingt auch Ruby lernt. Also eine ähnliche Situation wie bei Zope und Python.
Ich kenne Rails nicht aus eigener Erfahrung, aber ich habe schon öfter gehört, dass man, wenn man "Rails lernt" nicht unbedingt auch Ruby lernt. Also eine ähnliche Situation wie bei Zope und Python.
-
birkenfeld
- Python-Forum Veteran
- Beiträge: 1603
- Registriert: Montag 20. März 2006, 15:29
- Wohnort: Die aufstrebende Universitätsstadt bei München
Warum muss denn das "Zugpferd" unbedingt ein Web-Framework sein?deamon hat geschrieben:Als Rails-Konkurrenten kämen wohl im Wesentlichen Django, TurboGears und Pylons in Frage. Bei allen drei stört mich, dass die Domain-Objekte nicht im Mittelpunkt stehen und sowas wie Validierung auf der Darstellungsebene geschieht. Djano hat noch dazu eine ORM-Lösung, der ich wenig vertraue. Pylons ist technisch interessanter, aber es ist einfach nicht besonders bedienungsfreundlich. TurboGears spielt nach einem guten Start praktisch keine Rolle mehr, weil das Projekt keine klare Linie hat.
Natürlich sollte dieser "Leuchtturm" nicht das einzige starke Argument für eine Sprache oder Technologie sein. Aber so ein Leuchtturm ist eben unheimlich hilfreich, um anderen den Weg zu weisen. Wen sie den gefunden haben, werden sie noch viele andere schöne Dinge im Python-Land entdecken. Aber ohne Leuchtturm segeln sie vielleicht einfach vorbei ...
Ohne Rails würde außerhalb Japans keine Sau Ruby kennen. Ich finde es schade, dass Python trotz seiner langen Geschichte und der Eignung für das Web, dort nie im großen Stil eingesetzt wurde. Stattdessen hat die überaus hässliche Sprache PHP eine dominierende Stellung und in den letzten Jahren hat sich Ruby mit Rails seine Position erkämpft. Es gibt zwar auch Web-Entwicklung mit Python, aber die wird von vielen in ihrer Nische nicht wahrgenommen.
Das Zugpferd muss natürlich auch kein Web-Framework sein, aber ich denke, das wäre besonders attraktiv und außerdem habe ich da selbst schon was vermisst, was mich Web-Anwendungen in Python entwickeln ließe.
Ohne Rails würde außerhalb Japans keine Sau Ruby kennen. Ich finde es schade, dass Python trotz seiner langen Geschichte und der Eignung für das Web, dort nie im großen Stil eingesetzt wurde. Stattdessen hat die überaus hässliche Sprache PHP eine dominierende Stellung und in den letzten Jahren hat sich Ruby mit Rails seine Position erkämpft. Es gibt zwar auch Web-Entwicklung mit Python, aber die wird von vielen in ihrer Nische nicht wahrgenommen.
Das Zugpferd muss natürlich auch kein Web-Framework sein, aber ich denke, das wäre besonders attraktiv und außerdem habe ich da selbst schon was vermisst, was mich Web-Anwendungen in Python entwickeln ließe.
-
Leonidas
- Python-Forum Veteran
- Beiträge: 16025
- Registriert: Freitag 20. Juni 2003, 16:30
- Kontaktdaten:
Das stimmt so nicht. Ich (und viele andere) haben Ruby schon vor Rails verwendet, es gab auch mehrere Bücher, davon eines auf Deutsch (gut, das war katastrophal, aber immerhin). Eigentlich habe ich Ruby pünktlich zum Rails-Hype sein lassen und bereue es nicht mal so sehr, denn Rails hat die Sprache selbst zurückgedrängt (Ruby als Skriptsprache für Rails), ähnlich wie es seinerzeit bei Zope 2 passiert ist.deamon hat geschrieben:Ohne Rails würde außerhalb Japans keine Sau Ruby kennen.
Und man muss auch bedenken, dass Python gerade auch im Unix-Desktop-Bereich recht populär ist, es gibt einige Mediaplayer, IM-Clients, Konfigurationstools etc in Python, zudem wenn es für irgendwas Bindings für Skriptsprachen gibt, dann gibt es idR zuerst ein Python-Binding (insbesondere bei den freedesktop-Projekten habe ich so den Eindruck).
My god, it's full of CARs! | Leonidasvoice vs (former) Modvoice
Interessant finde ich - hinsichtlich des Fortschritts in und mit Python - eher die Fortentwicklung der Sprache an sich und beschleunigte Implementierungen (z. B. JIT in PyPy oder xtpython) oder auch andere Entwicklungen rund um den GIL (bzw. den loszuwerden). Ist doch spannend zu schauen, was davon wie den Weg in den "offziellen" Pythonzweig findet.
Und es gibt durchaus Firmen, die gerne Python einsetzten. Schön wäre dabei natürlich auch dies hier, wo ich gerade drüber gestolpert bin, aber ich befürchte ...
Gruß,
Christian
Und es gibt durchaus Firmen, die gerne Python einsetzten. Schön wäre dabei natürlich auch dies hier, wo ich gerade drüber gestolpert bin, aber ich befürchte ...
Gruß,
Christian
Der Fortschritt der Sprache und der Laufzeitumgebung ist sicher interessant, aber das ist kein Argument, was großartig neue Entwickler anlockt. Ruby ist meiner Meinung nach im Vergleich mit Python die schlechtere Sprache (allgemein konzeptionell) und hatte lange Zeit auch ziemlich miese Laufzeiteigenschaften, trotzdem haben viele bereitwillig Ruby gelernt, um Rails verwenden zu können.
Und genau so ein Zugpferd wäre auch für Python gut. Denn je mehr Anwender die Plattform hat, desto besser für die Weiterentwicklung. Und wenn auf mehr Servern Python läuft, ist das natürlich auch aus Python-Sicht gut, gleiches gilt für Job-Angebote usw ...
Und genau so ein Zugpferd wäre auch für Python gut. Denn je mehr Anwender die Plattform hat, desto besser für die Weiterentwicklung. Und wenn auf mehr Servern Python läuft, ist das natürlich auch aus Python-Sicht gut, gleiches gilt für Job-Angebote usw ...
Der Punkt ist, genau dass trifft nicht zu. Es gibt Leute die Ruby kaum können aber ohne Probleme Webapps mit Ruby on Rails programmieren können. Das ist einer der großen Nachteile wenn es zu DSLs kommt.deamon hat geschrieben:[...]trotzdem haben viele bereitwillig Ruby gelernt, um Rails verwenden zu können.
Dass die Entwickler eher die DSL des Frameworks als die eigentliche Sprache lernen, kann ich mir gut vorstellen. Aber im Prinzip ist es fast egal, ob man die Verwendung einer bestimmten API lernt, oder eine bestimmte DSL. In beiden Fällen kann man mit dem Wissen nicht viel anfangen, wenn man etwas anderes verwendet. Wobei man zumindest allgemeine Kenntnisse der Programmiersprache mitnehmen könnte, aber dann müsste man wieder ein neues API erlernen.
Es ist natürlich gut, eine vielseitige Sprache zu können, die man dann für alles mögliche verwenden kann. Ähnlich vorteilhaft ist es, möglichst allgemeine Bibliotheken zu kennen. Wenn man bei Java das Servlet-API beherrscht, kann man davon bei praktisch allen Web-Frameworks von profitieren. WSGI ist leider auf zu tiefer Ebene angesiedelt, um eine vergleichbare Position zu erreichen. Um WSGI nutzen zu können, ist eigentlich immer ein Framework nötig, bei dem man dann wieder spezielle statt allgemeiner Dinge lernen muss. Meiner Meinung nach fehlt Python aufbauend auf WSGI etwas wie das Servlet-API. Darin sollten etwas grundlegende Dinge wie Fehlerbehandlung, Sitzungsverwaltung oder Unterstützung von Datei-Uploads enthalten sein.
Es ist natürlich gut, eine vielseitige Sprache zu können, die man dann für alles mögliche verwenden kann. Ähnlich vorteilhaft ist es, möglichst allgemeine Bibliotheken zu kennen. Wenn man bei Java das Servlet-API beherrscht, kann man davon bei praktisch allen Web-Frameworks von profitieren. WSGI ist leider auf zu tiefer Ebene angesiedelt, um eine vergleichbare Position zu erreichen. Um WSGI nutzen zu können, ist eigentlich immer ein Framework nötig, bei dem man dann wieder spezielle statt allgemeiner Dinge lernen muss. Meiner Meinung nach fehlt Python aufbauend auf WSGI etwas wie das Servlet-API. Darin sollten etwas grundlegende Dinge wie Fehlerbehandlung, Sitzungsverwaltung oder Unterstützung von Datei-Uploads enthalten sein.
Zuletzt geändert von deamon am Mittwoch 24. Juni 2009, 10:53, insgesamt 1-mal geändert.
-
BlackJack
@daemon: Ich denke es gibt schon einen Unterschied zwischen DSL und API. Leute, die nur die Servlet-API verwenden, haben wenigstens Java gelernt und müssen das nicht für eine andere API noch zusätzlich lernen.
Bei einer DSL muss dagegen nicht viel von der darunterliegenden Sprache enthalten sein, so dass man zu einer anderen API auch gleich noch eine andere Sprache lernen muss.
Bei einer DSL muss dagegen nicht viel von der darunterliegenden Sprache enthalten sein, so dass man zu einer anderen API auch gleich noch eine andere Sprache lernen muss.
TIOBE misst, wie häufig eine Sprache im Internet erwähnt wird. Daraus kann man IMHO nicht auf die Größe der Community schließen. Gardener hat die Anzahl der Ruby-Entwickler (wahrscheinlich für Rails) auf ca. 1 Mio geschätzt und meint, bis 2013 werden es 4 Mio. Sun schätzt die Anzahl der Java-Entwickler auf ca. 10 Mio. Gibt es 1 Mio Python-Entwickler?
Vielleicht hilft Google-Groups weiter: Django: 14289 Mitglieder, Rails: 18539, GWT: 18035.
Auf Djangopeople.net sind 4733 User eingetragen. Auf workingwithrails.com sind es 16983.
Rails ist definitiv die Killer-Anwendung für Ruby. Dadurch wurde es 2004 dann auch bekannt, auch wenn ich die Sprache schon 1999 oder so durch das Pick Axe Buch kannte, das ich mir nach dem Pragmatic Programmer von den selben Autoren in den USA gekauft hatte. Ich war sofort verliebt in die Sprache, denn sie war wie Smalltalk, das zu diesem Zeitpunkt immer mehr von Java verdrängt wurde, welches eine eher mäßige Sprache war (und ist).
Braucht Python auch eine Killer-Anwendung? Schaden kann's nicht. 2001 dachte ich, es wäre Zope, doch irgendwie wurde das nix und wenn überhaupt, dann hat IMHO jetzt Django die Chance. Andererseits muss man's auch wollen und dieser Wille scheint mir in der Python-Gemeinde allgemein und bei Django ganz besonders zu fehlen.
DHH hatte sich damals Java-Entwickler als dankbares Ziel für Hohn und Spott ausgesucht und dadurch Rails ins Gerede gebracht und einen bis dahin einzigartigen Hype gestartet. Es hat Rails und Ruby nicht geschadet.
Deamon schreibt, ihn stört bei Django (und anderen Rahmenwerken), dass es keine Validierung auf Modellebene gibt. Das scheint mir als Grund aber zu wenig, um "schnell noch mal eben" ein weiteres Web-Rahmenwerk zu bauen. Klar, ich erwische mich auch ab und zu bei dem Gedanken, man müsste es noch mal "richtig" machen und die Welt mit einem weiteren Web-Rahmenwerk beglücken, aber so sehr das auch Spaß machen kann, Python würde es nicht wirklich weiterbringen.
In meiner ganz persönlichen Einschätzung hat Python extrem durch das 3.x-Fiasko gelitten. Die neue Version existiert zwar, aber ein klarer Wille, sie auch nutzen zu wollen, fehlt. Genau wie es zig Web-Rahmenwerke gibt und keines klar dominiert, sind zig Python-Versionen aktiv und buhlen so um die Aufmerksamkeit der Entwickler und helfen nicht, die neuste (und eigentlich aktuelle) Version nach vorne zu bringen.
Wie heißt es so schön: gut genug ist der Feind des besten. Python 2.x ist gut genug. Python 3.x ist in dem Versuch, nicht zu viel zu ändern, einfach in der Bedeutungslosigkeit versunken. Es ist anders genug, um nicht einfach umsteigen zu können, gleichzeitig ist der Umstieg nicht wirklich lohnenswert.
Bei Ruby ist es mit Version 1.9.1 vs. 1.8.7 oder sogar 1.8.6 ähnlich, aber nicht ganz so extrem, da inzwischen eigentlich das meiste mit 1.9.1 läuft und nicht weniger als die Verdopplung der Laufzeitgeschwindigkeit winkt, wenn man umsteigt. Das viele mit 1.8.6 arbeiten ist eigentlich eher der Trägheit der Entwickler geschuldet, die zu fast alle einen Mac haben und einfach die bei Leopard mitgelieferte Version benutzen.
Der Wicket-Ansatz, so glaube ich, funktioniert besser bei einer statisch getypten Sprache, die Klassen als zentrales Mittel hat. Für Python wirkt es - ich hatte das ja mal ausprobiert - irgendwie schwergewichtig. Wicket ist ja ähnlich wie Tapestry von Webobjects inspiriert. Dieses Rahmenwerk gab es ja bereits zu NextStep-Zeiten und war, wie eigentlich NextStep allgemein, mindestens 10 Jahre seiner Zeit voraus. Ich würde gerne mal studieren, wie Webobjects wirklich aussah, bevor Apple da Java drüber gestülpt hat. Vielleicht wäre das eine neue Inspirationsquelle. Ansonsten bietet sich natürlich Seaside als praktikables Continuations-basiertes Web-Rahmenwerk an, ließe sich aber in Python (ohne Stackless) wieder nur schwer umsetzen. Ruby wäre da geeigneter, hat es doch einen callcc-Befehl, der in 1.9.1 sogar ohne Memoryleak funktioneren soll.
BlackJacks vorgeschlagene Strategie, auf breiter Front schleichend den Siegeszug anzutreten, sehe ich eher skeptisch. Wenn man Aufmerksamkeit will, muss man es wie die schottischen Elite-Regimenter im Unabhängigkeitskrieg machen: Mit Pauken und Dudelsack mit flammendroten Uniformen und wehenden Fahnen in breiter Front auf den Feind zumarschieren. Hat den Engländern aber auch nichts genützt...
Auch übrigens, Rails lernen, ohne Ruby zu können, ist zum scheitern verurteilt. Man wäre verloren, wenn man verstehen will, was da sonst abgeht. Bei Django geht es da ohne Python-Kenntnisse noch eher. Was ich aber sagen will: Durch Rails lernt man nicht automatisch falsches nicht-ideomatisches Ruby.
Die von CM erwähnten Projekte, Python schneller zu machen, sind zwar interessant, laufen allerdings für meinen Geschmack viel zu langsam. Wie viele Jahre gibt es jetzt schon das PyPy-Projekt? Und wie lange gibt es schon den GIL?
Durch das höhere - auch kommerzielle - Interesse an Ruby ist die Situation dort wesentlich besser: JRuby ist eine ernstzunehmende Alternative, weil schneller als 1.8.x (allerdings noch nicht 1.9.x) und dank Suns Interesse, die JVM als Plattform für andere Sprachen neben Java (das seinen Zinit überschritten hat) zu platzieren. Es gibt Rubinius als Community-Variante, die zeitweise von EngineYard unterstützt wurde als es noch keine Finanzkrise gab und es gibt Microsoft, wie auch ein bisschen Coolness haben wollen und daher IronRuby (neben IronPython, was im Python-Umfeld eine ernstzunehmende Alternative ist). Es gibt noch mehr Ruby-Systeme - sogar eines für Flash - doch meist sind diese unvollständig. Dafür gibt es inzwischen eine Reihe guter IDEs. Bei Python sind das eher schlecht aus. Pydev für Eclipse überzeugt mich nicht wirklich.
Ach ja, und was BlackJack als Nachteil einer DSL verkauft, ist natürlich ihr großer Vorteil. Man muss eben nicht die Implementierung kennen und verstehen und jedes Mal hinschreiben, sondern kann abstrakter und damit in der Regel schneller vorgehen.
Stefan
Vielleicht hilft Google-Groups weiter: Django: 14289 Mitglieder, Rails: 18539, GWT: 18035.
Auf Djangopeople.net sind 4733 User eingetragen. Auf workingwithrails.com sind es 16983.
Rails ist definitiv die Killer-Anwendung für Ruby. Dadurch wurde es 2004 dann auch bekannt, auch wenn ich die Sprache schon 1999 oder so durch das Pick Axe Buch kannte, das ich mir nach dem Pragmatic Programmer von den selben Autoren in den USA gekauft hatte. Ich war sofort verliebt in die Sprache, denn sie war wie Smalltalk, das zu diesem Zeitpunkt immer mehr von Java verdrängt wurde, welches eine eher mäßige Sprache war (und ist).
Braucht Python auch eine Killer-Anwendung? Schaden kann's nicht. 2001 dachte ich, es wäre Zope, doch irgendwie wurde das nix und wenn überhaupt, dann hat IMHO jetzt Django die Chance. Andererseits muss man's auch wollen und dieser Wille scheint mir in der Python-Gemeinde allgemein und bei Django ganz besonders zu fehlen.
DHH hatte sich damals Java-Entwickler als dankbares Ziel für Hohn und Spott ausgesucht und dadurch Rails ins Gerede gebracht und einen bis dahin einzigartigen Hype gestartet. Es hat Rails und Ruby nicht geschadet.
Deamon schreibt, ihn stört bei Django (und anderen Rahmenwerken), dass es keine Validierung auf Modellebene gibt. Das scheint mir als Grund aber zu wenig, um "schnell noch mal eben" ein weiteres Web-Rahmenwerk zu bauen. Klar, ich erwische mich auch ab und zu bei dem Gedanken, man müsste es noch mal "richtig" machen und die Welt mit einem weiteren Web-Rahmenwerk beglücken, aber so sehr das auch Spaß machen kann, Python würde es nicht wirklich weiterbringen.
In meiner ganz persönlichen Einschätzung hat Python extrem durch das 3.x-Fiasko gelitten. Die neue Version existiert zwar, aber ein klarer Wille, sie auch nutzen zu wollen, fehlt. Genau wie es zig Web-Rahmenwerke gibt und keines klar dominiert, sind zig Python-Versionen aktiv und buhlen so um die Aufmerksamkeit der Entwickler und helfen nicht, die neuste (und eigentlich aktuelle) Version nach vorne zu bringen.
Wie heißt es so schön: gut genug ist der Feind des besten. Python 2.x ist gut genug. Python 3.x ist in dem Versuch, nicht zu viel zu ändern, einfach in der Bedeutungslosigkeit versunken. Es ist anders genug, um nicht einfach umsteigen zu können, gleichzeitig ist der Umstieg nicht wirklich lohnenswert.
Bei Ruby ist es mit Version 1.9.1 vs. 1.8.7 oder sogar 1.8.6 ähnlich, aber nicht ganz so extrem, da inzwischen eigentlich das meiste mit 1.9.1 läuft und nicht weniger als die Verdopplung der Laufzeitgeschwindigkeit winkt, wenn man umsteigt. Das viele mit 1.8.6 arbeiten ist eigentlich eher der Trägheit der Entwickler geschuldet, die zu fast alle einen Mac haben und einfach die bei Leopard mitgelieferte Version benutzen.
Der Wicket-Ansatz, so glaube ich, funktioniert besser bei einer statisch getypten Sprache, die Klassen als zentrales Mittel hat. Für Python wirkt es - ich hatte das ja mal ausprobiert - irgendwie schwergewichtig. Wicket ist ja ähnlich wie Tapestry von Webobjects inspiriert. Dieses Rahmenwerk gab es ja bereits zu NextStep-Zeiten und war, wie eigentlich NextStep allgemein, mindestens 10 Jahre seiner Zeit voraus. Ich würde gerne mal studieren, wie Webobjects wirklich aussah, bevor Apple da Java drüber gestülpt hat. Vielleicht wäre das eine neue Inspirationsquelle. Ansonsten bietet sich natürlich Seaside als praktikables Continuations-basiertes Web-Rahmenwerk an, ließe sich aber in Python (ohne Stackless) wieder nur schwer umsetzen. Ruby wäre da geeigneter, hat es doch einen callcc-Befehl, der in 1.9.1 sogar ohne Memoryleak funktioneren soll.
BlackJacks vorgeschlagene Strategie, auf breiter Front schleichend den Siegeszug anzutreten, sehe ich eher skeptisch. Wenn man Aufmerksamkeit will, muss man es wie die schottischen Elite-Regimenter im Unabhängigkeitskrieg machen: Mit Pauken und Dudelsack mit flammendroten Uniformen und wehenden Fahnen in breiter Front auf den Feind zumarschieren. Hat den Engländern aber auch nichts genützt...
Auch übrigens, Rails lernen, ohne Ruby zu können, ist zum scheitern verurteilt. Man wäre verloren, wenn man verstehen will, was da sonst abgeht. Bei Django geht es da ohne Python-Kenntnisse noch eher. Was ich aber sagen will: Durch Rails lernt man nicht automatisch falsches nicht-ideomatisches Ruby.
Die von CM erwähnten Projekte, Python schneller zu machen, sind zwar interessant, laufen allerdings für meinen Geschmack viel zu langsam. Wie viele Jahre gibt es jetzt schon das PyPy-Projekt? Und wie lange gibt es schon den GIL?
Durch das höhere - auch kommerzielle - Interesse an Ruby ist die Situation dort wesentlich besser: JRuby ist eine ernstzunehmende Alternative, weil schneller als 1.8.x (allerdings noch nicht 1.9.x) und dank Suns Interesse, die JVM als Plattform für andere Sprachen neben Java (das seinen Zinit überschritten hat) zu platzieren. Es gibt Rubinius als Community-Variante, die zeitweise von EngineYard unterstützt wurde als es noch keine Finanzkrise gab und es gibt Microsoft, wie auch ein bisschen Coolness haben wollen und daher IronRuby (neben IronPython, was im Python-Umfeld eine ernstzunehmende Alternative ist). Es gibt noch mehr Ruby-Systeme - sogar eines für Flash - doch meist sind diese unvollständig. Dafür gibt es inzwischen eine Reihe guter IDEs. Bei Python sind das eher schlecht aus. Pydev für Eclipse überzeugt mich nicht wirklich.
Ach ja, und was BlackJack als Nachteil einer DSL verkauft, ist natürlich ihr großer Vorteil. Man muss eben nicht die Implementierung kennen und verstehen und jedes Mal hinschreiben, sondern kann abstrakter und damit in der Regel schneller vorgehen.
Stefan