Perl / Python / Ruby

Bonjour tout est dans le titre:D

Aujourd'hui il y a 3 grands "langages de script", j'aimerais savoir ce que vous pensez de ces langages, lequel est votre préféré, pour quelles raisons, ses avantages par rapport au autres, inconvénients etc.

Merci !

Perso : Python.
Raison : Je ne connais pas les autres.
Pourquoi : Car python est tellement populaire qu'il devient difficile de passer à côté (et c'est tant mieux). Notamment si je devais citer un passage de ce que le fantôme vient d'écrire :

Au final j'ai commencé à plus approfondir Python que Ruby car je préférai la philosophie, l'apparence des codes sources et j'avais besoin de libs que Ruby ne possédait pas, aujourd'hui j'y reste car il est très rare que je n'ai pas ce qu'il me faut en Python pour coder ce dont j'ai besoin rapidement. Et c'est de plus en plus vrai.

Je vais en Python directement (dernière version, pas la 2.7).

Pourquoi ? Parce que j'aime la syntaxe (plus claire que Ruby, et BEAUCOUP plus compréhensible que Perl), parce que ça marche, parce que quand tu veux faire quelque chose tu as sûrement un module qui fait ça dans la bibliothèque standard, parce que les frameworks web sont simples et compréhensibles en Python.

J'ai testé Ruby, leur syntaxe à base de blocs fermés par des end me donne la migraine. Et le langage ne me paraît pas vraiment clair (et rails est une machine à gaz).

D'accord merci pour vos réponses, je suis surtout intéressé par la sécu donc j'imagine que le python est le plus approprié même si ruby est pas mal utilisé aussi.

Il y a beaucoup de différences entre python 2.7 et 3.x ?

Tu entend quoi par sécu ?

Il y a beaucoup de différences entre python 2.7 et 3.x ?

Oui et non mais en 2016 la question ne se pose pas, si tu dois commencer, commence par Python 3.

Bah j'avais déjà commencé à apprendre python en fait, j'ai appris avec la v 2.7, après j'ai pas été très loin non plus, je connais les bases quoi, j'ai été jusqu'aux dico.

Par sécu je veux dire sécurité informatique en général.

Je ne connais pas Perl donc je ne vais pas pouvoir en parler longuement, mais il est vrai que j'ai trouvé imbitables la majorité des codes Perl que j'ai rencontrés.

J'utilise Ruby quotidiennement, et je connais assez bien Python. Les langages se ressemblent sur de nombreux points, mais plusieurs différences font que j'ai une nette préférence pour Python, et que je classe Ruby dans les langages à déconseiller :

