Impressionant d'objectivité cette étude.
En gros : ah, y a largement plus de code écrit en PHP, PHP est plus utilisé, alors PHP caymieux.
Ah bon. Cool. Y a largement plus de développeurs et d'utilisateurs Windows, c'est pas pour autant que c'est mieux.
PHP il existe depuis belle lurette, c'est un langage devenu limite un standard, alors que Ruby n'a décollé sur le Web que depuis l'avénement de RoR donc c'est clair que y avait pas besoin de faire une étude pour savoir que PHP est clairement plus utilisé.
De plus, comme d'habitude, on tente de comparer ce qui n'est pas comparable : PHP qui est un simple langage de script avec Ruby on Rails qui est un framework complet basé sur Ruby.
Selon moi il n'existe aucun framework basé sur PHP qui a actuellement autant de succès que Ruby on Rails. Et c'est pas sans raison...
Le couple Ruby on Rails + RadRails (environnement basé sur Eclipse avec éditeur de code à onglets, navigateur base de données, lancement des serveurs de tests, tests unitaires, débugguage) est "clairement" tueur.
Peut être parce qu'il en existe des dizaines en PHP
Reste a savoir s'il y en a un qui arrive a la cheville de RoR - toute la chaine confondue, en allant des éditeurs, abstraction de la base de donnée, aux outils de test et au débuggage. J'en doute ...
Il faut quand meme avouer que jamais un framework PHP n'a fait autant sensation que RoR.
Je ne dis pas que c'est un critère objectif de jugement, ni meme un indicateur de qualité, c'est juste une constatation.
J'ai quand meme tendance à penser qu'un buzz se crée quand même autour de quelque chose de relativement novateur, etc..
Par exemple, et tu pourras certainement me renseigner, la génération de squelette d'application via un script Ruby, que tu as apparemment repris dans Jelix (que je redécouvre avec bonheur pour l'enseigner) , c'est quand meme une super idée non ? Ca existait avant ? (vraie question...)
Je suis tout a fait d'accord qu'on pourrait tuer RoR avec un killer framework en php5 (6), mais pour l'instant ce n'est pas le cas.
> a génération de squelette d'application via un script Ruby, que tu as apparemment repris dans Jelix (que je redécouvre avec bonheur pour l'enseigner) , c'est quand meme une super idée non ? Ca existait avant ?
Non ça n'existait pas avant à ma connaissance. En même temps, les developpeurs PHP en général ont compris l'importance des framework PHP qu'il y a peut-être 3-4 ans...
Et puis il y a peut être aussi l'effet linux/windows. Va donc dire à un windowsien "ouvre ta console et tape ça"... En général il préfère une belle gui, ou que son IDE lui génère son archi apres 3 cliques.
Personnellement, je ne trouve pas que les scripts en ligne de commande de RoR soient innovants. Trés pratique, bonne idée, mais pas innovante du tout. Je crois plutôt que le succés de ces scripts, c'est surtout dû à une meilleure acceptation de la ligne de commande qu'avant, par les developpeurs web.
Mais à mon avis, rien ne vaut un "nouveau projet RoR/Jelix/Symphony/framework_que_tu_preferes" dans un IDE, et qui te créer d'office un squelette de ta nouvelle appli.
Personnellement, je ne trouve pas que les scripts en ligne de commande de RoR soient innovants.
Il n'y a pas grand chose de Rails qui soit réellement innovant: les scripts qui génèrent du code, la possibilité de redéfinir le code dynamiquement, l'analyse de la base de données pour construire les objets, les langages de templates, l'intégration du système de tests, le système de modification incrémentable de la base, tout ça existe déjà ailleurs sous différentes formes.
Ce qui fait le succès de Rails, c'est surtout que tout est packagé autour d'un langage qui est expressif sans être dépaysant, et le fait que des conventions bien choisies évitent de devoir se coltiner avec ce dont on n'a pas besoin.
La modification dynamique de code, par exemple, ça existait depuis au moins aussi longtemps que Lisp, mais Lisp est plus difficile d'accès quand on vient de langages comme Java ou PHP.
C'est vrai que j'ai rarement vu un article apporter si peu.
Sans parler du fait que Ruby est le language avec lequel on commence le plus de projet (selon l'un des graphs).
Bref venir nous dire que PHP est le language le plus répandu, en effet il n'y avait pas besoin d'un article pour ça. C'est peut-être qu'ils voulaient pouvoir dire qu'ils avaient une grosse bd avec des projets open source :)
Je n'ai pas encore codé avec Ruby, mais j'ai un ami développeur web et il ne jure que par ça. De ce que j'ai vu, c'est un language TRES compréhensible à la lecture.
Faut s'habituer quand on a l'habitude de coder en C like mais sinon il a l'air vraiment agréable.
Bref Ruby ça a l'air d'être du bon, et il ne faut pas oublier une autre chose, à chaque language son application. Il parle dans cet article de Python, en même temps Python c'est pas le language le plus orienté web que je connaisse.
Mais bon... Tout ça pour dire que l'article.... bof.
Python c'est pas le language le plus orienté web que je connaisse.
Ruby n'est pas franchement plus orienté web que Python (à part peut-être la présence depuis longtemps d'erb, qui permet de mettre du ruby dans du HTML, à la PHP). Il ne faudrait pas que le succès de Rails, qui n'est qu'un framework, fasse penser que Ruby n'est qu'un langage pour le Web.
Entièrement d'accord, j'adore Ruby comme remplaçant de Perl. C'est un langage objet qui permet de faire de gros scripts propres rapidement. Après, ma préférence Ruby par rapport à Python, elle est subjective.
Utiliser les lignes de code comme mesure, c'est biaisé: il faut généralement plus de lignes en PHP qu'en Ruby pour exprimer la même chose. C'est encore plus accentué avec Rails, qui repose sur tout un tas de conventions qui évitent d'écrire du code.
En même temp cette erreur de comparaison Langage/framework est fait par l'auteur du journal, relayant la même erreur (et d'autres ) faites par l'auteur de l'article pointé.
En clair quand tu jetes la pierre, vises plus à droite tu te trompes de cibles.
Difficile de tracer une ligne de démarcation nette entre framework et langage. PHP est certes un langage, mais généralement quand on parle de PHP on parle du langage et de sa bibliothèque standard, ce qui en fait... un framework.
En prenant le problème dans l'autre sens, Rails définit un langage de programmation en rajoutant des "mots" et des "concepts" au langage Ruby.
Non, un framework, ça ne se résume pas à une bibliothèque et un langage.
Un vrai framework offre avant tout un cadre de conception, une manière de développer, une façon d'organiser son code, ses fichiers : tu ne met pas tes classes n'importe où, tes templates n'importe où. Tu as des "guide lines" pour coder etc...
Et surtout, un framework est trés souvent orienté vers un type d'application précis.
PHP, tout comme ruby ou python, ne sont pas des frameworks. ce sont des langages. Le fait qu'il ait une bibliothèque standard ne les rend pas pour autant "framework".
Un vrai framework offre avant tout un cadre de conception, une manière de développer, une façon d'organiser son code, ses fichiers : tu ne met pas tes classes n'importe où
Ruby offre un cadre de conception, une manière de développer, une façon d'organiser son code, et tu ne mets pas tes classes n'importe où. Un exemple ?
require 'toto/titi'
Pourquoi on n'a pas donné un chemin sur le système de fichiers ? Parce qu'on ne met pas ses classes n'importe où, il y a une liste de chemins d'includes, qui sont parcourus dans l'ordre pour trouver tes classes. Les fonctions, les objets, les namespaces, les conventions de nommage, qu'est-ce qui fait partie du langage et qu'est ce qui fait partie du framework ?
Si tu n'est pas convaincu quand je dis qu'un langage+une bibliothèque forment un framework, essaye de prendre le problème à l'envers, et demande toi si un framework est un langage ou pas. Quand tu prends un bout de code de Rails:
class Blabla < ActiveRecord::Base
has_many :clients
validates_uniqueness_of :name
accessor :toto
end
Ces instructions sont des ajouts du framework. Sauf la dernière qui est une instruction de Ruby. Quelle est la différence avec des mots clés du langage, ou avec une bibliothèque de fonctions ? Qu'est-ce qui empêcherait de faire un compilateur du langage définir par Rails vers un autre langage ? Du point de vue de l'utilisateur, Rails définit un langage avec un peu plus d'instructions qu'en Ruby (d'ailleurs Rails modifie certains objets de la lib standard pour leur rajouter des fonctions), un peu plus de conventions, mais quoi d'autre ?
Je ne dis pas que PHP, Ruby et Rails ont la même puissance d'expression, mais faire une distinction entre langage et framework est arbitraire.
Et surtout, un framework est trés souvent orienté vers un type d'application précis.
Pourquoi on n'a pas donné un chemin sur le système de fichiers ? Parce qu'on ne met pas ses classes n'importe où, il y a une liste de chemins d'includes, qui sont parcourus dans l'ordre pour trouver tes classes. Les fonctions, les objets, les namespaces, les conventions de nommage, qu'est-ce qui fait partie du langage et qu'est ce qui fait partie du framework ?
Quand je dis une organisation de fichiers dans un framewrok, je ne parle pas d'une liste de chemins d'includes. Quand je dis organisé, c'est vraiment "organisé"
Un exemple, dans Jelix, tu met tes modules dans un répertoire précis. Dans un module, tu met tes objets métiers dans un sous repertoires "classes", les templates dans "templates", les controlleurs dans "controllers" etc... Et pas ailleurs.
Tu veux trouver la classe foo du module bar, tu sais tout de suite où la trouver. Dans un système avec une liste de chemin d'include, elle peut finalement être dans n'importe quel de ces chemins d'include. On a un alors une organisation moins structurée.
Cela ne veut pas dire que ce soit mal non plus. Mais avec une organisation stricte, en connaissant le framework, le dev va mieux s'y retrouver et trouver plus vite ce qu'il cherche, même si il ne connait pas l'appli, ce qui est plutôt avantageux pour la maintenance et l'évolution de l'appli,
Et cette organisation des fichiers d'une appli, ce n'est pas le langage qui l'impose, mais le framework.
Bref, dans un framework, en principe (et c'est son but), il y a plein de petite chose comme ça qui guide et oblige le développeur vers un respect de certaines "guidelines".
Pour moi, le Zend framework par exemple, il n'a de framework que le nom. Ce n'est qu'un ensemble de bibliothèque utilitaire. Il n'oblige à aucune organisation. Si tu veux faire une appli hyper bordélique, tu peux le faire. Avec un fmk comme jelix, c'est déjà beaucoup plus compliqué...
Je suis un développeur php, donc et mes connaissance sur ruby sont relativement limitée je l'avoue...
Mais je pense qu'il est complètement débile de comparer un ensemble de librairies, classes prédéfinies et fonctions a juste un langage...
Pour avoir une comparaison correcte j'aimerais franchement que la comparaison se fasse entre :
- ruby on rail
- php+pear !
Le projet pear a démarré un peux après et a sans doute peu de visibilité, mais il s'agit a mon avis de la partie manquante a php pour être au niveau de ruby...
De plus je pense sérieusement que ruby ne sera jamais au niveau de la vitesse de php (spécialement si on active le module de cache d'opcode apc !)
Quand au personne qui nous parle de la facilité de création de site avec ruby on rail via des scripts, on peux faire la même chose en php.
Il existe même une simplification extrêmement facile a faire, par exemple en utilisant le système d'inclusion automatique de classe, en utilisant le système _get(), _set() intégré au classe, etc...
Bref je pense que les personnes qui sont favorable au ruby n'ont pas vraiment cherché du côté de la programmation object en php5 (je considère la version 4 comme étant hors d'âge, soyons sérieux...)
Bref ruby on rail pour moi c'est juste un buzz comme ubuntu en son temps, c'est juste la même chose en plus récent et présenté différemment...
De plus je pense sérieusement que ruby ne sera jamais au niveau de la vitesse de php
Pourquoi ?
Quand au personne qui nous parle de la facilité de création de site avec ruby on rail via des scripts, on peux faire la même chose en php.
On peut tout faire avec n'importe quel langage (Turing-complet), donc effectivement on peut faire en PHP tout ce qu'on peut faire en Ruby. Par contre, tous les langages ne rendent pas toutes les tâches faciles à coder, et c'est là que le choix se fait.
(Je ne donnerais pas mon avis sur ce que PHP rend facile et ce que Ruby rend facile, j'ai cru comprendre que c'était réservé au vendredi)
Sympathique, tu considères Ruby on rails comme un buzz, tu penses que les personnes qui sont favorables à ruby n'ont pas cherché à connaitre PHP 5, alors que tu dis toi même que t'as jamais vraiment utilisé Ruby et Ruby on Rails.
Si tu recherches sur le Net, tu verras que de nombreux développeurs PHP 5, et même .NET et J2EE ont été conquis par ce framework, c'est pas sans raison. Le créateur même de Tomcat et Ant (James Duncan Davidson) est aujourd'hui un fervent utilisateur de Rails. Il y a énormément de développeurs très connus qui croient en Rails, c'est loin d'être un simple buzz pour moi.
Et moi j'ai programmé mon application de stage de fin d'étude entièrement en PHP 5 et en utilisant le maximum de librairies PEAR (HTML, Page2, DB_DataObject, DB_DataObject_QuickForm, Table, et j'en passe).
Pour moi je trouve ça sympa toutes ces bibliothèques pour PHP, ça permet d'aller plus vite et éviter les choses rébarbatives comme la création de formulaires à la main, etc. Mais ça reste de la programmation bête PHP sans vraie structure où le développeur est libre de faire du code spaegetti s'il le souhaite.
C'est loin de valoir Rails qui est un framework complet et qui incite au MVC, aux tests unitaires, etc.
J'ai donc découvert Ruby et RoR grâce à mon stage et en faisant des recherches. Apres mon stage j'ai approndi et j'ai clairement laissé tomber PHP et PEAR pour mes projets persos.
Aujourd'hui, retourner à du développement PHP 5+PEAR serait pour moi un grand retour en arrière. Mes quelques observations sur des frameworks PHP comme CakePHP et Symphony m'ont permis de constater qu'ils étaient loin du niveau de Rails. Ils se contentent pour une grande majorité de suivre et de recopier une grosse partie des fonctionnalités de ce framework en les adaptant avec plus ou moins de réussite en PHP.
En tout cas, j'ai donc testé un peu Symphony et CakePHP et regardé quelques screencasts et j'ai pas été convaincu.
Dans tous les cas, je suis pour Rails en ce moment aussi grâce à tous les bons développeurs qui sont derrière.
Il suffit d'aller faire un tour sur le Net pour voir à quel point ce projet est actif, qu'il y a des blogs dessus. Et pas uniquement des blogs qui disent "Rails c'est bon mangez-en" mais des blogs de développeurs passionnés qui proposent des tonnes d'astuces, de plug ins, d'améliorations dont une grosse partie se retrouvent au fur et a mesure dans le tronc commun et fait de Rails le framework Web le plus actif et le mieux pensé.
Et même au delà de Rails, Ruby est un langage tellement intuitif et puissant. D'accord, pour l'instant c'est encore assez lent, mais ça ça s'améliore et je dois dire que pour ce qu'on gagne au niveau du langage ça en vaut la peine.
Quand je refais du Java, j'ai l'impression de retourner en arrière ;-)
t'as oublié de rajouter que PHP, outil communiste au possible, était financé par les psychopathes de GNOME tandis que Rails, suppot(sitoire) du capitalisme, développé par un réfugié politique danois et une boite de costards cravates de Chicago, était épaulé par les sbires totalitaires germanophones de KDEkipu.
Sans compter que la majorité des devéloppeurs Rails utilisent des ordinateurs d'une certaine entreprise au logo d'un fruit croqué, un système et un éditeur de texte propriétaire capuecaypaslibre... preuve que le projet va irrémédiablement droit dans le mur.
Comme dit plus haut, comparer PHP à Rails c'est ridicule, ce sont deux choses différentes.
Maintenant, comparer Ruby à PHP, ben PHP n'en sortirait pas grandit :-)
Maintenant l'avantage énorme de PHP est qu'il est disponible partout ...
A ce propos, connaissez vous des hébergeurs Ruby ?
Pour ma part, j'héberge chez moi pour le développement, et quand j'aurai fini ce que je suis en train de préparer (du moins la première phase) je pense prendre quelque chose chez http://www.hostingrails.com (a voir).
J'avais essayé rails à la sortie de la première édition du agile web dev using rails (version anglaise, avec l'ancien graphe sur la premiere page, celui avec les roues du train sur le rail), j'avais laissé de côté parce que je n'avais aucun projet en cours, et je m'y suis remis il y a 3 semaines à dose de 2h par semaine (c'est peu hein !). Bah c'est impressionnant ce qu'on peut faire alors qu'on débute avec rails, et ce en 6h de temps.
Quitte à parler bouquin, je vous recommande d'attendre la 2è édition (prévue je crois pour décembre), elle contient des parties plutôt importantes de rails (genre migration) que la première n'a pas (et c'est bien dommage). On sent que cette première édition est bien mais reflète déjà un peu le passé de rails à cause de ça. Dommage qu'on ne puisse pas acheter juste les pages qui manquent/celles mises à jour. Le pdf c'est bien mais jamais je n'arriverai à me séparer de la version papier d'un livre de programmation...
Je suis développeur Ruby, ex PHPiste (ouais ok je cumule les tares, promis je commence le Ocaml bientot), et bien il faut quand meme avouer que Ruby, ca coute cher.
Je m'explique : c'est lent. Mega lent. Donc il faut du bon gros matos.
Avec PHP tu peux faire tourner des trucs rapidement, de manière performante, sur de l'hebergment mutualisé et ca tient la charge.
Avec Ruby, et à fortiori avec Rails, ce n'est pas possible.
On en revient au meme : PHP est un simple langage de script alors que Rails un framework complet avec dispatcheur, etc, il est clair qu'il nécessite plus de ressources.
Lors de la sortie de Rails, les développeurs ont déterré FastCGI et ont hébergé des projets directement avec Apache + FastCGI... Aujourd'hui on se rend compte que pour héberger des projets qui tiennent la charge, rien ne vaut Apache 2.2 avec ProxyLoadBalancer et un cluster de mini-serveurs Mongrel (serveur HTTP en Ruby) derrière.
Par contre, Rails fait beaucoup de choses en plus, entre autres analyser la base de données pour en déduire la structure de ses objets, et charger dynamiquement des extensions à la lib du langage, ce qui fait que sur un serveur qui lance un process à chaque requête, on perd un temps monstre au chargement.
A propos de l'hébergement c'est pas du coté français que tu trouveras des hébergeurs dynamiques qui te proposent les dernières technologies sachant que la plupart propose encore PHP 4 par défaut avec PHP 5 en option...
J'étais chez OVH mutualisé avant et ça me broutait vraiment de devoir m'amuser a renommer toutes mes pages .php5 pour avoir le support PHP 5 (et encore du PHP 5.0)... Après leur avoir envoyé un mail au support technique le technicien m'a répondu que c'est normal parce que PHP 5 est en BETA (!!!).
J'ai alors pris une Dedibox et c'est le paradis, je peux faire ce que je veux :D. Et 35 euros par mois pour avoir son propre serveur, et pouvoir mettre les dernieres technologies c'est pas tres cher.
# completement nulle comme étude.
Posté par Nicolas Blanco (site web personnel) . Évalué à 9.
En gros : ah, y a largement plus de code écrit en PHP, PHP est plus utilisé, alors PHP caymieux.
Ah bon. Cool. Y a largement plus de développeurs et d'utilisateurs Windows, c'est pas pour autant que c'est mieux.
PHP il existe depuis belle lurette, c'est un langage devenu limite un standard, alors que Ruby n'a décollé sur le Web que depuis l'avénement de RoR donc c'est clair que y avait pas besoin de faire une étude pour savoir que PHP est clairement plus utilisé.
De plus, comme d'habitude, on tente de comparer ce qui n'est pas comparable : PHP qui est un simple langage de script avec Ruby on Rails qui est un framework complet basé sur Ruby.
Selon moi il n'existe aucun framework basé sur PHP qui a actuellement autant de succès que Ruby on Rails. Et c'est pas sans raison...
Le couple Ruby on Rails + RadRails (environnement basé sur Eclipse avec éditeur de code à onglets, navigateur base de données, lancement des serveurs de tests, tests unitaires, débugguage) est "clairement" tueur.
[^] # Re: completement nulle comme étude.
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Peut être parce qu'il en existe des dizaines en PHP, et pas en ruby ? Donc marché morcelé, toussa....
[^] # Re: completement nulle comme étude.
Posté par Anonyme . Évalué à 2.
Reste a savoir s'il y en a un qui arrive a la cheville de RoR - toute la chaine confondue, en allant des éditeurs, abstraction de la base de donnée, aux outils de test et au débuggage. J'en doute ...
[^] # Re: completement nulle comme étude.
Posté par atmaniak (site web personnel) . Évalué à 3.
http://www.symfony-project.com/
[^] # Re: completement nulle comme étude.
Posté par zerchauve . Évalué à 1.
Je ne dis pas que c'est un critère objectif de jugement, ni meme un indicateur de qualité, c'est juste une constatation.
J'ai quand meme tendance à penser qu'un buzz se crée quand même autour de quelque chose de relativement novateur, etc..
Par exemple, et tu pourras certainement me renseigner, la génération de squelette d'application via un script Ruby, que tu as apparemment repris dans Jelix (que je redécouvre avec bonheur pour l'enseigner) , c'est quand meme une super idée non ? Ca existait avant ? (vraie question...)
Je suis tout a fait d'accord qu'on pourrait tuer RoR avec un killer framework en php5 (6), mais pour l'instant ce n'est pas le cas.
(et il y a aussi le parametre RadRails....)
[^] # Re: completement nulle comme étude.
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 4.
Non ça n'existait pas avant à ma connaissance. En même temps, les developpeurs PHP en général ont compris l'importance des framework PHP qu'il y a peut-être 3-4 ans...
Et puis il y a peut être aussi l'effet linux/windows. Va donc dire à un windowsien "ouvre ta console et tape ça"... En général il préfère une belle gui, ou que son IDE lui génère son archi apres 3 cliques.
Personnellement, je ne trouve pas que les scripts en ligne de commande de RoR soient innovants. Trés pratique, bonne idée, mais pas innovante du tout. Je crois plutôt que le succés de ces scripts, c'est surtout dû à une meilleure acceptation de la ligne de commande qu'avant, par les developpeurs web.
Mais à mon avis, rien ne vaut un "nouveau projet RoR/Jelix/Symphony/framework_que_tu_preferes" dans un IDE, et qui te créer d'office un squelette de ta nouvelle appli.
[^] # Re: completement nulle comme étude.
Posté par zerchauve . Évalué à 0.
perso je trouve ça très innovant, et ca mache le boulot pour le développeur d'IDE qui fait son boulot, de l'interface :)
[^] # Re: completement nulle comme étude.
Posté par Yusei (Mastodon) . Évalué à 4.
Il n'y a pas grand chose de Rails qui soit réellement innovant: les scripts qui génèrent du code, la possibilité de redéfinir le code dynamiquement, l'analyse de la base de données pour construire les objets, les langages de templates, l'intégration du système de tests, le système de modification incrémentable de la base, tout ça existe déjà ailleurs sous différentes formes.
Ce qui fait le succès de Rails, c'est surtout que tout est packagé autour d'un langage qui est expressif sans être dépaysant, et le fait que des conventions bien choisies évitent de devoir se coltiner avec ce dont on n'a pas besoin.
La modification dynamique de code, par exemple, ça existait depuis au moins aussi longtemps que Lisp, mais Lisp est plus difficile d'accès quand on vient de langages comme Java ou PHP.
# pas grand chose à voir en effet....
Posté par David Roon . Évalué à 3.
Sans parler du fait que Ruby est le language avec lequel on commence le plus de projet (selon l'un des graphs).
Bref venir nous dire que PHP est le language le plus répandu, en effet il n'y avait pas besoin d'un article pour ça. C'est peut-être qu'ils voulaient pouvoir dire qu'ils avaient une grosse bd avec des projets open source :)
Je n'ai pas encore codé avec Ruby, mais j'ai un ami développeur web et il ne jure que par ça. De ce que j'ai vu, c'est un language TRES compréhensible à la lecture.
Faut s'habituer quand on a l'habitude de coder en C like mais sinon il a l'air vraiment agréable.
Bref Ruby ça a l'air d'être du bon, et il ne faut pas oublier une autre chose, à chaque language son application. Il parle dans cet article de Python, en même temps Python c'est pas le language le plus orienté web que je connaisse.
Mais bon... Tout ça pour dire que l'article.... bof.
[^] # Re: pas grand chose à voir en effet....
Posté par Yusei (Mastodon) . Évalué à 4.
Ruby n'est pas franchement plus orienté web que Python (à part peut-être la présence depuis longtemps d'erb, qui permet de mettre du ruby dans du HTML, à la PHP). Il ne faudrait pas que le succès de Rails, qui n'est qu'un framework, fasse penser que Ruby n'est qu'un langage pour le Web.
[^] # Re: pas grand chose à voir en effet....
Posté par Frédéric COIFFIER . Évalué à 4.
# Lignes de code
Posté par Yusei (Mastodon) . Évalué à 6.
[^] # Re: Lignes de code
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
raaa voilà, encore une comparaison entre un framework et un langage....
Si tu prend n'importe quel framework en php, tu auras également moins de ligne de code à écrire.. (c'est normal, c'est fait pour)
[^] # Re: Lignes de code
Posté par blackshack . Évalué à 4.
En clair quand tu jetes la pierre, vises plus à droite tu te trompes de cibles.
[^] # Re: Lignes de code
Posté par Yusei (Mastodon) . Évalué à 1.
En prenant le problème dans l'autre sens, Rails définit un langage de programmation en rajoutant des "mots" et des "concepts" au langage Ruby.
[^] # Re: Lignes de code
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 3.
Un vrai framework offre avant tout un cadre de conception, une manière de développer, une façon d'organiser son code, ses fichiers : tu ne met pas tes classes n'importe où, tes templates n'importe où. Tu as des "guide lines" pour coder etc...
Et surtout, un framework est trés souvent orienté vers un type d'application précis.
PHP, tout comme ruby ou python, ne sont pas des frameworks. ce sont des langages. Le fait qu'il ait une bibliothèque standard ne les rend pas pour autant "framework".
[^] # Re: Lignes de code
Posté par Yusei (Mastodon) . Évalué à 3.
Ruby offre un cadre de conception, une manière de développer, une façon d'organiser son code, et tu ne mets pas tes classes n'importe où. Un exemple ?
require 'toto/titi'
Pourquoi on n'a pas donné un chemin sur le système de fichiers ? Parce qu'on ne met pas ses classes n'importe où, il y a une liste de chemins d'includes, qui sont parcourus dans l'ordre pour trouver tes classes. Les fonctions, les objets, les namespaces, les conventions de nommage, qu'est-ce qui fait partie du langage et qu'est ce qui fait partie du framework ?
Si tu n'est pas convaincu quand je dis qu'un langage+une bibliothèque forment un framework, essaye de prendre le problème à l'envers, et demande toi si un framework est un langage ou pas. Quand tu prends un bout de code de Rails:
class Blabla < ActiveRecord::Base
has_many :clients
validates_uniqueness_of :name
accessor :toto
end
Ces instructions sont des ajouts du framework. Sauf la dernière qui est une instruction de Ruby. Quelle est la différence avec des mots clés du langage, ou avec une bibliothèque de fonctions ? Qu'est-ce qui empêcherait de faire un compilateur du langage définir par Rails vers un autre langage ? Du point de vue de l'utilisateur, Rails définit un langage avec un peu plus d'instructions qu'en Ruby (d'ailleurs Rails modifie certains objets de la lib standard pour leur rajouter des fonctions), un peu plus de conventions, mais quoi d'autre ?
Je ne dis pas que PHP, Ruby et Rails ont la même puissance d'expression, mais faire une distinction entre langage et framework est arbitraire.
C'est aussi le cas de beaucoup de langages.
[^] # Re: Lignes de code
Posté par Laurent J (site web personnel, Mastodon) . Évalué à 2.
Quand je dis une organisation de fichiers dans un framewrok, je ne parle pas d'une liste de chemins d'includes. Quand je dis organisé, c'est vraiment "organisé"
Un exemple, dans Jelix, tu met tes modules dans un répertoire précis. Dans un module, tu met tes objets métiers dans un sous repertoires "classes", les templates dans "templates", les controlleurs dans "controllers" etc... Et pas ailleurs.
Tu veux trouver la classe foo du module bar, tu sais tout de suite où la trouver. Dans un système avec une liste de chemin d'include, elle peut finalement être dans n'importe quel de ces chemins d'include. On a un alors une organisation moins structurée.
Cela ne veut pas dire que ce soit mal non plus. Mais avec une organisation stricte, en connaissant le framework, le dev va mieux s'y retrouver et trouver plus vite ce qu'il cherche, même si il ne connait pas l'appli, ce qui est plutôt avantageux pour la maintenance et l'évolution de l'appli,
Et cette organisation des fichiers d'une appli, ce n'est pas le langage qui l'impose, mais le framework.
Bref, dans un framework, en principe (et c'est son but), il y a plein de petite chose comme ça qui guide et oblige le développeur vers un respect de certaines "guidelines".
Pour moi, le Zend framework par exemple, il n'a de framework que le nom. Ce n'est qu'un ensemble de bibliothèque utilitaire. Il n'oblige à aucune organisation. Si tu veux faire une appli hyper bordélique, tu peux le faire. Avec un fmk comme jelix, c'est déjà beaucoup plus compliqué...
[^] # Re: Lignes de code
Posté par Raphaël G. (site web personnel) . Évalué à 2.
Mais je pense qu'il est complètement débile de comparer un ensemble de librairies, classes prédéfinies et fonctions a juste un langage...
Pour avoir une comparaison correcte j'aimerais franchement que la comparaison se fasse entre :
- ruby on rail
- php+pear !
Le projet pear a démarré un peux après et a sans doute peu de visibilité, mais il s'agit a mon avis de la partie manquante a php pour être au niveau de ruby...
De plus je pense sérieusement que ruby ne sera jamais au niveau de la vitesse de php (spécialement si on active le module de cache d'opcode apc !)
Quand au personne qui nous parle de la facilité de création de site avec ruby on rail via des scripts, on peux faire la même chose en php.
Il existe même une simplification extrêmement facile a faire, par exemple en utilisant le système d'inclusion automatique de classe, en utilisant le système _get(), _set() intégré au classe, etc...
Bref je pense que les personnes qui sont favorable au ruby n'ont pas vraiment cherché du côté de la programmation object en php5 (je considère la version 4 comme étant hors d'âge, soyons sérieux...)
Bref ruby on rail pour moi c'est juste un buzz comme ubuntu en son temps, c'est juste la même chose en plus récent et présenté différemment...
[^] # Re: Lignes de code
Posté par Yusei (Mastodon) . Évalué à 2.
Pourquoi ?
On peut tout faire avec n'importe quel langage (Turing-complet), donc effectivement on peut faire en PHP tout ce qu'on peut faire en Ruby. Par contre, tous les langages ne rendent pas toutes les tâches faciles à coder, et c'est là que le choix se fait.
(Je ne donnerais pas mon avis sur ce que PHP rend facile et ce que Ruby rend facile, j'ai cru comprendre que c'était réservé au vendredi)
[^] # Re: Lignes de code
Posté par Nicolas Blanco (site web personnel) . Évalué à 4.
Si tu recherches sur le Net, tu verras que de nombreux développeurs PHP 5, et même .NET et J2EE ont été conquis par ce framework, c'est pas sans raison. Le créateur même de Tomcat et Ant (James Duncan Davidson) est aujourd'hui un fervent utilisateur de Rails. Il y a énormément de développeurs très connus qui croient en Rails, c'est loin d'être un simple buzz pour moi.
Et moi j'ai programmé mon application de stage de fin d'étude entièrement en PHP 5 et en utilisant le maximum de librairies PEAR (HTML, Page2, DB_DataObject, DB_DataObject_QuickForm, Table, et j'en passe).
Pour moi je trouve ça sympa toutes ces bibliothèques pour PHP, ça permet d'aller plus vite et éviter les choses rébarbatives comme la création de formulaires à la main, etc. Mais ça reste de la programmation bête PHP sans vraie structure où le développeur est libre de faire du code spaegetti s'il le souhaite.
C'est loin de valoir Rails qui est un framework complet et qui incite au MVC, aux tests unitaires, etc.
J'ai donc découvert Ruby et RoR grâce à mon stage et en faisant des recherches. Apres mon stage j'ai approndi et j'ai clairement laissé tomber PHP et PEAR pour mes projets persos.
Aujourd'hui, retourner à du développement PHP 5+PEAR serait pour moi un grand retour en arrière. Mes quelques observations sur des frameworks PHP comme CakePHP et Symphony m'ont permis de constater qu'ils étaient loin du niveau de Rails. Ils se contentent pour une grande majorité de suivre et de recopier une grosse partie des fonctionnalités de ce framework en les adaptant avec plus ou moins de réussite en PHP.
En tout cas, j'ai donc testé un peu Symphony et CakePHP et regardé quelques screencasts et j'ai pas été convaincu.
Dans tous les cas, je suis pour Rails en ce moment aussi grâce à tous les bons développeurs qui sont derrière.
Il suffit d'aller faire un tour sur le Net pour voir à quel point ce projet est actif, qu'il y a des blogs dessus. Et pas uniquement des blogs qui disent "Rails c'est bon mangez-en" mais des blogs de développeurs passionnés qui proposent des tonnes d'astuces, de plug ins, d'améliorations dont une grosse partie se retrouvent au fur et a mesure dans le tronc commun et fait de Rails le framework Web le plus actif et le mieux pensé.
[^] # Re: Lignes de code
Posté par Nelis (site web personnel) . Évalué à 6.
Quand je refais du Java, j'ai l'impression de retourner en arrière ;-)
# Troll powered
Posté par Cyril PIERRE de GEYER (site web personnel) . Évalué à -3.
Merci journal :;)
[^] # Re: Troll powered
Posté par zerchauve . Évalué à 2.
t'as oublié de rajouter que PHP, outil communiste au possible, était financé par les psychopathes de GNOME tandis que Rails, suppot(sitoire) du capitalisme, développé par un réfugié politique danois et une boite de costards cravates de Chicago, était épaulé par les sbires totalitaires germanophones de KDEkipu.
[^] # Re: Troll powered
Posté par Nicolas Blanco (site web personnel) . Évalué à 1.
# Ridicule
Posté par Nelis (site web personnel) . Évalué à 3.
Maintenant, comparer Ruby à PHP, ben PHP n'en sortirait pas grandit :-)
Maintenant l'avantage énorme de PHP est qu'il est disponible partout ...
A ce propos, connaissez vous des hébergeurs Ruby ?
[^] # Re: Ridicule
Posté par iznogoud . Évalué à 2.
http://www.railsfrance.org/node/274
Pour ma part, j'héberge chez moi pour le développement, et quand j'aurai fini ce que je suis en train de préparer (du moins la première phase) je pense prendre quelque chose chez http://www.hostingrails.com (a voir).
J'avais essayé rails à la sortie de la première édition du agile web dev using rails (version anglaise, avec l'ancien graphe sur la premiere page, celui avec les roues du train sur le rail), j'avais laissé de côté parce que je n'avais aucun projet en cours, et je m'y suis remis il y a 3 semaines à dose de 2h par semaine (c'est peu hein !). Bah c'est impressionnant ce qu'on peut faire alors qu'on débute avec rails, et ce en 6h de temps.
Quitte à parler bouquin, je vous recommande d'attendre la 2è édition (prévue je crois pour décembre), elle contient des parties plutôt importantes de rails (genre migration) que la première n'a pas (et c'est bien dommage). On sent que cette première édition est bien mais reflète déjà un peu le passé de rails à cause de ça. Dommage qu'on ne puisse pas acheter juste les pages qui manquent/celles mises à jour. Le pdf c'est bien mais jamais je n'arriverai à me séparer de la version papier d'un livre de programmation...
[^] # Re: Ridicule
Posté par zerchauve . Évalué à 4.
Je m'explique : c'est lent. Mega lent. Donc il faut du bon gros matos.
Avec PHP tu peux faire tourner des trucs rapidement, de manière performante, sur de l'hebergment mutualisé et ca tient la charge.
Avec Ruby, et à fortiori avec Rails, ce n'est pas possible.
[^] # Re: Ridicule
Posté par Nicolas Blanco (site web personnel) . Évalué à 1.
Lors de la sortie de Rails, les développeurs ont déterré FastCGI et ont hébergé des projets directement avec Apache + FastCGI... Aujourd'hui on se rend compte que pour héberger des projets qui tiennent la charge, rien ne vaut Apache 2.2 avec ProxyLoadBalancer et un cluster de mini-serveurs Mongrel (serveur HTTP en Ruby) derrière.
Je vous recommande cette lecture :
http://blog.codahale.com/2006/06/19/time-for-a-grown-up-serv(...)
[^] # Re: Ridicule
Posté par zerchauve . Évalué à 1.
Après la vitesse pure c'est pas forcément une nécessité hein !
Ensuite, ta config avec Mongrel m'intéresse carrément, tu penses qu'il est possible d'arriver a faire tourner des trucs comme ça facilement ?
[^] # Re: Ridicule
Posté par Yusei (Mastodon) . Évalué à 1.
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
http://shootout.alioth.debian.org/debian/benchmark.php?test=(...)
Par contre, Rails fait beaucoup de choses en plus, entre autres analyser la base de données pour en déduire la structure de ses objets, et charger dynamiquement des extensions à la lib du langage, ce qui fait que sur un serveur qui lance un process à chaque requête, on perd un temps monstre au chargement.
[^] # Re: Ridicule
Posté par Nicolas Blanco (site web personnel) . Évalué à 2.
J'étais chez OVH mutualisé avant et ça me broutait vraiment de devoir m'amuser a renommer toutes mes pages .php5 pour avoir le support PHP 5 (et encore du PHP 5.0)... Après leur avoir envoyé un mail au support technique le technicien m'a répondu que c'est normal parce que PHP 5 est en BETA (!!!).
J'ai alors pris une Dedibox et c'est le paradis, je peux faire ce que je veux :D. Et 35 euros par mois pour avoir son propre serveur, et pouvoir mettre les dernieres technologies c'est pas tres cher.
Suivre le flux des commentaires
Note : les commentaires appartiennent à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.