ruby ou python

Oui donc on est d'accord, ce sont plus des questions de philosophie de langages ou de style de code, plus que de caractéristiques intrinsèque des langages. Choisir entre les deux se fait principalement au filing qu'aux capacités.

On est complètement d'accord ! J'aurais tendance à préférer Ruby pour manipuler du texte dans le sens où on ressent vraiment très plein beaucoup l'héritage de Perl dans ce langage. Alors que pour du traitement plus numérique, plus scientifique, j'aurais plutôt envie de me tourner vers Python qui lui, est mieux fourni de ce côté.

Mais de manière général, je suis complèment d'accord sur le fait que le choix est avant tout philosophique. Pour raconter un peu ma vie, j'ai l'habitude de langages "un peu chiant" niveau typage (OCaml, Haskell…) et quand j'ai voulu tester des langages à typage dynamique, j'ai très mal vécu le côté "bonjour, mon typage est dynamique, on dirait que c'est le bordel, mais il est très fort quand même" de Python qui te montre sympatie d'un côté et intransigeance de l'autre. Face à lui, Ruby, qui est clairement bordélique dans son typage (duck typing jusqu'au bout des ongles), au moins tu sais à quoi t'en tenir. Tout ça pour montrer que le choix entre les deux tient soit du goût du programmeur, soit du goût du patron.

Ce serait bien de ne pas tronquer tes citations, histoire de ne pas me faire dire ce que je n'ai pas dit …

J'utilise Emacs, jusqu'à preuve du contraire, il est pas trop pourri. Le seul langage qu'il indente mal, c'est Python. Parce qu'un bloc de code en python est très mal délimité, typiquement, quand je code, je fait C-x, h TAB, et pouf, j'ai un joli code indenté. Bah la, non, c'est pas parfait, il faut se retaper le code a la main pour voir s'il n'y a pas une instruction qui se balade en dehors d'un for.

Après je me doutais bien qu'on allait pas être d'accord avec moi, mais je ne pensais pas qu'on allait être d'aussi mauvaise foi… Je n'ai jamais dis que Python est merdique, contrairement a ce que raconte le camarade du dessus. J'ai dit que sa syntaxe me les brisait menu. Il y a un monde entre les deux affirmations.

Bref, t'es pas obligé d'être désagréable quand on est pas d'accord avec toi.

Bah la, non, c'est pas parfait, il faut se retaper le code a la main pour voir s'il n'y a pas une instruction qui se balade en dehors d'un for.

En même temps c'est parce que tu demande a ton éditeur de faire l'indentation automatiquement. Forcément ça ne peut pas marcher en python puisque celle-ci fait partie intégrante de la syntaxe.

C'est comme si tu demandais a ton éditeur de placer automatiquement les accolades ouvrantes et fermantes à ta place dans un langage type C. Il ne peut pas sans plus d'informations.

J'utilise Emacs, jusqu'à preuve du contraire, il est pas trop pourri.

J'utilise Geany qui est loin d'être encensé comme Emacs et je n'ai jamais eu ce soucis d'indentation.

mais je ne pensais pas qu'on allait être d'aussi mauvaise foi

Ce n'est pas de la mauvaise foi, lis bien nos réponses

Je n'ai jamais dis que Python est merdique, contrairement a ce que raconte le camarade du dessus.

On a ensuite bien compris que tu parlais d'éditeur

J'ai dit que sa syntaxe me les brisait menu.

C'est, on est bien d'accord une affaire de goût et en tout état de cause, rien qui puisse influencer le PO sur un choix de langage, car des aficionados python, pourraient dire la même chose de ruby, non?

Bref, t'es pas obligé d'être désagréable quand on est pas d'accord avec toi.

Les forums sont des systèmes de lectures, ne donnant pas le ton sur telles ou telles affirmations. Désolé si tu l'as mal pris, mais faire court sur ce genre de choses est déjà difficile, et tourner les phrases pour qu'elles soient belles et fassent plaisir, c'est pas mon genre.

Après je me doutais bien qu'on allait pas être d'accord

Avec tous les efforts du monde, désolé je ne peux pas…

Kje a l'air d'avoir donner une réponse qui me convient. C'est ce que je reproche a Python, sa syntaxe a coup de tabulation, la ou je préfère des délimiteurs.

Dans tous les cas il faut être conscient que Python est un langage avec une grosse part de philosophie derrière. Les conventions en Python sont très importantes. Après concernant l'auteur du sujet, sans plus de précision, je ne sais pas ce qu'on peut lui conseiller d'autres que d'essayer les deux. Perso je préfère largement Python mais j'ai conscience que c'est une question de goût (et d'utilisation, je fais pas mal de calculs scientifique) et ce que j'aime ou fait avec ne correspond pas forcément à ce que l'auteur attend.

Je viens d'avoir ce choix de langages il y a 15 jours:je désirais coder rapidement avec qt une petite appli sous Linux. j'ai choisi entre Python(pyQt) ou Ruby en fonction des ressources.

je dois dire que Ruby me donne des boutons! mais ça va puisque je viens de voir + haut que c'est a moi de m'adapter Je suis aussi peut-être déçu car j'attendais trop de ce langage que je pensais parfait vu sa "célébrité" Du coup c'est sur, je vais tester plus tard Ruby.

Euh. Sûrement relevé plus haut, mais la philosophie de Python est fondamentalement orientée objet. Perso je suis un aficionado forcené de Python, mais le plus objectivement possible je dirais, à l'avantage de celui-ci :

• une belle lisibilité du code (c'est très subjectif mais Python est le langage qui fournit les plus beaux codes sources àmha, excepté peut-être LISP ) ;
• une communauté plus étendue et réactive.

Après, je connais pas assez Ruby pour pouvoir bien comparer, et aucun jugement ne peut s'abstraire totalement de la subjectivité de celui qui l'énonce. Pour ce qui est de Django, j'ai découvert ce framework il y a peu, et je suis encore très impressionné par sa souplesse, sa simplicité de mise en place et sa complexité potentielle.

Edit : après lecture du reste du sujet, my two final cents sur la philosophie de Python. C'est un langage globalement bien pensé, avec des conventions agréables pour peu qu'on choisisse de les suivre (en gros tu peux faire n'imps, mais tu peux aussi faire du code fonctionnel et élégant) ; il possède un réel esprit orienté objet, avec ses avantages et ses inconvénients ; il est très polyvalent et aussi adapté pour du scripting rapido que pour du calcul scientifique ou du serveur si t'as que ça à faire. Quelques points tels que le typage cité par un camarade plus haut (et que je rejoins allègrement) peuvent te faire tiquer, mais voilà l'idée générale : un langage cohérent et, quelque part, esthétique.

C'est marrant, on peut remplacer Ruby par Python et inversement, et ça fonctionne aussi. Et concernant la cohérence, il y a bien des situations où Python n'est pas cohérent - la programmation fonctionnelle en Python est une hérésie, encore heureux que personne ne l'utilise.

Enfin, au delà des inepties qu'on peut noter, ça reste un débat sans fin. Le mieux serait d'attendre la réponse de l'OP ou de tout simplement clôturer le sujet qui, en l'état, ne peut que deviez sur "Qu'elle est le meilleur langage".

Un point négatif pour le python : le cassage des codes entre python 2.6 et 3.x, le fait que certains modules ne tournent qu'avec 2.6. Voir ici pour plus d'info et l'absence totale de garantie sur les éventuelles brisures entre les branches 3.x et la future 4.x

Alors que je ne pense pas s'il y ait eu de telles choses avec Ruby (je peux me tromper).

Sinon on peut aussi intégrer Lua dans le débat.

l'absence totale de garantie sur les éventuelles brisures entre les branches 3.x et la future 4.x

Mouais. La première version de Python 3 date de 2008 et Python 2.7 sera encore maintenu pendant 5 ans (a minima). On parle donc d'une transition en 11 ans ! Effectivement il y a des cassures entre Python 2 et Python 3, mais :

• Ce n'est pas courant
• Python 2 date de 2000, donc a supposer qu'il y a un python 4 (ce qui reste relativement peu probable), ce n'est pas pour tout de suite, la transition n'etant pas encore finie (et le but de python 3 est de ne pas avoir a faire un python 4).

Autant je suis d'accord que le passage 2 -> 3 est un peu chiant, autant je trouve ça dommage de leur reprocher vu le temps qu'ils prennent pour faire la migration et les précautions qu'ils prennent pour aider les dev (Python 2.7 est une version sortie uniquement pour aider la migration).

edit: Pour ruby, manifestement la 1.9, hors versions majeurs donc, a obligé la majorité des libs à être re-codé. Ce n'est donc pas un prob specifique à Python.

Salut, Juste pour en remettre une couche :

• Gaah : Tu préfère les délimiteurs à l'indentation, mais c'est totalement une question de gout. Si tu avait l'habitude d'indenté systématiquement ton code comme je le fait tu ne verrais pas un problème dans la syntaxe python et tu trouverais même les délimiteurs superflu. D'ailleurs c'est pour ça que je n'ai jamais essayer Ruby.

• Dinosaure : Pourquoi la programation fonctionnelle en python est-elle un hérésie ? ( Si on pouvait évité les affirmation radicale sans explication… )

Pour moi l'avantage de python est que sa syntaxe claire et relativement conventionnelle (comme ça à était dit plutôt) permet de prendre de bonnes habitudes de programmation (notamment l'indentation) et permet aussi de passer facilement à un autre langage. Moi j'ai commencé par python il y a quelques années et maintenant je connais aussi C/C++, JS, OCaml, Boo (un python like pour .NET), Perl et le TI-Basic, celui qui ma donné le plus de difficulté étant Perl avec le typage faible. Python permet aussi de faire des algos facilement transposable dans un autre langage, il est donc très pratique pour faire des prototypes. Le code python est d'ailleur (en générale) plus facile à lire que la plupart des langage pour un programmeur habitué à d'autre langages. Apparement ce n'est pas le cas de ruby puisque je n'ai compris l'exemple de l'utilisation de la méthode time du type int que par le commentaire. Bien sur aucun de ses argument ne sous entend que ce n'est pas le cas de Ruby puisque je ne connais pas grand chose à ce langage.

Le prob du fonctionnel en python est que l'interpréteur et le langage ne sont pas fait pour ça. Le plus évident est qu'il n'y a aucune optimisation des instructions récursives terminales ce qui entraîne facilement une saturation de la pile.

Oui je comprend ce que tu veut dire. Je posais la question à cause de ça. En fait python essaie de permettre tous les paradigme mais évidement il perd en qualité dans certain. D'ailleurs j'aimerais bien savoir ce que certain reproche à la POO avec python. Pour le coup il me semble que l'hérésie c'est d’affirmer que python n'est pas fait pour la POO .

Tiens Kje je lisais un de tes posts plus haut et

ce n'est pas courant

à propos des cassures Python 2.x $\rightarrow$ 3.x. Soit on parle pas de la même chose, soit tu diminues légèrement le fait qu'un nombre écrasant de libs 2.x sont incompatibles avec 3.x (et 2to3 ne suffit pas à absorber ça).

Perso, chaque fois que j'ai eu des besoins un peu spécifiques (faire de la spatialisation sonore poussée, du TTS), j'ai dû me coltiner du Python 2.x… Et il faut reconnaître que ça devient rapidement gonflant (y'a pas longtemps, pour un projet que je tiens à coder en 3.x, je me suis amusé à traduire entièrement une lib pour laquelle 2to3 n'avait pas pu grand-chose. Ben c'était très drôle) !

Indentation automatique, jusqu'à un certains point… Il faut savoir que l'indentation donne un sens, et qu'il n'est pas censé savoir (l'interpréteur) si tu veux mettre ton print dans la condition if ou en dehors. Un interpréteur n'est pas censé lire dans tes pensées.

C'est justement là le gros problème de python selon moi. Dans les langages où les blocs sont délimités par des accolades, des begin/end ou toute autre marque tangible, il ne peut jamais y avoir de problème d'interprétation.

De mon point de vue, un langage n'a pas à t'imposer une certaine mise en forme. LE langage n'est qu'un ensemble de syntaxes qui permettent d'exprimer des concepts. Certains concepts ne sont pas exprimables ou certains sont plus faciles à exprimer dans un langage qu'un autre, mais la mise en forme, ça doit être le choix de l'écrivain = l'artiste = le programmeur, pas l'académie française = les specs.

Après on a des conventions qu'il est courant de s'imposer pour s'y retrouver, l'indentation en fait partie tout comme le camelCase vs. underscore_mode, mais ça ne doit jamais être une stricte obligation.

Voilà, c'était mes 2€.

Pour prendre le contrepied de mon aversion pour python, j'avais testé ruby il y a 2 ou 3 ans et effectivement, c'est un langage avant-gardiste qui aborde les concepts habituels un peu différemment. A mon avis, ça peut autant être un avantage et un inconvénient. Avantage parce que ça peut effectivement paraître hype ou cool de ne pas faire comme tout le monde et que certains recherchent ça, mais inconvénient parce que c'est peut-être plus difficile après de passer à un langage plus classique comme python, java, C#, etc. le jour où on en a besoin. Après, c'est difficile de trancher sur la question vaut-il mieux être classique ou hype, c'est très personnel.

LE langage n'est qu'un ensemble de syntaxes qui permettent d'exprimer des concepts.

Je t'invite à écrire un compilateur pour un langage quelconque pour te rendre compte de l'inexactitude de cette déclaration.

Un langage de programmation, c'est au minimum :

• un vocabulaire,
• une syntaxe,
• un modèle de données (comprenant le système de types),
• un modèle d'évaluation.

Sans ça, le langage ne sert à rien. Que Python délimite ses blocs lexicaux par les indentations, ça fait partie de sa grammaire (donc c'est une considération purement syntaxique). Et un langage a parfaitement le droit de te l'imposer. Tu aimes ou non, c'est ton choix, mais ça s'arrête là.

Ce qu'il ne t'impose pas en revanche (il se contente de l'encourager), c'est la taille et la forme de tes indentations.

PS : j'ajoute qu'un bon langage est également censé te faire gagner du temps en restreignant ta pensée pour te faire acquérir des idiomatismes et des automatismes. En ceci, ça ne me choque pas que le langage attire ton attention sur l'indentation des blocs. Une fois que tu as fini de râler et de crier au viol de ta liberté de présenter ton code n'importe comment, ça n'a pas plus d'incidence sur ta façon de coder que d'adopter le K&R en C. I.e. ton code est lisible dès le départ et tu n'y fais même plus attention à la longue : ça devient une seconde respiration.

à propos des cassures Python 2.x → 3.x. Soit on parle pas de la même chose, soit tu diminues légèrement le fait qu'un nombre écrasant de libs 2.x sont incompatibles avec 3.x (et 2to3 ne suffit pas à absorber ça).

En effet le passage 2 -> 3 a perdu un certain nombre de libs. Après j'ai tout de même l'impression que les problèmes de ce genre reste relativement minime. Perso ça fait bien un an que je ne suis pas tombé sur une lib bloqué en 2. En règle général les bibliothèques qui ne sont pas encore passé à Python 3 sont des bibliotèques qui sont abandonnées et donc du coup de toute façon je ne les aurais pas sélectionné pour un projet un minimum sérieux à cause de cela.

Pour autant, je ne dit pas que la cassure a été facile a passer et que tout est derrière nous. Je trouve cela juste un peu exagéré de reprocher cette cassure a Python alors que justement tout a été fait pour que la transition soit douce. Ça fait 5 ans que la première version de Python3 est sortie, il reste encore 5 ans de support de Python 2, la transition est ultra douce. Suffit de rester sur le 2 pendant encore 5 ans si vraiment tu es bloqué par une lib. J'y suis encore en grande partie au boulot même si on va migrer dans l'année je pense.

Je suis d'accord avec Kje sur ce point. À l'heure actuelle où se pose la question de porter une grosse partie de la codebase que je maintiens au boulot de Perl vers Python, j'ai eu l'agréable surprise de constater que le plus gros du portage de l'écosystème Python 2 vers Python 3 était derrière nous : je n'ai trouvé aucun point de frottement qui nous imposerait de ne pas choisir Python 3 dès le départ. Qu'il s'agisse de connecteurs à des BDD diverses, de bibliothèques orientées système, ou même, le point le plus important (rédhibitoire dans mon cas précis), de Cython, qui est aujourd'hui assez mature pour interfacer aussi bien C que C++ avec Python 3.

C'était pas le cas l'année dernière.

C'est exactement ça qui est critiqué. Aucun outil ne pourra jamais ré-indenter du python – lancez un gg=G sous vim (puisqu'il a été cité) et observez, et comparez avec les autres langages. Ils peuvent nous assister pour indenter au fur et à mesure un bout de code qui est en cours de saisie (comme avec n'importe quel langage), mais pas pour prendre un code depuis une ressource tierce (forum, SO, refactoring), le copier-coller et espérer que la ré-indentation (mise au bon niveau) soit automatisable.
L'indentation sémantique est très bien pédagogiquement parlant : cela force les élèves à s'appliquer. Mais côté industrie, je trouve ça aberrant, justement à cause de ça. (Je viens de lire une critique comme quoi le mélange espace et tabulations pouvait causer des bugs. C'est vrai ou c'est une intox ? Cela me parait un peu gros comme problème pour être vrai)

Côté langage, Python me donne l'impression d'avoir été bâti comme le C++ : "Tiens, et si on rajoutait ça?". Il y a plein de features et paradigmes. C'est cool. On a un truc très puissant au final, mais il n'en ressort pas une impression d'homogénéité. Ruby au contraire semble avoir été pensé pour être ce qu'il est dès le début. Est-ce le cas ? Je n'en sais rien, mais l'impression d'homogénéité est là. (et vos critiques au sujet de l'adaptation du Python au fonctionnel et/ou à l'OO ne font que me confirmer cela)

Côté communauté. Indubitablement, ruby a perdu la partie. Autour de moi, tout le monde à touché à du python et peu ont vu un seule ligne de ruby. Ror a créé un engouement pour ruby en son temps, mais là… Je n'ai pas l'impression que cela crée trop d'émules. Je doute que des choses comme octopress changent la donne.

Côté âge. Ils sont de la même génération.

Côté Possibilité. Tout pareil.

Côté comptabilité ascendante. David a cité les problèmes de passage de python 2 à 3 avec toutes les libs qui n'ont pas suivi alors que le langage a été remis à plat. Et les choses s'améliorent vous nous dites. Côté ruby, les problèmes sont là. Et j'ai l'impression que c'est à chaque version qu'il y a des soucis. Pour l'industrialisation, c'est limite pire que les problèmes induits par les indentations sémantiques.

L'interpréteur ruby a longtemps été buggué dans le passé. C'est réglé depuis (enfin j'espère).