• Trop d'éléments de syntaxe différents pour la même chose, qui mènent à une trop grande variété de codes ;
• Ou au contraire, des éléments de syntaxe identiques pour des choses bien différentes (tables de hashage et blocs) ;
• Les fonctions qui ne sont pas des objets de première classe, et toutes les complications qui viennent avec lorsqu'on veut passer des fonctions/méthodes en paramètres ;
• Les symboles, qui découlent d'une mauvaise optimisation des chaînes de caractères, et qui donnent deux types à sémantique très proche (+ compliquent les étapes de sérialization) ;
• Les scopes et fermetures, différents pour les blocs et les fonctions, et l'inaccessibilité aux variables du scope parent ;
• La réouverture de classe, sujette à de nombreux bugs ;
• L'absence d'espaces de nom automatiques, tous les modules qui polluent l'espace de nom de courant, qui modifient toutes les classes standards ar monkey-patching ;
• La gestion des encodages, qui autorise le stockage d'une chaîne invalide, mais échoue lors de certaines opérations ("\xff".gsub('', '')) ;
• nil ; Toutes les fonctions qui préfèrent retourner nil plutôt que de lever une erreur ;
• La bibliothèque standard et ses absurdités (module time et gestion des fuseaux horaires, module uri et échappement des caractères, etc.) ;
• Sans oublier la communauté, très orientée Rails, qui fait que n'importe quel sujet sur le net présuppose qu'un développeur Ruby utilise forcément Rails (ce qui est un problème en raison du monkey-patching évoqué plus tôt, la classe String de base n'a plus rien à voir avec celle modifiée par Rails).

On a la chance sur Zeste de Savoir d'avoir une communauté Python assez importante et de plus en plus en active, donc tu as déjà pas mal de réponses concernant Python. En réalité, les 3 langages ont leur avantages et leur inconvénients. Le meilleur moyen de savoir quel est celui qui te convient le mieux ? Essaye-les, et forge toi un avis.

Il m'arrive personnellement s'utiliser ces trois langages. Je me permets donc de donner mon avis, qui n'est peut-être pas très objectif.

Pour commencer, Ruby. Ruby, c'est vraiment cool pour le web. Avec Ruby on Rails, on peut faire énormément de choses, sans parler de la communauté très active et des nombreuses ressources autour du framework.

(et rails est une machine à gaz).

Heureusement, il n'y a pas que Rails avec Ruby. Si tu trouves que Rails est trop lourd, tu peux utiliser un framework plus léger comme Sinatra, par exemple.
J'ai uniquement utilisé Ruby pour du web, et j'en suis très satisfait. Pour les autres usages, je ne pourrais t'en dire plus.

Concernant Python, tu as avec les posts précédents une longue énumération de ses avantages. Python pour le web, c'est aussi très bien. Tu as de nombreux frameworks, dont le « concurrent » de Ruby on Rails, Django. C'est un excellent framework. La preuve ? Zeste de Savoir utilise Django. Comme pour Ruby, tu as aussi des frameworks plus légers comme Flask, Bottle, CherryPy, etc…

Python, c'est aussi très bien - et peut-être ce qui se fait de mieux - pour un usage scientifique : calculs, traitement d'images, etc… Tu as de nombreux modules qui sont très intéressants à explorer comme numpy, matplotlib, ou encore OpenCV.

Et puis Python, ce n'est pas uniquement ça. Avec Python, tu peut à peu près tout faire : web, petits scripts, programmation système (d'ailleurs, je crois que nohar avait commencé un tutoriel à ce sujet), etc…

La communauté Python est importante, même la francophone. Quant on débute, c'est sûrement un avantage.

Enfin, Perl. Tout d'abord, il faut bien distinguer les deux Perl : l'« ancien Perl », et le « nouveau Perl ». Pour moi, l'ancien perl, c'est toutes les versions inférieures à Perl 6, qui lui est le nouveau Perl. Perl 6 corrige pas mal de choses, et apporte de nombreux concepts intéressants qui valent vraiment le détour. Je conseille à toute personne curieuse d'y jeter un œil !

globalement je trouve les codes Perl illisible

Forcément, quand on ne connaît pas le langage, ça peut faire peur. Beaucoup critiquent les codes Perl. Dans l'imaginaire collectif, un code Perl, c'est moche. Ce n'est peut-être pas aussi esthétique qu'un code Python, mais on a l'avantage de savoir tout de suite à ce que l'on à faire. Par exemple, on sait en un simple coup d’œil quel type de données on manipule. Aujourd'hui, avec l'habitude, je préfère lire un code Perl qu'un code Python.

Perl 6 a tardé à sortir

C'est vrai que Perl 6 a tardé, mais il est enfin là !

la communauté est loin d'etre aussi active et moderne que les deux autres.

C'est vrai. Toutefois, tu trouveras toujours un noyau assez important de passionnées, et des ressources de plus en nombreuses pour Perl 6. Pour Perl 5, c'est un peu différent, les ressources sont souvent vieillissantes.

