Ruby: The Bad Parts [fermé]

J'ai récemment lu le livre de Crockford "Javascript: The Good Parts" et l'un des principes sous-jacents était que les langages de programmation peuvent avoir de mauvais ensembles de fonctionnalités que les programmeurs devraient éviter.

Je suis un Rubyist et bien que j'aime la langue, il est toujours utile d'avoir du recul. Alors, quelle est selon vous la pire caractéristique (par exemple les méthodes, les classes, les pratiques) de Ruby? Mon intention ici n'est pas de commencer une discussion sur les mérites de la langue elle-même ou sa vitesse et ainsi de suite. Je préfère plutôt une discussion sur les fonctionnalités que vous considérez dangereuses / gênantes / douloureuses à utiliser, en fonction des expériences passées.

Vous devriez regarder Python vs Ruby: A Battle to The Death de Gary Bernhardt. Il fait la citation:

Ce que je trouve moche dans Ruby, c'est ce qui rend possible un logiciel Ruby incroyable comme RSpec, et que Python n'aurait jamais pu (compte tenu de l'implémentation actuelle).

Bien qu'il parle beaucoup de Python en particulier, il touche à beaucoup de choses qui sont juste étranges dans Ruby. L'un des grands sujets primordiaux est le patching de singe .

Les objets Ruby (contrairement aux objets de certains autres langages orientés objet) peuvent être modifiés individuellement. Vous pouvez toujours ajouter des méthodes par objet. Dans Ruby, le comportement ou les capacités d'un objet peuvent différer de ceux fournis par sa classe.

Bien que cela offre beaucoup de flexibilité et alimente certains des joyaux les plus populaires et compliqués de Ruby, cela peut vous mordre dans le cul si vous essayez de déboguer un problème sans vous rendre compte qu'une bibliothèque quelque part a modifié une méthode principale.

Certaines personnes ne pensent au rubis qu'en termes de rubis sur rails et c'est un peu ennuyeux parce que la langue se débrouille assez bien.

Je pense que la pire caractéristique est celle open classesqui vous permet de changer globalement le comportement de toutes les instances actuelles et futures de la classe modifiée.

La partie problématique de cette fonctionnalité est que ces changements (globaux) se produisent pendant l'exécution lorsque l'interpréteur Ruby rencontre la définition, ce qui peut être longtemps après que vous ayez déjà instancié quelques objets qui changent maintenant tout à coup leur comportement.

Dans une grande base de code, cela peut entraîner des bogues très, très difficiles à trouver - d'autant plus que cela est aggravé par l'histoire de débogage faible de Ruby (par exemple par rapport au CLR ou à la JVM) et l'utilisation d'autres fonctionnalités (par exemple eval) dans ce contexte peut rendre il est assez difficile de trouver l'emplacement où ce changement global s'est produit. c'est-à-dire si vous avez déjà atteint le point où vous soupçonnez que la «bonne» classe cause le problème! D'après mon expérience, vous commencez généralement par une chasse aux oies sauvages, car les problèmes commencent à faire surface sur un objet en utilisant le vrai coupable.

Donc, la meilleure chose serait de cesser d'utiliser des classes ouvertes ( #extendet de mettre les changements dans un Moduleest à mon humble avis beaucoup plus sûr, plus facile à comprendre et à tester) ou si cela ne peut être évité pour:

• étendre uniquement les classes avec un nouveau comportement (c'est-à-dire ne pas remplacer le comportement existant)
• avoir une place définie dans l'arborescence du code source, où toutes les extensions utilisant des classes ouvertes doivent être placées
• ne pas utiliser #evalet amis pour créer des classes ouvertes
• mettre toutes les utilisations des classes ouvertes sur un grand tableau visible, où tous les développeurs peuvent les voir - et préciser que toutes les modifications apportées sont des `` décisions architecturales '' affectant l'ensemble de la base de code (ce qu'elles font) et non le lieu de hacks rapides utiles pour votre tâche actuelle

La plus grande raison pour laquelle je n'utilise pas de rubis: c'est plus lent que la mélasse en janvier au pôle Nord pendant une période glaciaire. L'analyse comparative des langages est une science inexacte, mais Ruby apparaît considérablement plus lent que même JavaScript et Python.

Si cela peut être étendu à Ruby on Rails, alors:

1. Le fait que la logique de la base de données donne à chaque table une auto_incrementclé primaire, y compris les tables qui n'en ont pas besoin et ne devraient pas en avoir.

2. Le fait que les clés composées ne sont pas du tout prises en charge.

Pour Ruby, mon reproche serait le même que pour toute langue qui troque la sécurité contre l'expressivité; il est facile de faire beaucoup avec juste un peu de code, mais il est tout aussi facile de faire un énorme gâchis avec n'importe quelle quantité de code.

Ruby embrasse la métaprogrammation (réflexion, introspection), la programmation multi-paradigmes et le dynamisme à un niveau inhabituel. Il est facile de se tirer une balle dans le pied avec puissance et flexibilité.

Gênant? Ruby a la capacité d'être extrêmement lisible ou insondable. J'ai vu du code qui semble appartenir à un script Bash.

Mauvaises pratiques? Certains rubis valorisent l'intelligence à la sagesse. Ils écrivent et partagent des astuces qui montrent leur intelligence, mais cela crée un code illisible et fragile.

En passant: Javascript a été un désastre de par sa conception, et le livre "The Good Parts" essaie d'extraire sa beauté cachée. Perl, un langage qui a popularisé "Il y a plus d'une façon de le faire" (c'est-à-dire la flexibilité), a un livre similaire dans "Perl, Best Practices". L'histoire de Perl est celle de l'expérimentation et de l'expérience durement gagnée, "Best Practices" représente son savoir. Perl 6 sera, je pense qu'il est juste de dire, un redémarrage du langage basé sur cette connaissance et plus encore. Ruby peut souffrir de problèmes similaires.

@James et boucles for ... Quand vous faites une boucle for en rubis, il appelle alors ".each". Par conséquent, "for" est du sucre syntaxique pour les personnes plus à l'aise avec les boucles de style C. Mais en tant que Rubyist, vous allez toujours utiliser des itérateurs comme .map, .inject, .each_with_object. Vous n'aurez jamais à écrire une boucle for avec quelque chose comme "i = 0; i> 6; i ++" en rubis, et donc vous finissez par abandonner l'habitude. @andrew ... rubis éloquent n'approuve pas les boucles.

Cela concerne plus les programmeurs que le langage, mais pourquoi les programmeurs Ruby détestent-ils autant les boucles?

Je me rends compte que Ruby a:

someCollection.each do |item|
   ...
end

mais je n'ai jamais vu cela utilisé dans des situations où une boucle for ne ferait pas exactement la même chose.

J'ai demandé plusieurs fois et je n'ai jamais obtenu une bonne réponse à celle-ci.

Si c'est juste une question de style, je suis heureux d'accepter cela, mais j'ai vu des programmeurs Ruby vraiment travailler à ce sujet et je suis vraiment curieux.

J'évitais généralement les choses qui ont été ajoutées juste pour être rétrocompatibles avec d'autres langues. Par exemple, Perlismes et for x in y.