Excuse moi , j'étais un peu fatigué quand j'ai lancé le bon troll sur l" "x10 plus puissant que Python" :). Mais je maintiens que Ruby est stricto facto plus puissant que Pytho au niveau pouvoir d'expression.
Bien sûr, il existe plein de bon langage super bien conçu que sont mort industriellement, je ne citerais que SmallTalk qui était trop nouveau pour son époque (et qui n'a pas été des mieux gérés niveau commercial (problème de licence d'utilisation))
> les fonctionnalités intrinsèques d'un langage, ne t'en déplaise, ne SONT PAS IMPORTANTES !!! et ne font pas qu'un language soit adopté !!!!
La dessus, je ne suis pas d'accord, l'avantage de Ruby par rapport à Python, c'est justement d'apporter ce petit plus par rapport aux autres langages. Je m'explique : pour les 3/4 des logiciels, actuellement on s'en fout de se genre de fonctionnalités, et d'ailleurs qu'on écrivent ces derniers en Python ou en Ruby le code se ressemblera surement au niveau structure. Par contre, pour le dernier quart, Ruby permet d'envisager d'autres méthodes de conception/codage n'étant pas accessible (ou difficilement ou encore par des méthodes assez moches) dans Python par exemple. Prennons l'exemple de RubyOnRails, je ne pas regardé le code, mais j'imagine que ça doit utiliser plein de fonctionnalité d'introspection, de surcharge etc. . Si une version PythonOnRails sort ça serait intéressant de comparer la lisibilité du code, mais dans les parties un peu chaude, j'ai peur que le code ressemble à une potion magique de fonctions aux noms étranges. Après, c'est sûr que de toute façon, pour utiliser ce genre de fonctionnalité il faut avoir une vue des langages assez abstraite, et que pour qqun qui n'a fait que du C ça devrait sembler assez incompréhensible (changer à la volée le code executé même si c'est possible en C, ce n'est pas très courant).
Pour résumer, ce que je trouve bien avec Ruby par rapport à Python, c'est qu'il a franchi une étape de plus vers l'abstraction des langages informatique (disons pour être plus cohérents qu'il rejoint SmallTalk sur ce point :). Ça permettra surement au gens qui essayent Ruby (comme toi il me semble) de découvrir des nouveaux paradigmes qu'ils ne sont pas obligé d'utiliser mais qui a coup sûr leurs permettrons de faire évoluer leur manière de coder. Et aujourd'hui on demande de plus en plus aux programmes de supporter des plugins, de modifier leurs comportements à la volée, de gérer la persistance de leurs données .... Tu vas me dire qu'ils existent des dizaines de framework qui permettent de fair ça en Python ... et je te réponderais que le problème des frameworks c'est leur rigidité (tu l'as dit toi même plus haut) et qu'au contraire apporter des fonctionnalités comme le propose Ruby permet au programmeur de réaliser ce genre de chose lui-même en un temps record (et qui de plus correspondera à ses besoins). Par exemple j'ai réaliser en moins d'une heure un système de cache d'information et stockage persistent d'objet complétement transparents (en utilisant le method_missing, et la serialisation. le client appele ça méthode normalement et la mise à jour des informations et leurs sauvegardes sont faites automatiquement). En Java (que je connais bien aussi) ça m'aurait surement pris plus de temps et m'aurait obligé à définir un nouveau protocole pour les appels clients.
Pour les librairies, plus la communauté Rubiste augmentera plus ça avancera vite, et pour ton délai de 4/5 ans je trouve assez méchant, il suffit de voir le temps qu'à mis Python à rattraper Perl dans ce domaine.
Bon on peux s'accorder sur le point suivant je pense : Python a 10x plus de librairies que Ruby, mais Ruby a 10x plus de puissance d'expression que Python ... le problème c'est que Python d'après ce que tu dis à propos de ses dév ne gagnera plus grand chose en pouvoir d'expression ... par contre Ruby ne peux qu'avoir des librairies en plus.
Enfin, je pense que si tout le monde se limitait à dire 'y'a pas assez de lib pour investir dans ce langage' (comme tu le dis pour Ruby), en serait toujours en train de coder en C en utilisant la Glib :). Et pour vraiment finir (promis), Ruby aura toujours moins de libs que Python (comme Python en aura moins que Perl) car tout simplement la commauté Ruby (comme celle de Python envers Perl) évitera de développer celles qui ont peu d'intérêt (la plupart du temps car une nouvelle lib a supplantée la version historique).
[^] # Re: Différence avec Python ?
Posté par pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. Évalué à 2.
Bien sûr, il existe plein de bon langage super bien conçu que sont mort industriellement, je ne citerais que SmallTalk qui était trop nouveau pour son époque (et qui n'a pas été des mieux gérés niveau commercial (problème de licence d'utilisation))
> les fonctionnalités intrinsèques d'un langage, ne t'en déplaise, ne SONT PAS IMPORTANTES !!! et ne font pas qu'un language soit adopté !!!!
La dessus, je ne suis pas d'accord, l'avantage de Ruby par rapport à Python, c'est justement d'apporter ce petit plus par rapport aux autres langages. Je m'explique : pour les 3/4 des logiciels, actuellement on s'en fout de se genre de fonctionnalités, et d'ailleurs qu'on écrivent ces derniers en Python ou en Ruby le code se ressemblera surement au niveau structure. Par contre, pour le dernier quart, Ruby permet d'envisager d'autres méthodes de conception/codage n'étant pas accessible (ou difficilement ou encore par des méthodes assez moches) dans Python par exemple. Prennons l'exemple de RubyOnRails, je ne pas regardé le code, mais j'imagine que ça doit utiliser plein de fonctionnalité d'introspection, de surcharge etc. . Si une version PythonOnRails sort ça serait intéressant de comparer la lisibilité du code, mais dans les parties un peu chaude, j'ai peur que le code ressemble à une potion magique de fonctions aux noms étranges. Après, c'est sûr que de toute façon, pour utiliser ce genre de fonctionnalité il faut avoir une vue des langages assez abstraite, et que pour qqun qui n'a fait que du C ça devrait sembler assez incompréhensible (changer à la volée le code executé même si c'est possible en C, ce n'est pas très courant).
Pour résumer, ce que je trouve bien avec Ruby par rapport à Python, c'est qu'il a franchi une étape de plus vers l'abstraction des langages informatique (disons pour être plus cohérents qu'il rejoint SmallTalk sur ce point :). Ça permettra surement au gens qui essayent Ruby (comme toi il me semble) de découvrir des nouveaux paradigmes qu'ils ne sont pas obligé d'utiliser mais qui a coup sûr leurs permettrons de faire évoluer leur manière de coder. Et aujourd'hui on demande de plus en plus aux programmes de supporter des plugins, de modifier leurs comportements à la volée, de gérer la persistance de leurs données .... Tu vas me dire qu'ils existent des dizaines de framework qui permettent de fair ça en Python ... et je te réponderais que le problème des frameworks c'est leur rigidité (tu l'as dit toi même plus haut) et qu'au contraire apporter des fonctionnalités comme le propose Ruby permet au programmeur de réaliser ce genre de chose lui-même en un temps record (et qui de plus correspondera à ses besoins). Par exemple j'ai réaliser en moins d'une heure un système de cache d'information et stockage persistent d'objet complétement transparents (en utilisant le method_missing, et la serialisation. le client appele ça méthode normalement et la mise à jour des informations et leurs sauvegardes sont faites automatiquement). En Java (que je connais bien aussi) ça m'aurait surement pris plus de temps et m'aurait obligé à définir un nouveau protocole pour les appels clients.
Pour les librairies, plus la communauté Rubiste augmentera plus ça avancera vite, et pour ton délai de 4/5 ans je trouve assez méchant, il suffit de voir le temps qu'à mis Python à rattraper Perl dans ce domaine.
Bon on peux s'accorder sur le point suivant je pense : Python a 10x plus de librairies que Ruby, mais Ruby a 10x plus de puissance d'expression que Python ... le problème c'est que Python d'après ce que tu dis à propos de ses dév ne gagnera plus grand chose en pouvoir d'expression ... par contre Ruby ne peux qu'avoir des librairies en plus.
Enfin, je pense que si tout le monde se limitait à dire 'y'a pas assez de lib pour investir dans ce langage' (comme tu le dis pour Ruby), en serait toujours en train de coder en C en utilisant la Glib :). Et pour vraiment finir (promis), Ruby aura toujours moins de libs que Python (comme Python en aura moins que Perl) car tout simplement la commauté Ruby (comme celle de Python envers Perl) évitera de développer celles qui ont peu d'intérêt (la plupart du temps car une nouvelle lib a supplantée la version historique).