Perl / Python / Ruby

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

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 ! :)

Édité par Drakop

+0 -0
Staff

Cette réponse a aidé l'auteur du sujet

C'est très difficile comme question car les 3 permettent a peu pret la meme chose. Tout le reste de ce message est donc un avis hautement personnel.

Le plus simple, Perl, est très puissant pour faire du traitement de chaines de caractères mais globalement je trouve les codes Perl illisible. De plus Perl 6 a tardé à sortir et la communauté est loin d'etre aussi active et moderne que les deux autres.

Pour Python Vs Ruby, c'est plus dur, ils sont fondamentalement proches.

Coté langage, je trouve que la différence ce tient au fait que Python applique beaucoup d'importance à une ligne du "zen of python" qui dit "Il devrait y avoir une - et si possible une seule - façon évidente de faire les choses". Cela génère des choix syntaxique fort. Il y a beaucoup moins de constructions en Python qu'en Ruby (exemple: pas de fonctions anonymes de plus d'une expression). Mais il en résulte que c'est un langage très simple a lire et à comprendre. Il y a en général peu de façon faire un algo, et il y a toujours une façon pythonic de le faire. Ce qui fait que les codes se comprennent très vite et bien quand on le pratique. En ruby par contre il y a souvent plusieurs possibilités de faire une meme chose. Et la possibilité de faire des DSL n'arrange pas les choses. Alors oui ça permet des choses élégantes et puissante mais cela rend du coup difficile de comprendre ce qui se passe derrière car plein de magie.

Du coup, puisqu'on passe fatalement beaucoup de temps à lire du code, plus qu'à en écrire, c'est clairement un avantage pour Python.

Ensuite il y a la communauté et l’écosystème. Les deux sont très bien pourvu donc les différences sont probablement minime. Il y a des domaines ou Python bat largement Ruby (je pense au calcul scientifique par exemple ou la batterie de lib numpy/scipy/etc. n'a pas d'équivalent dans les autres langages de scripts généralistes).

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. Ruby a eu longtemps une longueur d'avance avec Rails mais ce n'est plus le cas aujourd'hui et Python est très bien fournit coté dev web (Django, flask, pyramid, etc.).

Les seuls cas où je n'utilise pas Python est quand j'ai des besoins très spécifiques (genre un algo de calcul qui ne peut pas être exprimé simplement avec numpy) où là je vais passer par Cython ou du C++.

+4 -0

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.

ZdS, le best du Zeste ! Tuto Arduino, blog, etc

+3 -0
Staff

Cette réponse a aidé l'auteur du sujet

Perso, j'ai bossé pendant des années avec Perl (5.x) et Python, la comparaison des deux est facile à faire : Perl perd sur tous les points.

  • Il n'est pas simple : il est facile d'écrire un code qui fait ce que tu veux, mais difficile de savoir ce que tu voulais faire quand tu relis ton code quelques jours plus tard. Alors relire le code des autres…
  • Contrairement à une croyance populaire, Perl n'est PAS "puissant pour faire du traitement de chaînes de caractères".
    • D'abord, sa gestion de l'unicode, comme quasiment tout dans le langage, te demande d'aller farfouiller dans les boyaux des chaînes de caractères pour appliquer un flag un peu ésotérique sans aucune garantie de résultat. En 2016, c'est inacceptable pour un langage de script. Python, lui, différencie nativement les chaînes unicode des chaînes d'octets classiques. Si tu as une erreur d'encodage, ça s'affichera juste moche en Perl, alors que ça lèvera immédiatement une erreur en Python.
    • Perl permet de faire des regexps avec une syntaxe builtin qui va bien… mouais, du coup un code en Perl va avoir naturellement tendance à régler les problèmes à coups de regexps, alors que les regexps ne sont par définition ni lisibles, ni vraiment adaptées pour une bonne moitié des problèmes dans lesquels elles sont utilisées. Python propose exactement le même moteur de regexp que Perl dans sa bibliothèque standard, mais à côté de ça il dispose aussi de puissantes méthodes sur ses chaînes de caractères qui te permettent de te passer des regexps 9 fois sur 10.
  • 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.

Au final, je pourrais continuer encore longtemps la comparaison, mais le résultat sera le même : je ne vois aucun intérêt à Perl, parce qu'il n'y a strictement aucun domaine dans lequel il n'est pas plusieurs années lumières derrière Python.

Quant à Ruby, je ne connais pas vraiment. De ce que j'en ai vu ça a l'air un langage rigolo qui ressemble beaucoup à Python avec quelques éléments un peu funky en plus, mais je n'ai jamais eu l'occasion de bosser un peu sérieusement avec.

Édité par nohar

I was a llama before it was cool

+4 -0

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).

+1 -0
Auteur du sujet

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 ?

+0 -0
Staff

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.

+8 -0
Auteur du sujet

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.

+0 -0

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).

Édité par entwanne

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. :zorro:

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.

+0 -0

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.
Staff

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.

+0 -0
Staff

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.

+0 -0

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.

entwanne

  • 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.

Édité par Eusèbe

+0 -0

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.

artragis

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.

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

Kje

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.

  • La portée des variables super mal foutue (cc nonlocal) (pour Ruby et Perl c'est peut-être débile aussi, je sais pas)

Eusèbe

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.

Édité par entwanne

  • La portée des variables super mal foutue (cc nonlocal) (pour Ruby et Perl c'est peut-être débile aussi, je sais pas)

Eusèbe

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.

entwanne

 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.

Édité par Eusèbe

+0 -0

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

Troll spotted :D

"Il est vraiment regrettable que tous les gens qui savent parfaitement comment diriger un pays soient trop occupés à conduire des taxis et à couper des cheveux"

+2 -2

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)

Édité par Necros211

+1 -0
Staff

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.

Édité par nohar

I was a llama before it was cool

+1 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte