bistouille

Ayant du temps à perdre, j'ai tenté de me familiariser un petit peu avec ruby, langage que je ne connaissais que de nom, je me suis amusé à retranscrire une petite application que j'avais effectuée avec tkinter et python, un Space Invaders très, très basique. J'ai pour ce faire gardé la même arborescence de l'application. Venant de python, je relate les différents points que j'ai aimés et beaucoup moins appréciés par comparaisons.

Étant habitué en python que les espaces de noms soient implicitement créés lors des imports de modules, en ruby le require est l'équivalent de l'import * d'un module python, il est donc obligatoire d'user de modules afin de générer des espaces de noms et éviter les conflits d'identifiants, et je me demande si ce n'est pas un gros point noir de ruby et qui fait qu'il est relativement peu usité.

Ce qui est marrant en ruby est que finalement l'usage des boucles for et while ont l'air d'être relativement peu usitées, je n'en ai utilisé aucune dans ce script, les blocks les remplacent avantageusement, et ça j'aime bien.

Ne pas mettre de parenthèses pour les appels de fonctions, on aime, on n'aime pas (le concepteur du langage a-t-il une phobie des parenthèses ?), mais à vrai dire cela ne rend pas le code très compréhensible si on ne les met pas (ce que j'ai fait), de plus cela oblige à utiliser les procs si l'on souhaite garder une référence d'une fonction, bref l'avantage d'avoir pensé cela ainsi n'a pour moi aucun avantage, je n'aime donc pas.

Je n'ai pas compris pourquoi la modification de la valeur des constantes ne jette pas une erreur au lieu d'un warning, ce qui aurait été plus logique.

On peut dire ce qu'on veut de python, mais la gestion des erreurs est bien plus stricte qu'en ruby, par exemple l'accès à un élément inexistant via un indice d'une liste en python jette une erreur, alors qu'en ruby cela retourne nil, je ne trouve pas cela génial et peut vite devenir des sources de problèmes, même si je sais qu'au lieu d'utiliser les indices, on peut utiliser des méthodes afin d'obtenir une gestion plus rigoureuse des erreurs, ce qui en devient encore plus dommageable, pourquoi, par exemple, la méthode [] d'Array n'est donc pas un fetch au lieu d'un index ? Étrange…

Deux classes distinctes pour les booléens, je veux bien, excepté que si l'on a besoin de vérifier qu'un type reçu est de type bool, bah cela oblige à définir son propre type bool, utiliser une condition ou encore définir un array contenant true et false et de regarder si notre valeur est dedans, du moins je n'ai pas trouvé d'autre moyen pour le faire. Je préfère largement des booléens définis comme entiers.

L'objet en ruby est un peu plus élaboré qu'en python, pas besoin de définir la référence de l'objet en arguments des méthodes et d'utiliser cette référence au sein de la classe, gestion plus stricte de la visibilité des attributs et méthodes (même si comme en python, il y a toujours possibilité d'y avoir accès), le super d'une méthode fait un appel implicite vers la méthode parente. Variables de classes plus strictes, donc un gros point positif de ruby.

Ce script (qui n'est sans doute pas ce qu'on fait de mieux, n'étant de toute façon qu'un amateur) en ruby est plus lent qu'en python, cela se voit en jeu avec les légers soubresauts des animations, je ne saurai dire si cela vient de ruby lui-même ou de l'implémentation de tk dans ruby (ou peut-être de mon script, mais j'en doute), mais même en occupation mémoire entre python et ruby cela passe du simple au … plus du quintuple (13Mo~ vs 86Mo~, ouais je sais 86Mo c'est que dalle).
Et punaise quel bazar dans le module tk de ruby, aucun commentaire de code, difficile de s'y retrouver dedans, et je n'apprécie guère les indentations de codes à seulement 2 espaces, c'trop la misère à lire, mais je ne crache pas dans la soupe, au moins l'implémentation existe.

Finalement, ruby et python ont beaucoup de similitudes, je ne sais pas si j'approfondirai ultérieurement mes connaissances en ruby afin d'utiliser des concepts plus avancés…

Pour ceux qui voudraient jeter un œil à mes scripts, c'est là. Je vous préviens de suite, les .py et .rb se situent dans les mêmes répertoires, mais cela n'empêche pas de lancer le script avec ruby ou python3.