Non, non, ce n’est pas moi qui le dit, mais Derek Sivers dans un billet paru sur O’Reilly Network initulé en anglais “7 reasons I switched back to PHP after 2 years on Rails”. Un article qui fait beaucoup parler de lui dans le milieu Rails depuis quelques jours, car il est dans la lignée des milliers d’articles essayant de descendre Ruby on Rails ou de démontrer pourquoi leur logiciel à eux fait des choses mieux que Rails (tout en copiant le comportement de Rails).

Je vais d’ailleurs traduire ses 7 arguments et essaye d’y répondre (calmement) :

1. Est-ce qu’il y a quelque chose que Rails/Ruby sait faire que PHP ne sait pas faire ?
2. La plupart de nos logiciels étaient écrits en PHP. Ne pas sous-estimer l’intégration.
3. Je ne veux pas ce dont je n’ai pas besoin
4. Petit et rapide
5. Construit d’après mes goûts
6. J’aime SQL
7. Les langages de programmation sont comme les petites amies : la nouvelle est mieux parce que “vous” êtes mieux

Ma petite analyse :

1. L’auteur n’a pas tord sur ce point. On peut très bien faire la même chose en PHP et en Rails/Ruby. Après tout, on ne fait que servir des pages web à des navigateurs web, non ? D’ailleurs, je vais me mettre au C++ ou à l’assembleur Sparc pour faire mes prochaines pages web, histoire que ça soit hyper optimisé
2. L’auteur n’a pas tord sur ce point. Ne pas sous-estimer l’intégration à l’existant ! (News at 10 : bientôt la découverte du fil à couper le beurre). Ceci vaut d’ailleurs pour n’importe quelle technologie et ça vaut même pour n’importe quelle activité, hors informatique aussi.
3. L’auteur prétend tout connaitre du logiciel qu’il a développé et qu’il n’a pas envie de connaitre tout le code de Rails pour pouvoir l’utiliser. Evidemment, il a certainement lu le code de PHP, de son serveur web, de son système d’exploitation, etc. Au passage, le code de Rails est quand même très lisible, compréhensible et le code source de chaque fonction de l’API publique est directement disponible indépendamment sur son site web officiel. (*)
4. L’auteur prétend que son site tourne très bien avec 2 petites machines. Oui, il n’a utilisé qu’une seule phrase pour décrire cet argument en anglais aussi. Ceux qui ont été à la session “Empirisme dans l’IT” lors du dernier BarCampAlsace4 connaissent mon sentiment sur la question : inutile de jeter des chiffres à la figure des gens si on ne donne ni le contexte, ni les outils de mesure, ni la “métrique” intéressante sur le système en question.
5. Ca sent le syndrôme NIH (Not Invented Here) à plein nez.
6. Certes, je n’en suis pas à aimer SQL (le langage de requête utilisé pour interroger une base de données), et j’aime utiliser ce que Rails a à m’offrir pour me faciliter la vie. Mais je sais aussi que ces aides qui me facilitent la vie n’aident pas forcément à la rapidité de mon application. Mais en premier, ça m’aura permis d’écrire rapidement du code lisible qui fonctionne. A ce sujet j’aime la maxime suivante : “D’abord on fait en sorte que ça fonctionne, ensuite on fait en sorte que ça fonctionne bien et tout à la fin on optimise”.
7. L’auteur prétend (et avec raison) que si l’on trouve que la toute dernière technologie à la mode est si géniale, c’est parce que, dans le même temps, nous nous sommes bonnifié au travers de nos diverses expériences passées. Encore une fois, ceci est vrai pour n’importe quelle technologie et n’importe quel secteur d’activité.

Bref, comme vous l’aurez compris, je trouve que le titre du billet original est ravageur alors que le contenu nous laisse en fait sur notre faim. Et avec ces argument un peu faible que l’on peut utiliser sans faire mention de Rails, il donne en fait des balles neuves à la communauté Rails qui continue à grandir et à gagner en force et en maturité.

Enfin, et comme le signale DHH (fondateur de Rails) sur son blog , la Grande Réécriture d’un projet depuis le tout début est de toute façon souvent problématique et périlleux…

(*) OK, le code “privé” est parfois un peu difficile à prendre en main au premier abord, je pense notamment à la partie routage, mais on croise de plus en plus de billets de blog expliquant telle ou telle partie du code de Rails, avec les liens vers les Design Pattern implémentés.