et franchement le code python m'a tout de suite parlé ...
C'est pas mal ça de dire que tu comprends mieux le code Python en disant 5 lignes plus tard que tu connais très bien Python :). De même je comprends beaucoup mieux l'anglais que l'allemand que je n'ai jamais appris :).
si tu viens de perl/bash ... le ruby te parlera mieux, c évident
Tu ne dois vraiment pas connaître Perl et Bash pour dire que Ruby ressemble à ces langages ! Mise à part les variables spéciales ($*) et les expressions régulières intégrées dans Ruby, il n'y a aucun point commun.
Après effectivement, pour des gens ayant appris à coder en C/C++ le Python sera surement plus lisible. Par contre le pense que Ruby est bien plus lisible pour des personnes ayant programmés en Java/SmallTalk/Eiffel que des personnes ayant fait du Perl/Bash.
(je pense que plus de dev sur terre viennent du monde c/pascal/cobol/basic que du monde perl/bash)
C'est à vérifier, car actuellement il me semble que dans les formations en informatique (sauf industrielle) on insiste plus sur les technologies objets (Java/C#/J2EE/.Net/C++ ...) que sur les langages procéduraux de type C/Pascal/Cobol/Basic qui sont bien sur toujours abordés pour des raisons historiques et techniques. Ça n'enlève rien à la puissance et l'utilité de ces langages.
et même si t'es pas développeur du tout, le python te parlera plus (c là son avantage sur sa syntaxe)
Pour la lisibilité du code pour un non développeur, je te trouve bien présomptueux, je ne me risquerais pas à dire quel langage serait le mieux. Tout dépend des bases que les personnes ont. Si tu apprends à quelqu'un à penser en procédural, il sera attiré par la syntaxe Python, en revanche si tu lui apprends à penser Objet, il sera surement attiré par Ruby.
maintenant, quand à l'argument ruby est full OO, alors que c venu après sur python .... bof aussi ... car le full OO, t'obliges à programmer en OO uniquement ! et ça je sais pas si c'est un avantage ... (en python, t'as le choix)
En Ruby aussi tu as le choix mais pour ce qui de programmer en 'full OO', personnelement je trouve que c'est un véritable avantage, ça te force à bien structurer ton programme. J'ai longtemps écrit des programmes en Perl qui marchait pas mal, par contre au niveau maintenabilité du code c'était ingérable. Je ne parle même pas de mes essais pour faire du code objet en Perl (quelle horreur, j'attends Perl6 pour voir si ça s'arrange de ce coté là). J'ai commencé à réécrire des programmes Perl en Ruby et effectivement même si c'est possible de faire une transcription bête et méchante (sans notion OO), j'ai très rapidement séparé mes bouts de code dans différentes classes. À la fin, je me retrouve avec un code moins long et beaucoup mieux organisé.
le cas du self : tu peux l'appeler "S" ou "_" au lieu de self, tu gagneras 3 caracs ... (par convention de programmation, self c mieux, evidemment)
J'aime bien les gens qui défendent mordicus les faiblesses/erreurs de conception d'un langage comme des 'features', que ce soit en Java (héritage simple), Perl (références), Python (le self dans les paramètres des messages). Pour ce qui est du 'self', je suis d'accord que c'est plus lisible de le laisser quand on fait appel à une variable, ça permet d'un coup d'oeil de savoir si une variable est locale ou appartient à l'instance de la classe. Mais de là à laisser le 'self' comme premier paramètre d'une méthode, c'est un peu gros :).
mais je trouve que le code ruby est rempli de hiéroglyphes qui ne me parlent pas du tout au premier abord ... et ne me donnent pas envi ...
Pour les 'hiéroglyphes', j'aimerais bien des exemples !
maintenant, tout ça est subjectif ... chacun ses gouts et ses couleurs (heureusement)
Ah, je suis enfin d'accord avec toi :). Mais je me suis permis de te répondre car je trouvais ton post un peu trop trollesque.
moi je choisi pas le langage en fonction de ses qualités intrasecs, mais en fonction de ce qui va m'apporter ...
Ah, pour moi les qualités intrasecs d'un langage jouent beaucoup sur ce qu'il va m'apporter. Le pouvoir d'expression d'un langage est pour moi très important, j'ai horreur de passer 2 heures pour trouver une façon d'avoir une fonctionnalité non incluses dans un langage (genre surcharges des classes de bases, modification à l'exécution de code des classes ...).
et en python, au niveau libs, c bien simple, tu peux tout faire dans tous les domaines ...
Tu serais surpris de voir le nombre de libs disponibles en Ruby, même si ces dernières sont actuellement dispatchées et manque de suivies (vive RubyGems).
au niveau ouverture, tu peux faire des classes java, tout comme des classes dot.net ....
C'est aussi possible pour Java en Ruby en utilisant JRuby http://jruby.sourceforge.net/(...) .
que demander de plus ? non ?
Personnelement, je demanderais à Python de devenir vraiment objet, d'inclure les itérateurs à la manière de SmallTalk ... il semblerait que les dernières version de Python répondent à certaines de ces attentes ... hélas j'ai depuis longtemps trouvé un langage réalisant déjà cela : Ruby.
Bref, Python et Ruby, ça n'est pas pareil, et c'est un peu idiot de les comparer même s'ils ont la même cible. Tu préféres Python, je préfére Ruby, chacun à ces raisons, mais j'ai au moins l'avantage d'avoir essayé pas mal des langages de script (je fais aussi du Python de temps en temps) avant de donner mon avis.
[^] # Re: Différence avec Python ?
Posté par pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. Évalué à 5.
C'est pas mal ça de dire que tu comprends mieux le code Python en disant 5 lignes plus tard que tu connais très bien Python :). De même je comprends beaucoup mieux l'anglais que l'allemand que je n'ai jamais appris :).
si tu viens de perl/bash ... le ruby te parlera mieux, c évident
Tu ne dois vraiment pas connaître Perl et Bash pour dire que Ruby ressemble à ces langages ! Mise à part les variables spéciales ($*) et les expressions régulières intégrées dans Ruby, il n'y a aucun point commun.
Après effectivement, pour des gens ayant appris à coder en C/C++ le Python sera surement plus lisible. Par contre le pense que Ruby est bien plus lisible pour des personnes ayant programmés en Java/SmallTalk/Eiffel que des personnes ayant fait du Perl/Bash.
(je pense que plus de dev sur terre viennent du monde c/pascal/cobol/basic que du monde perl/bash)
C'est à vérifier, car actuellement il me semble que dans les formations en informatique (sauf industrielle) on insiste plus sur les technologies objets (Java/C#/J2EE/.Net/C++ ...) que sur les langages procéduraux de type C/Pascal/Cobol/Basic qui sont bien sur toujours abordés pour des raisons historiques et techniques. Ça n'enlève rien à la puissance et l'utilité de ces langages.
et même si t'es pas développeur du tout, le python te parlera plus (c là son avantage sur sa syntaxe)
Pour la lisibilité du code pour un non développeur, je te trouve bien présomptueux, je ne me risquerais pas à dire quel langage serait le mieux. Tout dépend des bases que les personnes ont. Si tu apprends à quelqu'un à penser en procédural, il sera attiré par la syntaxe Python, en revanche si tu lui apprends à penser Objet, il sera surement attiré par Ruby.
maintenant, quand à l'argument ruby est full OO, alors que c venu après sur python .... bof aussi ... car le full OO, t'obliges à programmer en OO uniquement ! et ça je sais pas si c'est un avantage ... (en python, t'as le choix)
En Ruby aussi tu as le choix mais pour ce qui de programmer en 'full OO', personnelement je trouve que c'est un véritable avantage, ça te force à bien structurer ton programme. J'ai longtemps écrit des programmes en Perl qui marchait pas mal, par contre au niveau maintenabilité du code c'était ingérable. Je ne parle même pas de mes essais pour faire du code objet en Perl (quelle horreur, j'attends Perl6 pour voir si ça s'arrange de ce coté là). J'ai commencé à réécrire des programmes Perl en Ruby et effectivement même si c'est possible de faire une transcription bête et méchante (sans notion OO), j'ai très rapidement séparé mes bouts de code dans différentes classes. À la fin, je me retrouve avec un code moins long et beaucoup mieux organisé.
le cas du self : tu peux l'appeler "S" ou "_" au lieu de self, tu gagneras 3 caracs ... (par convention de programmation, self c mieux, evidemment)
J'aime bien les gens qui défendent mordicus les faiblesses/erreurs de conception d'un langage comme des 'features', que ce soit en Java (héritage simple), Perl (références), Python (le self dans les paramètres des messages). Pour ce qui est du 'self', je suis d'accord que c'est plus lisible de le laisser quand on fait appel à une variable, ça permet d'un coup d'oeil de savoir si une variable est locale ou appartient à l'instance de la classe. Mais de là à laisser le 'self' comme premier paramètre d'une méthode, c'est un peu gros :).
mais je trouve que le code ruby est rempli de hiéroglyphes qui ne me parlent pas du tout au premier abord ... et ne me donnent pas envi ...
Pour les 'hiéroglyphes', j'aimerais bien des exemples !
maintenant, tout ça est subjectif ... chacun ses gouts et ses couleurs (heureusement)
Ah, je suis enfin d'accord avec toi :). Mais je me suis permis de te répondre car je trouvais ton post un peu trop trollesque.
moi je choisi pas le langage en fonction de ses qualités intrasecs, mais en fonction de ce qui va m'apporter ...
Ah, pour moi les qualités intrasecs d'un langage jouent beaucoup sur ce qu'il va m'apporter. Le pouvoir d'expression d'un langage est pour moi très important, j'ai horreur de passer 2 heures pour trouver une façon d'avoir une fonctionnalité non incluses dans un langage (genre surcharges des classes de bases, modification à l'exécution de code des classes ...).
et en python, au niveau libs, c bien simple, tu peux tout faire dans tous les domaines ...
Tu serais surpris de voir le nombre de libs disponibles en Ruby, même si ces dernières sont actuellement dispatchées et manque de suivies (vive RubyGems).
au niveau ouverture, tu peux faire des classes java, tout comme des classes dot.net ....
C'est aussi possible pour Java en Ruby en utilisant JRuby http://jruby.sourceforge.net/(...) .
que demander de plus ? non ?
Personnelement, je demanderais à Python de devenir vraiment objet, d'inclure les itérateurs à la manière de SmallTalk ... il semblerait que les dernières version de Python répondent à certaines de ces attentes ... hélas j'ai depuis longtemps trouvé un langage réalisant déjà cela : Ruby.
Bref, Python et Ruby, ça n'est pas pareil, et c'est un peu idiot de les comparer même s'ils ont la même cible. Tu préféres Python, je préfére Ruby, chacun à ces raisons, mais j'ai au moins l'avantage d'avoir essayé pas mal des langages de script (je fais aussi du Python de temps en temps) avant de donner mon avis.