Journal Python on rails

Posté par (page perso) .
Tags : aucun
0
6
oct.
2005
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 ...
  • # Et PHP ...

    Posté par (page perso) . Évalué à 5.

    Pour parler d'un language moins connu que Ruby et Python ... je voudrais juste mentionner pour les qq dizaines de développeurs PHP que CakePHP vient de sortir officiellement en version 0.10.0
    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(...)
  • # c'est vrai ;-)

    Posté par (page perso) . Évalué à 2.

    J'ai lu de manière normale ta première phrase, et elle m'a bien amusé !
    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 (page perso) . Évalué à 4.

      "J'ai lu de manière normale ta première phrase, et elle m'a bien amusé !"

      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. ;)
  • # Pour continuer le débat

    Posté par (page perso) . Évalué à 5.

    http://www.billkatz.com/node/42(...) "Could Rails have been built without Ruby?"
    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 (page perso) . Évalué à 2.

      Interessant, mais ce n'est que le point de vue d'un gars, il y a 7 mois ...
      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 . Évalué à 3.

        On a pas dû lire le même article.

        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 . Évalué à 5.

    Ce gross buzz sur les frameworks Web a eu le mérite de montrer le dynamisme de la communauté Python (avec ses gourous comme Ian Bicking et PJE qui tirent vers le haut), même si du coup pour l'instant les acteurs ne cessent de se multiplier et aucun ne sort encore vainqueur.

    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 . Évalué à 2.

      Ce qui nous manquerait , c'est un vrai comparatif.
      Comme t'as l'air de t'y interesser t'as pas ca dans ta besace ?
      • [^] # Re: Dynamisme de Python

        Posté par . Évalué à 1.

        Ce qui nous manquerait , c'est un vrai comparatif.

        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 (page perso) . Évalué à 3.

          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).

          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 (page perso) . Évalué à 2.

    je croyais qu'en python on préférait plutôt avoir une manière de faire...

    -> [scaphandre amianté]
    • [^] # Re: l'embarras du choix?

      Posté par . Évalué à 2.

      Manquait plus qu'un perlien se ramène avec son TIMTOWTDI et ca va être un vrai champ de bataille.
      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 . Évalué à 3.

    C'est stupide de reecrire un logiciel juste parce que le langage ne plait pas. Il faut s'ouvrir un peu, apprendre d'autres langages et pas se renfermer autour de son langage fetiche.

    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 . Évalué à 3.

      C'est stupide de reecrire un logiciel juste parce que le langage ne plait pas. Il faut s'ouvrir un peu, apprendre d'autres langages et pas se renfermer autour de son langage fetiche.

      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 à ceux qui les ont postés. Nous n'en sommes pas responsables.