Rappelez vous, en début d'année, ce post :
http://linuxfr.org/2005/01/04/18000.html(...) (Sortie de Ruby 1.8.2)
avait généré un énorme débat ...(et un gros troll poilu python-ruby)
dans ce post : http://linuxfr.org/comments/518388.html#518388(...)
J'expliquais que python possédait déjà toutes les libs qui vont bien, et qu'il suffisait de choisir les meilleures. Et eventualisait de faire un RoR à base de cherrypy/sqlobject et cheetah.
10 mois plus tard ... des MVC python, concurrent de RoR n'en finissent pas de sortir ...
pour n'en citer que qqu'uns (batis souvent autour de sqlobject, cherrypy ou cheetah):
mighty : http://www.myghty.org/(...)
bricks : http://www.pythonweb.org/doc/bricks.doc.html(...)
subway : http://subway.python-hosting.com/wiki(...)
paste : http://pythonpaste.org/(...)
django : http://www.djangoproject.com/(...)
turbogears : http://www.turbogears.org/index.html(...)
Les 2 derniers ayant "plus" le vent en poupe ... (subjectif, on en parle tout simplement bien plus sur le web)
on compare même le dernier à l'ubuntu/linux : http://42.blogs.warnock.me.uk/2005/10/is_turbogears_t.html(...)
(Ce dernier vient également avec tout qui va bien (la "video" et la doc), comme Ror)
Ce n'est pas pour reprendre le troll de jadis ... mais c'est juste pour dire que maintenant, en python, le gars qui veut un "MVC tout prêt", il a plus que l'embarra du choix ! (tout est prêt, même les "python eggs")
et comme d'hab, en python, trop de choix, risque encore de causer un préjudice à python dans son ascenssion du web ...
Journal Python on rails
6
oct.
2005
# Et PHP ...
Posté par Alexandre DATH (site web personnel) . Évalué à 5.
Le développement de ce framework MVC "à la" RoR est assez soutenu, un SVN et un trac sont disponibles...
Les liens ...
Le site : http://cakephp.org(...)
Le trac : http://trac.cakephp.org(...)
... depuis la sortie de 0.10.0, le trac a été vidé et repensé, l'ancien trac avec un wiki bcp plus fournit (mais pas forcément à jour avec la 0.10.0) est dispo ici : https://oldtrac.cakephp.org/wiki(...)
[^] # Re: Et PHP ...
Posté par vrm (site web personnel) . Évalué à 0.
[^] # Re: Et PHP ...
Posté par lezardbreton . Évalué à 2.
# c'est vrai ;-)
Posté par manatlan (site web personnel) . Évalué à 2.
C'est vrai qu'il existe, bien evidemment, d'autres MVC, dans plein d'autres languages (java, php, ...) ... et qui sont, bien evidemment, plus utilisé que le python, ou le ruby ;-)
Mon journal parle des framework MVC dans le monde python/ruby ... et vient clôturer le troll de début d'année ... (d'ailleurs, j'en ai pas parlé, mais je crois qu'il existe d'autres MVC maintenant aussi dans le monde ruby)
[^] # Re: c'est vrai ;-)
Posté par Alexandre DATH (site web personnel) . Évalué à 4.
Tant mieux, c'est le but recherché :)
C'était biensur uniquement de l'humour, je sais bien qu'il existe une palette de framework MVC deja sur PHP.
Mais comme j'utilises actuellement CakePHP, je voulais en profiter pour lui faire un peu de pub (car il mérite à être plus connu) :)
Mais tout le monde sait que Ruby et Python sont largement supérieur à PHP. ;)
[^] # Re: c'est vrai ;-)
Posté par golum . Évalué à 2.
http://linuxfr.org/comments/632134.html#632134(...)
Sinon n'hésitez pas à consulter ce journal récent qui parle de turbogears
http://linuxfr.org/~rangzen/19593.html(...)
Puisque manatlan ne l'a pas cité
# Pour continuer le débat
Posté par Yann KLIS (site web personnel) . Évalué à 5.
où l'auteur nous explique pourquoi c'est bien Ruby qui fait la force de Ruby on Rails, et qu'évidemment on peut écrire des frameworks web dans d'autres langages, mais qu'en Ruby ça rosque.
[^] # Re: Pour continuer le débat
Posté par manatlan (site web personnel) . Évalué à 2.
quand sous python, il n'existait pas de concurrent direct (les briques existaient déjà) ...
Et en prennant zope en reference, je comprends assez bien son point de vue ;-)
[^] # Re: Pour continuer le débat
Posté par Sylvain Sauvage . Évalué à 3.
Katz ne compare pas RoR avec Zope, ni les bibliothèques de Ruby avec celles de Python.
Il explique simplement que le principe exposé par Graham de bottom-up design (ci-après BUD) est en fait un des principes de Ruby et de Lisp.
RoR est une sorte de « Ruby++ pour le web ».
Il dit aussi que c'est pour cela que RoR est bien : c'est du Ruby et, en même temps, c'est plus que du Ruby.
Il donne Zope 2 comme contre-exemple : c'est en Python mais ce n'est pas du Python. Il pense que c'est pour cela que Zope a eu des problèmes et que Zope X3 a été lancé.
Voilà. La réponse à la question posée dans le titre (Est-ce que RoR aurait pu être écrit sans Ruby ?) est non, car pas de BUD, pas de RoR et Ruby permet le BUD et oui, car il n'est pas le seul (mais c'est quand même 'achetement pratique en Ruby ;o).
# Dynamisme de Python
Posté par Thomas Hervé . Évalué à 5.
Effectivement TurboGears est beaucoup évoqué, mais aussi parce que c'est le dernier en date. Django a lui aussi pas mal fait parler de lui,... et c'est l'avant-dernier :). Ce qui est appréciable chez TurboGears c'est que c'est plus un assemblage autour d'autres softs: cherrypy, kid, sqlobject, mochikit, des briques existantes vraiment intéressantes et maintenues par des personnes compétentes. TurboGears apporte surtout un liant entre tout ca, et un peu de marketing.
A noter qu'il n'y a pas vraiment incompatibilité entre Paste et les autres. Cet article : http://www.groovie.org/articles/2005/10/04/python-paste-power(...) montre comment il permet de générer des applications dans les autres frameworks.
C'est en tout cas très stimulant, chacun apportant d'excellentes idées.
--
Thomas
[^] # Re: Dynamisme de Python
Posté par golum . Évalué à 2.
Comme t'as l'air de t'y interesser t'as pas ca dans ta besace ?
[^] # Re: Dynamisme de Python
Posté par Thomas Hervé . Évalué à 1.
Ca c'est un projet qui n'est pas bête. Mais vu l'ampleur du travail, personne ne l'a encore fait. L'idéal serait d'avoir une application test déclinée sur le différents frameworks. Des volontaires ? :)
La meilleure chose pour les distinguer aujourd'hui, ce sont les fonctionnalités disponibles, la documentation, et aussi beaucoup de subjectif. Histoire d'en remettre une couche: http://wiki.python.org/moin/WebProgramming(...) .
Ca me permet d'introduire un framework moins connu mais qu'il-est-bien : Nevow. Si vous aimez Python et que nous ne connaissez ni Nevow, ni Twisted, je ne peux que vous encouragez à regarder aussi de ce côté. Certains choix sont un peu déroutants au début (ce sont les apôtres de l'Asynchronous Programming, une méthode de gestion d'évenements sans Threads).
--
Thomas
[^] # Re: Dynamisme de Python
Posté par Damien (site web personnel) . Évalué à 3.
Et justement en python c'est l'horreur, parce que la syntaxe ne permet pas les méthodes anonymes (et lambda a des limitations si je ne m'abuse)...
En gros ils essayent de faire des continuations sans avoir le support dans le langage (ou en tout cas sans les utiliser...). Pour voir ce que ça peut donner quand c'est bien fait, il faut voir Seaside [1], qui réussit à masquer complètement l'asynchronisme.
Bref, franchement, Twisted m'a pas convaincu, surtout que c'est quand même assez bas niveau ; c'est génial pour faire des applis qui doivent utiliser plein de protocoles différents, mais pour du web c'est pas assez spécialisé (oui, je suis fan de RubyOnRails :)
[1] http://seaside.st(...)
# l'embarras du choix?
Posté par Damien (site web personnel) . Évalué à 2.
-> [scaphandre amianté]
[^] # Re: l'embarras du choix?
Posté par golum . Évalué à 2.
Manatlan tu penses qu'on va dépasser les 153 Post de celui que tu nous montre sur Ruby.
====== >[ ]
# Un langage n'est pas une religion
Posté par Erwan . Évalué à 3.
Ce serait comme reecrire gdesklets en Ruby parce qu'on aime pas le Python, ce serait contre-productif et stupide.
Ce qui fait un bon logiciel, c'est le developpeur. Et ce qui fait un bon developpeur, ce sont ses competences et ses connaissances intrinseques. Pas le fait qu'il trouve que tel langage sux ou tel autre rox.
[^] # Re: Un langage n'est pas une religion
Posté par Thomas Hervé . Évalué à 3.
Complétement pas d'accord. Si il y a bien une chose intéressant ici (et dans le logiciel libre), c'est le choix. Il y a des choses intéressantes à prendre partout, et là tu pars du principe que c'est une réécriture complètre du logiciel en copie : ce n'est pas du tout ca. Le but est de batir quelque chose sur les mêmes principes, mais avec des nouvelles façons de voir les choses.
Ce serait comme reecrire gdesklets en Ruby parce qu'on aime pas le Python, ce serait contre-productif et stupide.
Plusieurs choses. Ce sont des frameworks, c'est dont pour construire des applications complètes. Si tu connais Python et pas Ruby , c'est beaucoup rapide de prendre un framework déjà en Python que d'apprendre le Ruby (un plugin gdesklet ce n'est pas la même ampleur qu'une application web). Ensuite qui te parle de productivité ? Si un développeur a envie de faire un truc qui sert à rien, c'est bien son droit. Combien d'application ne passent jamais la version 0.1 ?
On pourrait dire : ca serait comme réécrire GNOME en C++. Ou Python en Python (sisi certains le font). Ou Minix en étant Finlandais.
Bref tu es très mal placé pour juger la stupidité de la chose.
Ce qui fait un bon logiciel, c'est le developpeur. Et ce qui fait un bon developpeur, ce sont ses competences et ses connaissances intrinseques. Pas le fait qu'il trouve que tel langage sux ou tel autre rox.
Ce qui fait un bon développeur (opensource) c'est son ouverture, sa liberté et ses convictions. Si je trouve Ruby nul (jugement complétement arbitraire sans argument), je n'ai pas envie de faire des applications web avec, point.
--
Thomas
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.