Pourquoi Ruby est-il plus adapté pour Rails que Python? [fermé]

90

Python et Ruby sont généralement considérés comme des cousins ​​proches (bien qu'avec un bagage historique assez différent) avec une expressivité et une puissance similaires. Mais certains ont fait valoir que l'immense succès du framework Rails a vraiment beaucoup à voir avec le langage sur lequel il est construit: Ruby lui-même. Alors pourquoi Ruby serait-il plus adapté à un tel framework que Python?

Victor Yan
la source
44
Allitération. _
Jimmy
75
"Python on Pails" n'a tout simplement pas la même sensation ...
éphémère
105
@Ephemient: Je crois que ce serait Python on Planes.
Jimmy
37
@Jimmy: Qui a besoin d'avions? import antigravity ;-) xkcd.com/353
Vinay Sajip
157
Y a-t-il un Java dans les prisons?
Nosredna le

Réponses:

170

Il existe probablement deux différences majeures:

Ruby a des fermetures élégantes et anonymes.

Les rails les utilisent à bon escient. Voici un exemple:

class WeblogController < ActionController::Base
  def index
    @posts = Post.find :all
    respond_to do |format|
      format.html
      format.xml { render :xml => @posts.to_xml }
      format.rss { render :action => "feed.rxml" }
    end
  end
end

Les fermetures / lambdas anonymes facilitent l'émulation de nouvelles fonctionnalités de langage qui prendraient des blocs. En Python, les fermetures existent, mais elles doivent être nommées pour être utilisées. Ainsi, au lieu de pouvoir utiliser des fermetures pour émuler de nouvelles fonctionnalités de langage, vous êtes obligé d'être explicite sur le fait que vous utilisez une fermeture.

Ruby a une métaprogrammation plus propre et plus facile à utiliser.

Ceci est largement utilisé dans Rails, principalement en raison de sa facilité d'utilisation. Pour être précis, dans Ruby, vous pouvez exécuter du code arbitraire dans le contexte de la classe. Les extraits de code suivants sont équivalents:

class Foo
  def self.make_hello_method
    class_eval do
      def hello
        puts "HELLO"
      end
    end
  end
end

class Bar < Foo # snippet 1
  make_hello_method
end

class Bar < Foo; end # snippet 2
Bar.make_hello_method

Dans les deux cas, vous pouvez alors faire:

Bar.new.hello  

qui imprimera "HELLO". La class_evalméthode prend également une chaîne, il est donc possible de créer des méthodes à la volée, lors de la création d'une classe, qui ont une sémantique différente en fonction des paramètres transmis.

Il est, en fait, possible de faire ce genre de métaprogrammation en Python (et dans d'autres langages aussi), mais Ruby a une longueur d'avance car la métaprogrammation n'est pas un style de programmation particulier. Cela découle du fait que dans Ruby, tout est un objet et toutes les lignes de code sont directement exécutées. En conséquence, Classes sont eux-mêmes des objets, les corps de classe ont unself pointant sur la classe et vous pouvez appeler des méthodes sur la classe lorsque vous en créez une.

Ceci est en grande partie responsable du degré de déclarativité possible dans Rails et de la facilité avec laquelle nous sommes en mesure d'implémenter de nouvelles fonctionnalités déclaratives qui ressemblent à des mots-clés ou à de nouvelles fonctionnalités de langage de blocs.

Yehuda Katz
la source
40
En Python, tout est objet et toutes les lignes de code sont également exécutées directement. ;) Mais, vous n'avez pas de "self" pointant sur la classe dans le corps de la classe, cela n'est créé qu'après la définition de la classe, vous devez donc mettre ce code ensuite en Python, ce qui est certes moins élégant , mais fonctionnellement équivalent.
Lennart Regebro
31
@lennart c'est un peu le point. Python vous permet de faire le même genre de choses avec les lambdas nommés, les décorateurs et le codage après la création des classes, mais la perte d'élégance s'additionne rapidement et rend quelque chose comme Rails soit sensiblement plus difficile à implémenter, soit nettement moins élégant pour les utilisateurs finaux.
Yehuda Katz
9
Ils ne me semblent pas vraiment des différences majeures.
Dietrich Epp
10
@lennart Je suis un peu confus. J'ai dit que vous n'en aviez pas besoin en Python - mais que ne pas les avoir rendait le code plus difficile à implémenter ou moins élégant pour les utilisateurs finaux (l'un ou l'autre). Les langages sont terminés - vous pouvez écrire des Rails en C si vous le souhaitez.
Yehuda Katz
5
@lennart Nous entrons maintenant en territoire subjectif, mais les deux fonctionnalités dont j'ai parlé sont assez pratiques pour produire des frameworks avec un mélange de programmation déclarative et procédurale. L'absence de lambdas anonymes, en particulier, est une limitation de l'expressivité de Python. Le manque de cohérence (la nécessité de travailler avec des classes créées uniquement APRÈS que les classes aient été créées) est également assez limitatif.
Yehuda Katz
58

Ceux qui ont soutenu que

l'immense succès du framework Rails a vraiment beaucoup à voir avec le langage sur lequel il est construit

(OMI) se trompe. Ce succès doit probablement plus à un marketing intelligent et soutenu qu'à des prouesses techniques. Django fait sans doute un meilleur travail dans de nombreux domaines (par exemple, l'administrateur kick-ass intégré) sans avoir besoin de fonctionnalités de Ruby. Je ne dis pas du tout Ruby, je défends juste Python!