Puisque Perl propose de faire de la POO, parlons-en : le seul langage dans lequel la POO est encore plus laborieuse, je crois que c'est Javascript. Une classe en Perl est en fait un package, dont tu déclares une méthode new, dans laquelle tu utilises une fonction spéciale bless pour caster explicitement une référence sur une table de hashage en autre chose… Et bien évidemment il n'y a pas de sucre syntaxique pour ça.

Tu as raison : faire de la POO avec Perl, c'est assez pénible. Heureusement, Perl 6 a corrigé ça.

En bref : Perl 6, le langage en lui même, est vraiment intéressant. Là ou Python et Ruby (et même l'ancien Perl) sont encore au dessus, c'est au niveau de la taille de la communauté, de l’écosystème (documentation, modules). Mais ça s'améliore progressivement.

Emporté par mon discours sur Ruby, j'en ai oublié Python. Je ne vais pas répéter ses nombreuses qualités déjà énoncées pour la plupart dans ce sujet, mais je vais plus m'attarder sur ses défauts.

• L'impossibilité de créer des types réellement immutables autrement qu'en héritant de tuple ;
• L'horreur de la classe namedtuple ;
• La syntaxe d'utilisation des décorateurs qui n'est pas une expression, mais quelque chose de plus limité (Il est possible de faire @foo(...) mais pas @foo(...)(...)) ;
• L'optimisation des opérateurs au niveau des classes, et donc l'impossibilité de surcharger facilement tous les opérateurs possibles (il faut nécessairement faire une fonction pour chaque opérateur) ;
• Les différence entre __getattr__ et __getattribute__ ;
• L'absence d'interpréteur/compilateur réellement performant à ce jour.

La syntaxe d'utilisation des décorateurs qui n'est pas une expression, mais quelque chose de plus limité (Il est possible de faire @foo(…) mais pas @foo(…)(…)) ;

amha, c'est une force. Je trouve le décorateur tellement plus simple et intuitif à appliquer et prévoir que les annotations des autres langages. Par contre à coder, le décorateur c'est juste horrible.

Ce que j'aime dans python c'est qu'une partie non négligeable des patterns communs ont leur raccourcis syntaxique et ça c'est géant.

L'optimisation des opérateurs au niveau des classes, et donc l'impossibilité de surcharger facilement tous les opérateurs possibles (il faut nécessairement faire une fonction pour chaque opérateur) ;

Ça dépend, par exemple pour les container il y a des collections.abc qui peut grandement simplifier l'implémentation.

• La portée des variables super mal foutue (cc nonlocal) (pour Ruby et Perl c'est peut-être débile aussi, je sais pas)
• Le typage dynamique (granted, c'est pas Ruby et Perl qui vont rattraper ça)

Par contre à coder, le décorateur c'est juste horrible.

Bof, une fois qu'on a compris qu'une fonction était une valeur comme une autre ça va. Ça fait probablement partie des raisons pour lesquelles les gens qui prétendent qu'apprendre la programmation fonctionnelle aide aussi à programmer dans des langages qui mettent en avant un autre style n'ont pas forcément tort. Cela dit, c'est vrai que si lambda était un peu plus utilisable, ça rendrait sans doute les choses plus agréables.

Il y a des fois où j'aurais eu besoin d'utiliser une fonction stockée dans un dictionnaire comme décorateur, c'est comme ça que j'avais relevé ce comportement.

Oui, mais je pensais plus au fait de créer un proxy complet autour d'un objet, comme c'était le cas avec les old-style classes en Python 2.

Tu peux expliciter ce que tu trouves mal foutu ? Sachant que ce genre de mots-clefs n'est utile que lorsque tu souhaites réassigner une variable d'un scope parent.

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19
20
21

>>> def f():
...     a = "lol"
...     def g():
...             print(a)
...     g()
...
>>> f()
lol
>>> def f():
...     a = "lol"
...     def g():
...             print(a)
...             a = "blbl"
...     g()
...
>>> f()
Traceback (most recent call last):
  File "<stdin>", line 1, in <module>
  File "<stdin>", line 6, in f
  File "<stdin>", line 4, in g
UnboundLocalError: local variable 'a' referenced before assignment

Dans un langage avec une portée correcte, ce genre de comportement ne devrait pas arriver : la liaison du a dans le print ne devrait certainement pas dépendre de code situé après. nonlocal a été rajouté en 3.0 (si je ne dis pas de bêtise) entre autres pour pouvoir écrire la deuxième fonction sans hack sale, mais ce problème ne devrait déjà pas se poser (et ça fait hack sale malgré tout). Pouvoir casser un code correct qui fonctionne parfaitement en rajoutant une affectation de variable plus tard, c'est quand même gênant.

le seul langage dans lequel la POO est encore plus laborieuse, je crois que c'est Javascript.

Troll spotted

De mon coté je ne parlerais que de Ruby car je ne connais pas assez les deux autres

Ruby est un langage très beau a lire, j'oserais même dire artistique. Il y a de nombreux alias juste pour qu'une ligne de code ressemble à une phrase anglaise (surtout RSpec qui fait ca si bien _)

Malheuresement, de nombreux alias demande de plus ou moins connaitre les principaux.

Une autre particularité sypatique, c'est la norme ruby est d'utiliser ? pour dire que l'on renvoie un bool. ainsi on peux avoir

1
2
3
4

# GOOD
foo.nil?
# BAD
foo.is_nil

Ruby est aussi un des langages des plus maléable, l'un des plus pratique pour la métaprogrammation. Un code ruby bien pensé peux coder lui même des fonctions à partir d'un fichier de configuration.

J'ai une superbe phrase pour ce langage

On peux apprendre à utiliser ruby en moins d'une heure, mais il faut des années pour le maîtrisé.

D'ailleurs un nouveau langage vient lui faire de l'ombre: Crystal qui est un langage syntaxiquement très proche avec la même philosophie, cependant il est compilé, il est extrêmement rapide (des résultats proches du C)

D'accord merci pour vos réponses, je vais continuer mon apprentissage pour le python et passer au ruby ensuite pour comparer et voir celui qui me plait le plus !

Ce à quoi me fait penser les topics où l'on demande des avis sur un langage.

Pas taper.

nonlocal a été rajouté en 3.0 (si je ne dis pas de bêtise) entre autres pour pouvoir écrire la deuxième fonction sans hack sale, mais ce problème ne devrait déjà pas se poser (et ça fait hack sale malgré tout). Pouvoir casser un code correct qui fonctionne parfaitement en rajoutant une affectation de variable plus tard, c'est quand même gênant.

Je ne suis pas vraiment d'accord.

tl;dr: Cela vient du fait qu'en Python la portée d'un symbole doit être unique dans un code object, elle ne peut pas varier dans le temps.

La portée des symboles d'un code object ne doit jamais être ambiguë. Dans ton second exemple, ça l'est, parce qu'il y a une chance sur 2 que ce code ne fasse pas ce que tu veux.

• Soit tu veux que a soit une variable libre (celle qui vient de l'environnement de f), auquel cas ta seconde ligne doit vouloir dire "je mets mon a à jour après l'avoir affiché", ce qui n'est pas le cas puisque l'opérateur d'affectation, sans indication explicite supplémentaire, crée systématiquement un lien dans le scope local, c'est sa définition.

• Soit tu veux que a soit une variable locale à l'environnement de g et tu cherches à l'afficher avant qu'elle existe auquel cas c'est une erreur qui doit péter à la compilation.

Le compilateur ne peut pas deviner ton intention, et d'ailleurs il ne le fera jamais (in the face of ambiguity, refuse the temptation to guess). Si tu veux modifier le binding d'une variable libre dans le code object, il faut le dire explicitement parce que l'opérateur = ne veut pas le deviner. D'où le mot-clé nonlocal qui résoud le problème en respectant le zen de Python : explicit is better than implicit.