Je n'allais pas poster ceci comme réponse, mais Xeoncross me l'a demandé, alors c'est parti:
(Sidenote: si quelqu'un pouvait résoudre le problème de démarque dans le petit exemple de code, je l'apprécierais.)
Erik Max Francis a écrit:
"Brandon J. Van Every" a écrit:
Quoi de mieux à propos de Ruby que de Python? Je suis sûr qu'il y a quelque chose. Qu'Est-ce que c'est? Ne serait-il pas beaucoup plus logique de demander cela aux personnes Ruby plutôt qu'aux personnes Python?
Peut ou non, selon ses objectifs - par exemple, si ses objectifs incluent une «étude sociologique» de la communauté Python, alors poser des questions à cette communauté est susceptible de se révéler plus révélateur d'informations à ce sujet que de les placer ailleurs :-). Personnellement, j'ai volontiers profité de l'occasion pour suivre le tutoriel Ruby d'une journée de Dave Thomas au dernier OSCON. Ci-dessous un mince placage de différences de syntaxe, je trouve Ruby et Python incroyablement similaires - si je calculais l'arbre minimal couvrant à peu près n'importe quel ensemble de langues, je suis presque sûr que Python et Ruby seraient les deux premières feuilles à fusionner en un nœud intermédiaire :-).
Bien sûr, je suis fatigué, en Ruby, de taper la "fin" idiote à la fin de chaque bloc (plutôt que de simplement indenter) - mais alors j'arrive à éviter de taper le tout aussi idiot :
dont Python a besoin au
début de chaque bloc, c'est donc presque un lavage :-). D'autres différences de syntaxe telles que @fooversus
self.foo, ou la signification plus élevée de la casse dans Ruby vs Python, sont vraiment à peu près aussi hors de propos pour moi.
D'autres fondent sans aucun doute leur choix de langages de programmation sur de telles questions et génèrent les débats les plus chauds - mais pour moi, ce n'est qu'un exemple d'une des lois de Parkinson en action (le montant du débat sur une question est inversement proportionnel à celui de la question). importance réelle). Une différence de syntaxe que je trouve importante et en faveur de Python - mais d'autres personnes penseront sans doute juste l'inverse - est "comment appeler une fonction qui ne prend aucun paramètre". En Python (comme en C), pour appeler une fonction, vous appliquez toujours l '"opérateur d'appel" - parenthèses de fin juste après l'objet que vous appelez (à l'intérieur de ces parenthèses de fin, allez les arguments que vous passez dans l'appel - si vous ne passez aucun argument, alors les parenthèses sont vides). Cela laisse la simple mention de tout objet, sans opérateur impliqué, comme signifiant juste une référence à l'objet - dans n'importe quel contexte, sans cas particuliers, exceptions, règles ad hoc, etc. En Ruby (comme en Pascal), pour appeler une fonction AVEC des arguments, vous passez les arguments (normalement entre parenthèses, bien que ce ne soit pas toujours le cas) - MAIS si la fonction ne prend pas d'arguments, le simple fait de mentionner la fonction l'appelle implicitement. Cela peut répondre aux attentes de nombreuses personnes (du moins, sans aucun doute, celles dont la seule expérience antérieure de programmation était avec Pascal, ou d'autres langages avec des "appels implicites" similaires, comme Visual Basic) - mais pour moi, cela signifie que la simple mention d'un objet peut SOIT signifier une référence à l'objet, OU un appel à l'objet, en fonction du type d'objet - et dans les cas où je ne peux pas obtenir une référence à l'objet en le mentionnant simplement, je devrai utiliser une explicite "donnez-moi une référence à cela, ne l'appelez pas!" opérateurs qui ne sont pas nécessaires autrement. Je pense que cela a un impact sur la "première classe" des fonctions (ou méthodes, ou autres objets appelables) et la possibilité d'interchanger les objets en douceur. Par conséquent, pour moi, cette différence de syntaxe spécifique est une sérieuse marque noire contre Ruby - mais je comprends pourquoi les autres penseraient autrement, même si je ne peux guère être en désaccord avec plus de véhémence avec eux :-). En dessous de la syntaxe, nous entrons dans quelques différences importantes dans la sémantique élémentaire - par exemple, les chaînes en Ruby sont des objets mutables (comme en C ++), tandis qu'en Python, ils ne sont pas modifiables (comme en Java, ou je crois en C #). Encore une fois, les gens qui jugent principalement en fonction de ce qu'ils connaissent déjà peuvent penser que c'est un avantage pour Ruby (à moins qu'ils ne connaissent Java ou C #, bien sûr :-). Moi, je pense que les chaînes immuables sont une excellente idée (et je ne suis pas surpris que Java, indépendamment je pense, ait réinventé cette idée qui était déjà en Python), même si cela ne me dérangerait pas d'avoir un type de "tampon de chaîne mutable" (et idéalement avec une meilleure facilité d'utilisation que les propres "tampons de chaîne" de Java); et je ne donne pas ce jugement à cause de la familiarité - avant d'étudier Java, en dehors des langages de programmation fonctionnels où les gens qui jugent principalement par ce qu'ils connaissent déjà peuvent penser que c'est un plus pour Ruby (à moins qu'ils ne connaissent Java ou C #, bien sûr :-). Moi, je pense que les chaînes immuables sont une excellente idée (et je ne suis pas surpris que Java, indépendamment je pense, ait réinventé cette idée qui était déjà en Python), même si cela ne me dérangerait pas d'avoir un type de "tampon de chaîne mutable" (et idéalement avec une meilleure facilité d'utilisation que les propres "tampons de chaîne" de Java); et je ne donne pas ce jugement à cause de la familiarité - avant d'étudier Java, en dehors des langages de programmation fonctionnels où les gens qui jugent principalement par ce qu'ils connaissent déjà peuvent penser que c'est un plus pour Ruby (à moins qu'ils ne connaissent Java ou C #, bien sûr :-). Moi, je pense que les chaînes immuables sont une excellente idée (et je ne suis pas surpris que Java, indépendamment je pense, ait réinventé cette idée qui était déjà en Python), même si cela ne me dérangerait pas d'avoir un type de "tampon de chaîne mutable" (et idéalement avec une meilleure facilité d'utilisation que les propres "tampons de chaîne" de Java); et je ne donne pas ce jugement à cause de la familiarité - avant d'étudier Java, en dehors des langages de programmation fonctionnels où Je pense que les chaînes immuables sont une excellente idée (et je ne suis pas surpris que Java, indépendamment je pense, ait réinventé cette idée qui était déjà en Python), même si cela ne me dérangerait pas d'avoir un type de "tampon de chaîne mutable" (et idéalement un avec une meilleure facilité d'utilisation que les propres "tampons de chaîne" de Java); et je ne donne pas ce jugement à cause de la familiarité - avant d'étudier Java, en dehors des langages de programmation fonctionnels où Je pense que les chaînes immuables sont une excellente idée (et je ne suis pas surpris que Java, indépendamment je pense, ait réinventé cette idée qui était déjà en Python), même si cela ne me dérangerait pas d'avoir un type de "tampon de chaîne mutable" (et idéalement un avec une meilleure facilité d'utilisation que les propres "tampons de chaîne" de Java); et je ne donne pas ce jugement à cause de la familiarité - avant d'étudier Java, en dehors des langages de programmation fonctionnels oùtoutes les données sont immuables, tous les langages que je connaissais avaient des chaînes mutables - pourtant quand j'ai vu pour la première fois l'idée de chaîne immuable en Java (que j'ai apprise bien avant d'apprendre Python), cela m'a tout de suite semblé excellente, un très bon ajustement pour la sémantique de référence d'un langage de programmation de niveau supérieur (par opposition à la sémantique de valeur qui correspond le mieux aux langages plus proches de la machine et plus éloignés des applications, telles que C) avec des chaînes en tant que première classe, intégrées (et jolies crucial) type de données.
Ruby présente certains avantages en sémantique élémentaire - par exemple, la suppression de la distinction "listes vs tuples" de Python extrêmement subtile. Mais la plupart du temps (comme je le garde, avec simplicité un grand plus et des distinctions intelligentes subtiles un inconvénient notable) est contre Ruby (par exemple, ayant des intervalles fermés et semi-ouverts, avec les notations a..b et a .. .b [quelqu'un veut prétendre qu'il est évident qui est lequel? -)], est idiot - à mon humble avis , bien sûr!). Encore une fois, les gens qui envisagent d'avoir beaucoup de choses similaires mais subtilement différentes au cœur d'une langue, un PLUS, plutôt qu'un MOINS, les compteront bien sûr "à l'inverse" de la façon dont je les compte :-).
Ne vous laissez pas induire en erreur par ces comparaisons en pensant que les deux langues sont
trèsdifférent, attention. Ils ne le sont pas. Mais si on me demande de comparer "capelli d'angelo" à "spaghettini", après avoir souligné que ces deux sortes de pâtes sont à peu près indiscernables pour tout le monde et interchangeables dans n'importe quel plat que vous pourriez vouloir préparer, j'aurais alors inévitablement pour passer à l'examen microscopique de la façon dont les longueurs et les diamètres diffèrent imperceptiblement, comment les extrémités des brins sont effilées dans un cas et non dans l'autre, et ainsi de suite - pour essayer d'expliquer pourquoi je préférerais personnellement avoir capelli d 'angelo comme pâtes dans tout type de bouillon, mais préféreraient les spaghettinis comme pastasciutta pour accompagner des sauces adaptées à de telles formes de pâtes longues et minces (huile d'olive, ail haché, poivrons rouges hachés et anchois finement moulus, par exemple - mais si vous coupez l'ail et les poivrons au lieu de les hacher, alors vous devriez choisir le corps plus sain des spaghettis plutôt que l'évanescence plus mince des spaghettinis, et il serait bien avisé de renoncer à l'achoview et d'ajouter à la place du basilic de printemps frais [ ou même - je suis hérétique ...! - feuilles de menthe claire [...] - au tout dernier moment avant de servir le plat). Oups, désolé, cela montre que je voyage à l'étranger et que je n'ai pas eu de pâtes depuis un certain temps, je suppose. Mais l'analogie est encore assez bonne! -) et il serait bien avisé de renoncer à l'achoview et d'ajouter à la place du basilic de printemps frais [ou même - je suis un hérétique ...! - feuilles de menthe claire [...] - au tout dernier moment avant de servir le plat). Oups, désolé, cela montre que je voyage à l'étranger et que je n'ai pas eu de pâtes depuis un certain temps, je suppose. Mais l'analogie est encore assez bonne! -) et il serait bien avisé de renoncer à l'achoview et d'ajouter à la place du basilic de printemps frais [ou même - je suis un hérétique ...! - feuilles de menthe claire [...] - au tout dernier moment avant de servir le plat). Oups, désolé, cela montre que je voyage à l'étranger et que je n'ai pas eu de pâtes depuis un certain temps, je suppose. Mais l'analogie est encore assez bonne! -)
Donc, revenons à Python et Ruby, nous arrivons aux deux gros trucs (en termes de langage proprement dit - laissant les bibliothèques et d'autres accessoires importants tels que les outils et les environnements, comment incorporer / étendre chaque langue, etc., etc., hors de pour l'instant - ils ne s'appliqueraient pas à toutes les MISES EN ŒUVRE de chaque langue, par exemple, Jython vs Classic Python étant deux implémentations du langage Python!):
Les itérateurs et blocs de code de Ruby par rapport aux itérateurs et générateurs de Python;
Ruby TOTAL, la "dynamicité" débridée, y compris la possibilité de "rouvrir" n'importe quelle classe existante, y compris toutes les classes intégrées, et de changer son comportement au moment de l'exécution - par rapport à la
dynamicité vaste mais limitée de Python, qui ne change jamais le comportement des classes existantes classes intégrées et leurs instances.
Personnellement, je considère 1 comme un lavage (les différences sont si profondes que je pouvais facilement voir des gens détester l'une ou l'autre et vénérer l'autre, mais sur MES échelles personnelles, les avantages et les inconvénients sont à peu près égaux); et [2] une question cruciale - qui rend Ruby beaucoup plus approprié pour le "bricolage", MAIS Python est également plus approprié pour une utilisation dans des applications de grande production. C'est drôle, d'une certaine manière, parce que les deux langues sont tellement beaucoup plus dynamiques que la plupart des autres, qu'à la fin la différence clé entre elles et mon POV devrait reposer sur cela - que Ruby "va à onze" à cet égard (la référence voici "Spinal Tap", bien sûr). En Ruby,JE PEUX FAIRE CELA ! C'est-à-dire que je peux modifier dynamiquement la classe de chaîne intégrée afin que
a = "Bonjour tout le monde"
b = "bonjour le monde"
si a == b
imprimer "égal! \ n"
autre
imprimer "différent! \ n"
fin
IMPRIMERA "égal". En python, je ne peux PAS faire ça. Aux fins de la métaprogrammation, de la mise en œuvre de cadres expérimentaux, etc., cette incroyable capacité dynamique de Ruby est extrêmement
attirant. MAIS - si nous parlons de grandes applications, développées par de nombreuses personnes et maintenues par encore plus, y compris toutes sortes de bibliothèques de sources diverses, et devant être mises en production dans les sites clients ... eh bien, je ne VEUX PAS une langue assez dynamique, merci beaucoup. Je déteste l'idée même d'une bibliothèque qui casse involontairement d'autres bibliothèques non liées qui reposent sur la différence de ces chaînes - c'est le genre de "canal" profond et profondément caché, entre des morceaux de code qui semblent séparés et DEVRAIENT être séparés, qui annonce la mort dans programmation à grande échelle. En laissant n'importe quel module affecter le comportement de tout autre "secrètement",
Si je devais utiliser Ruby pour une application aussi grande, j'essaierais de me fier à des restrictions de style de codage, à de nombreux tests (à réexécuter chaque fois que TOUT CHANGE - même ce qui devrait être totalement indépendant ...), etc. pour interdire l'utilisation de cette fonction de langue. Mais ne pas avoir la fonctionnalité en premier lieu est encore mieux, à mon avis - tout comme Python lui-même serait un langage encore meilleur pour la programmation d'applications si un certain nombre de modules intégrés pouvaient être "cloués", donc je savais que , par exemple,
len("ciao")est 4 (plutôt que d'avoir à se soucier de manière subliminale de savoir si quelqu'un a changé la liaison de nom lendans le __builtins__
module ...). J'espère que finalement Python "clouera" ses fonctions intégrées.
Mais le problème est mineur, car la reliure des éléments intégrés est assez obsolète ainsi qu'une pratique rare en Python. Dans Ruby, cela me semble majeur - tout comme les fonctionnalités
macro trop puissantes d'autres langues (comme, par exemple, Dylan) présentent des risques similaires à mon avis (j'espère que Python n'obtiendra jamais un système macro aussi puissant, non importe l'attrait de «laisser les gens définir leurs propres langages spécifiques au domaine incorporés dans le langage lui-même» - cela, à mon humble avis, nuirait à la merveilleuse utilité de Python pour la programmation d'applications, en présentant une «nuisance attrayante» pour le bricoleur potentiel qui se cache dans le cœur de chaque programmeur ...).
Alex