Vinay Sajip
la source
10
Eh bien, nous entrons dans un territoire subjectif ici. Si vous pensez que l'administrateur est un "seul", c'est peut-être parce que vous n'avez pas apprécié les avantages de gain de temps qu'il confère. Selon vous, Django fait-il pire que Rails, à cause des fonctionnalités de Ruby et de Python? Le point n'est pas vraiment de savoir quel framework est le meilleur - c'est de savoir si (comme indiqué ailleurs dans cette question) il manque quelque chose à Python qui le rend moins capable de développer un framework kick-ass. D'après les preuves, il n'y a pas un tel manque.
Vinay Sajip
18
@ Aux votants négatifs: cela ne me dérange pas vraiment, mais je suis curieux de savoir pourquoi vous avez pensé que ma réponse n'était pas utile . Je ne me suis pas rendu compte qu'une personne avait voté contre parce que l'autre n'était pas d'accord avec la position de quelqu'un - je n'ai généralement voté que là où je sentais qu'une question ou une réponse aggraverait d'une manière ou d'une autre les choses.
Vinay Sajip
5
Je peux écrire ma propre section d'administration, je n'ai pas besoin de cela dans le cadre. Je préfère d'autres moyens de rendre ma candidature plus facile à rédiger.
nitecoder
8
@railsninja: Tant mieux pour vous. Je préfère ne pas avoir à écrire des pages standard pour les tâches administratives dont la plupart des systèmes ont besoin. Récemment, j'ai fait du travail bénévole pour un site Web caritatif local, et il n'aurait pas été possible de faire ce site du tout si l'administrateur Django ne faisait pas partie de l'équation. En fait, j'ai fourni un site avec une interface utilisateur Ajaxifiée assez personnalisée pour les utilisateurs finaux, mais les administrateurs back-end ont travaillé avec l'administrateur et c'était plus que suffisant pour leurs besoins.
Vinay Sajip le
6
@Matt: Sa question est de savoir pourquoi Ruby est PLUS approprié que Python .. Et la réponse, à juste titre, est que ce n'est pas le cas.
Lennart Regebro
54

La communauté python pense que faire les choses de la manière la plus simple et la plus directe possible est la plus haute forme d'élégance. La communauté ruby ​​croit que faire les choses de manière intelligente qui permet un code cool est la plus haute forme d'élégance.

Rails est tout au sujet de si vous suivez certaines conventions, beaucoup d'autres choses se produisent comme par magie pour vous. Cela correspond très bien à la manière rubis de regarder le monde, mais ne suit pas vraiment la manière python.

Matt Briggs
la source
4
Bien sûr, mais il y a une perte de personnes Perl (enfin, peut-être pas beaucoup ) qui pensent que les one-liners cryptiques sont cool, et de nombreuses personnes Lisp qui jurent que c'est le seul vrai langage. Nous sommes définitivement sur le territoire de votre bateau.
Vinay Sajip
4
Rails n'a aucune magie, il est juste là dans la source. Si vous voulez savoir comment, lâchez-vous et découvrez.
nitecoder
21
"Toute technologie suffisamment avancée est indiscernable de la magie." - Arthur C. Clarke
Vinay Sajip
1
"magique", c'est-à-dire que le framework fait énormément de choses pour vous sans qu'on vous le demande directement. Encore une fois, je ne porte pas de jugement de valeur, c'est une façon de faire qui a de bons et de mauvais côtés. Personnellement, je pense que cela fonctionne à merveille dans les rails.
Matt Briggs
2
L'élégance et les conventions ne dénotent pas la magie.
BJ Clark
26

Ce débat est-il un nouveau débat «vim contre emacs»?

Je suis un programmeur Python / Django et jusqu'à présent je n'ai jamais trouvé de problème dans ce langage / framework qui me conduirait à passer à Ruby / Rails.

