Bonjour , à l'instar de débats que j'ai notamment pu voir sur des sites comme développez.com avec C vs C++ ou encore C++ vs Java , je me décide à lancer ce débat qui revient aussi sous forme de question récurante sur le web en général. Dites nous ce que vous préférez si tant est qu'il y est une préférence , essayez de l'expliquer avec des arguments construits . Peut être utilisez vous les 2 selon les cas.
Pour ma part je code essentiellement en Ruby je ne connais que très peu Python seulement par un tout petit peu de Django via la tuto officiel et de Flask , autrement j'utilise surtout Ruby : j'ai beaucoup utilisé Sinatra , je me forme sur Rails mais pas de réel projet avec et en ce moment je débute sur Rubymotion qui est un framework génial pour compiler du Ruby en code natif Ios/Osx et Android. Les autres technos que j'utilise plus ou moins sont inspirées ou proche de ruby : Elixir et Swift .
J'adore l'expressivité et l'élégance de Ruby , j'adore sa capacité à faire du DSL facilement , je le vois avec les gems pour Rubymotion qui permettent d'atteindre un niveau d'abstraction par rapport à la plateforme cible assez impressionnant . Concernant Rails je le trouve super bien foutu et je préfère son architecture à celle de Django (et même de Symfony où tout est bundle) même si l'Orm et l'interface d'admin de Django sont des points en sa faveur.
Voilà en quelque sorte mon ressenti , je n'ai pas assez exploré Python pour faire des comparaisons langagières même si pour le peu que j'ai vu je trouve certains noms de "methodes" plus lisibles en Ruby .
Pour être un fervent adorateur du Python, mais aussi utilisateur de Ruby, mon avis va clairement en faveur du premier. Je m'explique.
Déjà, au niveau de l'environnement. Chaque fois que je me documente sur une bibliothèque Ruby, c'est la galère. Les projets sont souvent mal documentés (difficile à trouver dans la bonne version, incomplet, etc.), l'installation peu expliquée (les bibliothèques système ne sont pas souvent explicitées dans les dépendances). Ce qui fais que j'en viens à lire le code. Et là c'est pas souvent mieux, il est déjà difficile de trouver où se situe une fonction (j'y reviendrai plus tard), mais en plus chaque développeur semble utiliser son propre dialecte Ruby.
Ainsi, la possibilité de réouvrir les classes. Je ne sais pas qui a eu cette idée diabolique, mais j'aurais préféré que cette personne reste au lit le jour où elle a proposé cette idée. Elle m'a fait perdre de longues minutes de debug.
Les nombreux noms de méthodes pour faire la même chose, avec certains types qui les implémentes, d'autres non.
Les appels sans parenthèses, on finit par ne plus savoir ce que l'on manipule : fonction/méthode, variable/attribut, c'est aussi un bon bordel. Et pour peu que ça mêle des priorités…
Les mixins, et les mots-clefs include et extends, l'un fait des trucs, l'autre en fait d'autres, au final j'en viens à tester souvent les deux pour trouver celui qui me permet d'«hériter» de ce que je veux. Je préfère incontestablement l'héritage multiple.
Les paramètres nommés, qui n'en sont pas vraiment, mais un peu quand même.
Je crois aussi avoir rencontré des choses que j'ai jugé étranges en manipulant des variables de classe, mais je n'ai plus les détails en tête.
La seule chose que j'apprécie dans Ruby, ce sont les blocs, même si j'ai tendance à préférer les énumérateurs externes des autres langages (j'adhère totalement au protocole des itérateurs Python).
Bref, Ruby va totalement à l'encontre de ces règles, donc ça passe mal https://www.python.org/dev/peps/pep-0020/
Intéressant comme avis , Les nombreux noms de méthodes pour faire la même chose, avec certains types qui les implémentes, d'autres non. Justement moi ça me plait dans le sens où ça me permet de refactoriser mon code le grand choix après ça demande à en retenir plus et à gérer les incompatibilités
Mais en relisant, je remarque que j'ai bien descendu Ruby, et pourtant rien contre Python.
L'impossibilité de créer des type immuables. Enfin si, y'a des hacks, en héritant d'un tuple pour y stocker les attributs voulus.
Les erreurs de type "local variable referenced before assigment", et la nécessite du mot-clef nonlocal. (à ce propos, j'ai oublié de dire que j'avais horreur des scopes en Ruby)
Les lambdas dans les listes en intention : [lambda: i for i in range(10)][0]()
L'absence par défaut de récursivité terminale.
pip qui dit parfois que tout va bien alors qu'un paquet n'a pu être installé.
ca marche super bien sous tous mes pc linux (Ubuntu, gnome, fedora ...), mais Windows, la cela se passe pas bien
je parle de la ligne 460 dans le fichier socket : en créant un simplehttpserver, il fait un appel a socket, et plus précisément à gethostbyname, et la c'est la cata. ca plante avec des can't decode partout, tout ca parce qu'il y a except error et pas except OSError as e ou juste except.
y a aussi des bugs dans socketserveur que j'ai re rencontré aujourd'hui meme.
m'enfin ca se corrige, comme on a acces aux sources de python
mais c'est tres tres chiant
le truc de local variable referenced before assignment m'enerve aussi tiens
mais sinon, j'aime bien python
pour ruby, je n'ai pas encore appronfondis le sujet, j'ai juste regardé un peu la syntaxe
Quand on parle de Python en tant que langage, ça me paraît toujours important de savoir si on parle de Python 2 ou Python 3. Pour moi, le fait que la communauté Python ne se tourne pas davantage vers Python 3 est un vrai problème.
Ceci étant, y'a quelques gros "plus" à Python :
Les comprehensions, pas vraiment d'équivalent en Ruby.
L'ensemble de librairies disponibles, moins le problème Python 2 vs 3.
J'ai plus pratiqué Ruby ceci dit, et il y a aussi des features qui manquent à Python :
Les blocks (non, les générateurs en Python, ce n'est pas la même chose)
Ruby n'est pas schizo avec la rétro-compatibilité :-)
Mais Ruby casse ses interfaces entre versions mineures, ce n'est pas beaucoup mieux.
Tu parles de « souffrir » du problème, mais je ne pense pas que le terme soit adapté. La transition se fait en douceur, comme c'était prévu. Le problème se situe peut-être au niveau des distributions qui imposent toujours python2 par défaut en 2015.
× Après avoir cliqué sur "Répondre" vous serez invité à vous connecter pour que votre message soit publié.
× Attention, ce sujet est très ancien. Le déterrer n'est pas forcément approprié. Nous te conseillons de créer un nouveau sujet pour poser ta question.
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique
entwanne — @entwanne — Un zeste de Python — La POO en Python — Notions de Python avancées — Les secrets d'un code pythonique