cependant, on ne m'otera pas l'idée que ça reste moins lisible que du python ...
Il y a plein de raccourcis avec des hieroglyphes (@,,ドル|,&,!,?,<=> ...) qui apportent de superbes fonctionnalitées (j'adore le concept du bang!)
Mais qui rendent alors la lecture bien complexe pour un programmeur ne connaissant pas le perl/ruby/bash/smalltalk (qui sont des langages bien connu comme étant bien bruités) (comprendre : sans avoir la moindre idée de ce que fait ces hiéroglyphes, il n'est pas possible de comprendre le code (pour les dev c/c++/java/c#/basic/pascal)
C'est dommage qu'on ne puisse t'oter l'idée que Ruby est moins lisible que Python :). Prennons les 'hiéroglyphes' cités un par un :
@ : Ça désigne juste une variable d'instance, ce n'est pas pire que de mettre des self devant. Par contre ça devient un peu moche quand on accède au variable de classe @@ (ça me fait penser au __ de Python :)
$ : c'est une variable globale, il me semble, mais j'en met jamais dans mes programmes et c'est très limité dans les codes des librairies
| : Ah? ça n'existe pas le | dans Python, on ne peut pas faire d'opération sur les bits ? c'est un opérateurs utilisés dans la plupart des langages
& : pareil que pour |
? et ! : ne sont pas obligatoire, ça rajoute juste du sens, comme les __ dans Python à part que le '?' et '!' veulent déjà signifier qqchose dans le langage commun ce qui facilite leurs compréhensions
<=> On aurait pu mettre 'cmp' à la place, mais comme Ruby a pris le partie de surcharger les opérateurs arithmétique (+, -, *, % ...) je trouve ça plutôt cohérent.
Et encore tu as oublié de citer que les variables en majuscule sont considérée comme constante. En gros, en Ruby au lieu de juste donner des conventions de codage (majuscule pour les constantes, ajouter un '!' pour les "bang', un '?' pour les méthodes de type booléene) il prend en compte la syntaxe pour ajouter du sens (je parle bien de sémantique) au code.
Effectivement avant de lire du Ruby il faut connaître c'est quelques spécificités, mais c'est comme dans tous les langages.
Pour rappel tous ces 'hiéroglyphes' n'existent pas dans Perl/SmallTalk/Java et consort où n'ont pas du tout la même signification (genre en Perl $ désigne une variable scalaire, @ un tableau et % un hachage). Donc ça n'aide pas vraiment de connaître ces langages avant de faire du Ruby (au contraire). Ce que je ne comprends pas c'est qu'on puisse trouver que c'est un problème pour la lisibilité ! Le nombre de signes (3 importants : @, @@ et $) dont on doit apprendre la négligeable et la plupart du temps se comprend juste en lisant du code.
Je vais me répéter mais l'introduction des '!' et '?' facilitent grandement la compréhension d'un code. Après je comprend que les développeurs de Python refuse de les incorporer, ça les obligeraient à modifier toutes les libs existantes pour rendre tout le code cohérent ! Ça n'est pas envisageable comme pour le plupart des langages, ils sont obligés de garder le bagage des versions précédentes pour garder une compatibilité. Et c'est bien ce que je reproche à Python (ou Java), il essaye d'ajouter de nouvelles fonctionnalités dans un langage qui n'a pas était prévu pour dès le début. Du coup pour ne pas casser brutalement la compatibilité, on ajoute par petite touche les nouveautés en trouvant des astuces pour rester cohérent avec la syntaxe de départ (voir l'exemple du super en Python).
Pour le rapprochement avec Perl, je dirais que ça n'a rien à voir, le problème de Perl est de permettre d'écrire la même chose de 36000 façons différentes en utilisant des astuces abracabrantesques (surtout les variables magiques) qui rendent le code illisible pour qqun ne connaissant pas bien le langage. En Ruby on n'a pas ce problème, je me répéte, la seule chose qu'a garder Ruby par rapport à Perl c'est l'intégration des regexp dans la syntaxe du langage (=~) et les noms des variables globales (0ドル représente le nom de ton programme en cours d'exécution par exemple), rien de plus. Alors bien sûr pour savoir ce que représente les variables $* il faut mieux connaître Bash/Perl ou alors prendre une doc expliquant ces variables :).
[^] # Re: Différence avec Python ?
Posté par pifou . En réponse à la dépêche Sortie de Ruby 1.8.2. Évalué à 2.
cependant, on ne m'otera pas l'idée que ça reste moins lisible que du python ...
Il y a plein de raccourcis avec des hieroglyphes (@,,ドル|,&,!,?,<=> ...) qui apportent de superbes fonctionnalitées (j'adore le concept du bang!)
Mais qui rendent alors la lecture bien complexe pour un programmeur ne connaissant pas le perl/ruby/bash/smalltalk (qui sont des langages bien connu comme étant bien bruités) (comprendre : sans avoir la moindre idée de ce que fait ces hiéroglyphes, il n'est pas possible de comprendre le code (pour les dev c/c++/java/c#/basic/pascal)
C'est dommage qu'on ne puisse t'oter l'idée que Ruby est moins lisible que Python :). Prennons les 'hiéroglyphes' cités un par un :
@ : Ça désigne juste une variable d'instance, ce n'est pas pire que de mettre des self devant. Par contre ça devient un peu moche quand on accède au variable de classe @@ (ça me fait penser au __ de Python :)
$ : c'est une variable globale, il me semble, mais j'en met jamais dans mes programmes et c'est très limité dans les codes des librairies
| : Ah? ça n'existe pas le | dans Python, on ne peut pas faire d'opération sur les bits ? c'est un opérateurs utilisés dans la plupart des langages
& : pareil que pour |
? et ! : ne sont pas obligatoire, ça rajoute juste du sens, comme les __ dans Python à part que le '?' et '!' veulent déjà signifier qqchose dans le langage commun ce qui facilite leurs compréhensions
<=> On aurait pu mettre 'cmp' à la place, mais comme Ruby a pris le partie de surcharger les opérateurs arithmétique (+, -, *, % ...) je trouve ça plutôt cohérent.
Et encore tu as oublié de citer que les variables en majuscule sont considérée comme constante. En gros, en Ruby au lieu de juste donner des conventions de codage (majuscule pour les constantes, ajouter un '!' pour les "bang', un '?' pour les méthodes de type booléene) il prend en compte la syntaxe pour ajouter du sens (je parle bien de sémantique) au code.
Effectivement avant de lire du Ruby il faut connaître c'est quelques spécificités, mais c'est comme dans tous les langages.
Pour rappel tous ces 'hiéroglyphes' n'existent pas dans Perl/SmallTalk/Java et consort où n'ont pas du tout la même signification (genre en Perl $ désigne une variable scalaire, @ un tableau et % un hachage). Donc ça n'aide pas vraiment de connaître ces langages avant de faire du Ruby (au contraire). Ce que je ne comprends pas c'est qu'on puisse trouver que c'est un problème pour la lisibilité ! Le nombre de signes (3 importants : @, @@ et $) dont on doit apprendre la négligeable et la plupart du temps se comprend juste en lisant du code.
Je vais me répéter mais l'introduction des '!' et '?' facilitent grandement la compréhension d'un code. Après je comprend que les développeurs de Python refuse de les incorporer, ça les obligeraient à modifier toutes les libs existantes pour rendre tout le code cohérent ! Ça n'est pas envisageable comme pour le plupart des langages, ils sont obligés de garder le bagage des versions précédentes pour garder une compatibilité. Et c'est bien ce que je reproche à Python (ou Java), il essaye d'ajouter de nouvelles fonctionnalités dans un langage qui n'a pas était prévu pour dès le début. Du coup pour ne pas casser brutalement la compatibilité, on ajoute par petite touche les nouveautés en trouvant des astuces pour rester cohérent avec la syntaxe de départ (voir l'exemple du super en Python).
Pour le rapprochement avec Perl, je dirais que ça n'a rien à voir, le problème de Perl est de permettre d'écrire la même chose de 36000 façons différentes en utilisant des astuces abracabrantesques (surtout les variables magiques) qui rendent le code illisible pour qqun ne connaissant pas bien le langage. En Ruby on n'a pas ce problème, je me répéte, la seule chose qu'a garder Ruby par rapport à Perl c'est l'intégration des regexp dans la syntaxe du langage (=~) et les noms des variables globales (0ドル représente le nom de ton programme en cours d'exécution par exemple), rien de plus. Alors bien sûr pour savoir ce que représente les variables $* il faut mieux connaître Bash/Perl ou alors prendre une doc expliquant ces variables :).