J'imagine que ce serait la même chose si j'avais de l'expérience avec Ruby / Rails.

Les deux ont une philosophie similaire et font le travail de manière rapide et élégante. Le meilleur choix est ce que vous savez déjà.

luc
la source
25

Personnellement, je trouve que le rubis est supérieur au python à bien des égards, ce que j'appellerais une «expressivité cohérente». Par exemple, dans ruby, join est une méthode sur l'objet tableau qui génère une chaîne, vous obtenez donc quelque chose comme ceci:

numlist = [1,2,3,4]
#=> [1, 2, 3, 4]
numlist.join(',')
#=> "1,2,3,4"

En python, join est une méthode sur l'objet string mais qui renvoie une erreur si vous lui passez autre chose qu'une chaîne comme objet à joindre, donc la même construction est quelque chose comme:

numlist = [1,2,3,4]
numlist
#=> [1, 2, 3, 4]
",".join([str(i) for i in numlist])
#=> '1,2,3,4'

Il y a beaucoup de ces petites différences qui s'accumulent avec le temps.

De plus, je ne peux pas penser à une meilleure façon d'introduire des erreurs de logique invisibles que de rendre les espaces blancs significatifs.

des champs
la source
29
Mon expérience est que rendre les espaces blancs significatifs aide à éliminer les erreurs de logique. Il est beaucoup plus déroutant d'avoir un désaccord entre l'espacement et la syntaxe.
Nosredna
5
Dans les langages avec début et fin et dans les langages avec accolades et en assemblage, j'ai vu du code se coller mal et causer des problèmes plus tard. C'est toujours un problème. Avez-vous eu beaucoup de problèmes avec les gens qui collent mal Python?
Nosredna
5
L' espace blanc n'est pas significatif en Python: secnetix.de/~olli/Python/block_indentation.hawk . Il est presque impossible d'introduire des "erreurs invisibles" dues à l'indentation en Python (vous devez truquer les paramètres de votre éditeur) alors que bien sûr il est tout à fait possible d'introduire des erreurs invisibles dues à l'indentation dans n'importe quel autre langage, simplement en indentant incorrectement. @fields: Alors ne copiez pas de code via skype ou HTML, alors. Bon sang.
Lennart Regebro
7
Il est vrai que Python se plaint si vous essayez d'ajouter des non-chaînes à des chaînes, comme dans une jointure. C'est parce que l'explicite est mieux que l'implicite. Il y a très peu de conversions automatiques en Python, et la raison en est qu'elles ont tendance à poser des problèmes, en particulier dans les langages dynamiques, car les choses finissent par ne pas être du type que vous attendiez. Bien sûr, la méthode "" .join () semble inversée au début, mais c'est la raison. Cela n'a pas de sens sur la liste ...
Lennart Regebro
8
Dieu tout-puissant ... Vous voulez dire typé statiquement, pas fortement typé. Python est fortement typé, tout comme Ruby: stackoverflow.com/questions/520228/ ... Vous ne pouvez pas non plus ajouter une chaîne à un entier dans Ruby. J'en ai assez de vous corriger, veuillez vérifier vos faits avant de répondre à l'avenir.
Lennart Regebro
15

La vraie réponse n'est ni Python ni Ruby ne sont de meilleurs / pires candidats pour un framework Web. Si vous voulez de l'objectivité, vous devez écrire du code dans les deux et voir lequel correspond le mieux à vos préférences personnelles, y compris la communauté.

La plupart des gens qui plaident pour l'une ou l'autre n'ont jamais utilisé sérieusement l'autre langue ou «votent» pour leur préférence personnelle.

Je suppose que la plupart des gens choisissent de savoir avec qui ils entrent en contact en premier parce que cela leur apprend quelque chose de nouveau (MVC, tests, générateurs, etc.) ou fait quelque chose de mieux (plugins, modèles, etc.). J'avais l'habitude de développer avec PHP et suis entré en contact avec RubyOnRails. Si j'avais connu MVC avant de trouver Rails, je n'aurais probablement jamais laissé PHP derrière. Mais une fois que j'ai commencé à utiliser Ruby, j'ai apprécié la syntaxe, les fonctionnalités, etc.

Si j'avais trouvé Python et l'un de ses frameworks MVC en premier, je louerais probablement plutôt ce langage!

Kris
la source
11

Python a toute une série de frameworks de type Rails. Il y en a tellement qu'une blague dit que pendant la discussion typique à PyCon, au moins un framework Web verra le jour.

L'argument selon lequel la métaprogrammation Rubys la rendrait mieux adaptée est erroné par l'OMI. Vous n'avez pas besoin de métaprogrammation pour des frameworks comme celui-ci.

