Discussion :

[Franck.H]

Je cherche pour plus tard surtout, un langage de script pour faire différentes choses, de la manipulation de fichiers rapide et surtout ponctuel aussi bien que de jeux 2D quels qu'ils soient.

Je connais un peu Python (étudié en vitesse un week-end) pour entrevoir un peu le langage mais je vois que Ruby m'a l'air pas mal du tout également et dispose en interne d'une bibliothèque pour gérer la 2D ce qui en fait un sacré plus.

Je me pose donc la question, techniquement et du point de vue de la vitesse d'exécution ou du moins de la limite à un point donné d'un gros projet, lequel sera le plus performant ?

Bien entendu, je demande un point de vue objectif (qui se base éventuellement sur des faits ou sur l'expérience) et non pas de préférence. Je veux juste voir un peu autre chose mais dans la catégorie des langages de scripts.

A savoir, même si tous deux existent sur un peu tous les OS, je suis exclusivement sur Windows (bientôt 8)

[Franck.H]

Je viens de lire cet article http://www.dallagnese.fr/fr/computer...crete-example/... Est ce que c'est toujours d'actualité cette différence entre les deux langages même si ça date de deux ans environ ?

• lenteur d'exécution d'une interface Qt pour Ruby
• déploiement plus abouti pour Python (py2exe)

C'est vrai que la syntaxe Ruby est plus jolie et plus lisible tel était le but lorsque de sa création. La syntaxe Python à côté me semble un peu plus bâclée avec les self un peu partout sans compter les __init__ (par exemple) qui me semble être une choix qui a été fait par manque d'imagination quant aux noms et qui rendent le code un peu plus sale.

[totocaracana]

La syntaxe Python à côté me semble un peu plus bâclée avec les self un peu partout sans compter les __init__ (par exemple) qui me semble être une choix qui a été fait par manque d'imagination quant aux noms et qui rendent le code un peu plus sale.

Je ne suis pas d'accord. Pour les __init__, c'est des methodes "systèmes", si on est "obligé" de prendre ce nom, c'est pour simplifier la vie des développeurs. En effet, si on créé une classe héritée d'une autre classe, on écrit classe.__init__(self). Ce qui serait horriblement plus compliqué si le __init__ n'était pas partout ...

Après, au niveau du self, c'est lourd, oui (beaucoup de mes erreurs viennent de la), mais au moins, c'est clair.


Sinon, il est vrai que je ne m'y connais pas trop en Ruby, mais si j'aime le Python, c'est pour la rapidité A CODER (parce que pour l'execution ...), et la simplicité.

Quelques liens :

• assez objectif, en anglais, points par points
• en anglais, plus complet
• en français, à travers un exemple concret, en Qt

[Franck.H]

Je suis quand même sidéré par le peu d'avis

[fatbob]

Ne connaissant pas Ruby, je suis mal placé pour répondre.
Cela dit, pour ce qui est de python, je trouve ce langage excellent.
La syntaxe me convient parfaitement (à peu près pour les raisons que tu donnes comme des inconvénients), en particulier, le système par indentation à la place des saletés de {} utilisés dans tous les langages pour imiter le C et qui sont vraiment pas pratique sur des claviers azerty. En plus, ça pollue inutilement le code.

La compacité du code fait que c'est quasiment un langage de dialogue avec la machine. Le développement en python est vraiment très rapide (très nettement plus que le php, le C ou java par exemple).
Les types de données (tableaux, listes...) sont extrêmement puissants et pratiques

Pour des jeux en 2D, il existe pyGame.
Pour travailler avec des fichiers textes, je ne crois pas qu'on puisse faire plus rapide (à coder, pas à exécuter)
Et les modules externes sont hyper nombreux (pour faire du web, des webcrawlers, des pdf, travailler avec des bases de données, lire des documents MS Office, open office...)
Et, last but not least, c'est un langage très utilisé comme langage de macro pour des logiciels. Je citerais
vim, open office (à travers pyUno), gimp, blender mais il y en a plein d'autres.

Beaucoup de ces qualités sont partagées avec ruby que je testerais bien mais, autant que je sache, python est sensiblement plus riche en modules externes et, au final, ce point me semble très important vu que je bosse avec des données qui viennent de toutes sortes d'origines et que je dois formater dans toutes sortes de formats...