Je pense donc que nous pouvons conclure que Ruby n'est pas meilleur (et probablement ni pire) que Python à cet égard.

Lennart Regebro
la source
8

Parce que Rails est développé pour tirer parti de l'ensemble des fonctionnalités de Rubys.

Une question similaire serait "Pourquoi Python est-il plus adapté à Django que Ruby?".

Paddy3118
la source
4

Je suppose que nous ne devrions pas discuter des caractéristiques linguistiques en soi, mais plutôt des accents que les communautés respectives apportent aux caractéristiques linguistiques. Par exemple, en Python, la réouverture d'une classe est parfaitement possible mais ce n'est pas courant; en Ruby, cependant, la réouverture d'une classe fait partie de la pratique quotidienne. cela permet une personnalisation rapide et directe du framework aux exigences actuelles et rend Ruby plus favorable pour les frameworks de type Rails que tout autre langage dynamique. D'où ma réponse: utilisation courante de la réouverture des classes.

Giorgi
la source
1

Certains ont dit que le type de métaprogrammation requis pour rendre ActiveRecord (un composant clé des rails) possible est plus facile et plus naturel à faire en ruby ​​qu'en python - je ne connais pas encore python;), donc je ne peux pas personnellement confirmer cette déclaration.

J'ai brièvement utilisé les rails, et son utilisation de catchalls / interceptors et d'évaluation dynamique / injection de code vous permet d'opérer à un niveau d'abstraction beaucoup plus élevé que certains des autres frameworks (avant l'heure). J'ai peu ou pas d'expérience avec le framework Python - mais j'ai entendu dire qu'il est tout aussi capable - et que la communauté python fait un excellent travail en soutenant et en encourageant les efforts pythoniques.

Faisal Vali
la source
3
En effet, ce genre de «magie» est souvent mal vu en Python; par exemple, code.djangoproject.com/wiki/RemovingTheMagic
éphémient
2
Je pense que la "magie" (astuces de métaprogrammation) au nom de "magie" devrait toujours être désapprouvée - un code plus simple, mais tout aussi puissant et expressif, devrait toujours gagner - mais il y a des cas où la seule façon de fournir la fonctionnalité et la syntaxe exactes que vous voulez nécessite de la "magie" - et dans ces cas, la "magie" est indispendable;)
Faisal Vali
1

Je pense que la syntaxe est plus propre et que Ruby, du moins pour moi, est beaucoup plus «agréable» - aussi subjective que cela soit!

James Schorr
la source
-1

Deux réponses:

une. Parce que les rails ont été écrits pour le rubis.

b. Pour la même raison, C plus adapté à Linux que Ruby

Dhananjay Nene
la source
Compte tenu du contexte de la question, la réponse n'a absolument aucun sens.
lorefnon
-6

Tout cela est TOTALEMENT "IMHO"

Dans Ruby, il existe UN SEUL framework d'application web, c'est donc le seul framework annoncé pour cette langue.

Python en a eu plusieurs depuis sa création, pour n'en nommer que quelques-uns: Zope, Twisted, Django, TurboGears (il est lui-même un mélange d'autres composants du framework), Pylons (un peu clone du framework Rails), etc. Aucun d'entre eux n'est supporté à l'échelle de la communauté python en tant que "THE one to use", donc toute la "vague de fond" est répartie sur plusieurs projets.

Rails a la taille de la communauté uniquement, ou du moins dans la grande majorité, à cause de Rails.

Python et Ruby sont parfaitement capables de faire le travail en tant que cadre d'applications Web. Utilisez celui que VOUS (et votre équipe de développement potentiel) aimez et sur lequel vous pouvez vous aligner.

Ch'marr
la source
7
ruby a plusieurs frameworks d'applications Web: Nitro, Merb, Camping .. pour n'en nommer que quelques
Corban Brook
5
Ajoutez: Sinatra et même une application Rack nue pour des applications Web très rapides et très minimales.
Kris
2
-1 "Dans Ruby il y a UN framework d'application web" trop catégorique ... pour une fausse déclaration. Nitro, Merb, Camping, Sinatra
Maximiliano Guzman
2
Les opinions mal informées des deux côtés sont exactement la cause de la confusion pour les nouveaux arrivants qui essaient de régler tout cela. Cela signifie également que quelqu'un pourrait passer à côté de quelque chose qu'il apprécierait vraiment s'il savait mieux.
Walt Jones le
3
Je pense que son argument était que Rails a une grande part d'esprit de la communauté Ruby que Django a de la communauté Python, ce qui est valide
pjb3