¿Por qué Ruby es más adecuado para Rails que Python? [cerrado]


90

Python y Ruby generalmente se consideran primos cercanos (aunque con un bagaje histórico bastante diferente) con expresividad y poder similares. Pero algunos han argumentado que el inmenso éxito del framework Rails realmente tiene mucho que ver con el lenguaje en el que está construido: Ruby mismo. Entonces, ¿por qué Ruby sería más adecuado para un marco de este tipo que Python?


44
Aliteración. _
Jimmy

75
"Python on Pails" simplemente no tiene la misma sensación ...
efímero

105
@Ephemient: Creo que sería Python on Planes.
Jimmy

37
@Jimmy: ¿Quién necesita aviones? importar antigravedad ;-) xkcd.com/353
Vinay Sajip

157
¿Existe Java en las cárceles?
Nosredna

Respuestas:


170

Probablemente hay dos diferencias principales:

Ruby tiene cierres elegantes y anónimos.

Rails los usa con buenos resultados. He aquí un ejemplo:

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

Los cierres / lambdas anónimos facilitan la emulación de nuevas funciones de lenguaje que tomarían bloques. En Python, existen cierres, pero deben tener un nombre para poder usarse. Entonces, en lugar de poder usar cierres para emular nuevas funciones de lenguaje, se ve obligado a ser explícito sobre el hecho de que está utilizando un cierre.

Ruby tiene una metaprogramación más limpia y fácil de usar.

Esto se usa mucho en Rails, principalmente por lo fácil que es de usar. Para ser específico, en Ruby, puede ejecutar código arbitrario en el contexto de la clase. Los siguientes fragmentos son equivalentes:

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

En ambos casos, puede hacer:

Bar.new.hello  

que imprimirá "HOLA". losclass_eval método también toma un String, por lo que es posible crear métodos sobre la marcha, a medida que se crea una clase, que tienen una semántica diferente según los parámetros que se pasan.

De hecho, es posible hacer este tipo de metaprogramación en Python (y también en otros lenguajes), pero Ruby tiene una ventaja porque la metaprogramación no es un estilo especial de programación. Se deriva del hecho de que en Ruby todo es un objeto y todas las líneas de código se ejecutan directamente. Como resultado, los Classes en sí mismos son objetos, los cuerpos de clase tienen un selfapuntador a la clase y puede llamar a métodos en la clase mientras crea uno.

Esto es en gran medida responsable del grado de declaratividad posible en Rails y de la facilidad con la que podemos implementar nuevas características declarativas que parecen palabras clave o nuevas características de lenguaje de bloques.


40
En Python, todo son objetos y todas las líneas de código también se ejecutan directamente. ;) Pero, no tienes un "self" apuntando a la clase en el cuerpo de la clase, que no se crea hasta después de la definición de la clase, así que tienes que poner ese código después en Python, que ciertamente es menos elegante , pero funcionalmente equivalente.
Lennart Regebro

31
@lennart ese es el punto. Python le permite hacer el mismo tipo de cosas con lambdas con nombre, decoradores y código de colocación después de que se crean las clases, pero la pérdida de elegancia se suma rápidamente y hace que algo como Rails sea notablemente más difícil de implementar o menos elegante para los usuarios finales.
Yehuda Katz

9
Realmente no me parecen grandes diferencias.
Dietrich Epp

10
@lennart Estoy un poco confundido. Dije que no los necesitabas en Python, pero que no tenerlos hacía que el código fuera más difícil de implementar o menos elegante para los usuarios finales (uno u otro). Los idiomas se están completando; puede escribir Rails en C si lo desea.
Yehuda Katz

5
@lennart Ahora estamos entrando en territorio subjetivo, pero las dos características de las que hablé son bastante convenientes cuando se producen marcos con una combinación de programación declarativa y procedimental. La falta de lambdas anónimas, en particular, es una limitación de expresividad de Python. La falta de coherencia (la necesidad de trabajar con clases creadas solo DESPUÉS de que se crearon las clases) también es bastante limitante.
Yehuda Katz

58

Aquellos que han argumentado que

el inmenso éxito del marco Rails realmente tiene mucho que ver con el lenguaje en el que se basa

están (en mi opinión) equivocados. Ese éxito probablemente se deba más a un marketing inteligente y sostenido que a cualquier destreza técnica. Podría decirse que Django hace un mejor trabajo en muchas áreas (por ejemplo, el administrador de kick-ass incorporado) sin la necesidad de ninguna característica de Ruby. No estoy despreciando a Ruby en absoluto, ¡solo estoy defendiendo a Python!


10
Bueno, estamos entrando en territorio subjetivo aquí. Si cree que el administrador es un "único", quizás sea porque no ha disfrutado de los beneficios de ahorro de tiempo que confiere. ¿Hay áreas en las que crees que Django funciona peor que Rails, debido a las características que tiene Ruby y Python no? El punto realmente no se trata de qué marco es mejor, sino de si (como se señaló en otra parte de esta pregunta) falta algo en Python que lo haga menos capaz de desarrollar un marco increíble. Según la evidencia, no existe tal falta.
Vinay Sajip

18
@Para los votantes en contra: Realmente no me importa, pero tengo curiosidad por saber por qué pensaron que mi respuesta era inútil . No me di cuenta de que alguien votó negativamente porque no estaba de acuerdo con la posición de alguien; por lo general, he votado negativamente solo cuando siento que una pregunta o respuesta de alguna manera empeora las cosas.
Vinay Sajip

5
Puedo escribir mi propia sección de administración, no necesito que esto esté en el marco. Prefiero otras formas de facilitar la redacción de mi solicitud.
nitecoder

8
@railsninja: Bien por ti. Prefiero no tener que escribir páginas repetitivas para las tareas administrativas de limpieza que la mayoría de los sistemas necesitan. Recientemente, hice un trabajo pro bono para un sitio web de caridad local, y no hubiera sido factible hacer ese sitio si el administrador de Django no fuera parte de la ecuación. Tal como estaba, proporcioné un sitio con una interfaz de usuario Ajaxified bastante personalizada para los usuarios finales, pero los administradores de back-end trabajaron con el administrador y fue más que adecuado para sus necesidades.
Vinay Sajip

6
@Matt: Su pregunta es por qué Ruby es MÁS adecuado que Python ... Y la respuesta, muy correctamente, es que no lo es.
Lennart Regebro

54

La comunidad de Python cree que hacer las cosas de la manera más simple y directa posible es la forma más alta de elegancia. La comunidad de ruby ​​cree que hacer las cosas de manera inteligente que permitan un código genial es la forma más alta de elegancia.

Rails se trata de que si sigues ciertas convenciones, te suceden mágicamente muchas otras cosas. Eso encaja muy bien con la forma rubí de ver el mundo, pero en realidad no sigue la forma de Python.


4
Claro, pero hay una pérdida de gente de Perl (bueno, quizás no mucha ) que piensa que las frases crípticas son geniales, y mucha gente Lisp que jura que es el único idioma verdadero. Definitivamente estamos en el territorio de lo que sea que flote su bote.
Vinay Sajip

4
Rails no tiene magia, está ahí en la fuente. Si quieres saber cómo, sal de tu culo y descúbrelo.
nitecoder

21
"Cualquier tecnología suficientemente avanzada es indistinguible de la magia." - Arthur C. Clarke
Vinay Sajip

1
"mágico" significa que el marco hace muchísimas cosas por ti sin que te lo pidan directamente. Una vez más, no estoy haciendo juicios de valor, es un estilo de hacer las cosas que tiene lados buenos y malos. Personalmente, creo que funciona de maravilla en raíles.
Matt Briggs

2
La elegancia y las convenciones no denotan magia.
BJ Clark

26

¿Es este debate un nuevo debate "vim versus emacs"?

Soy un programador de Python / Django y hasta ahora nunca he encontrado un problema en ese lenguaje / marco que me lleve a cambiar a Ruby / Rails.

Puedo imaginar que sería lo mismo si tuviera experiencia con Ruby / Rails.

Ambos tienen una filosofía similar y hacen el trabajo de una manera rápida y elegante. La mejor opción es lo que ya sabes.


25

Personalmente, encuentro que ruby ​​es superior a python en muchos aspectos que comprenden lo que yo llamaría 'expresividad consistente'. Por ejemplo, en ruby, join es un método en el objeto de matriz que genera una cadena, por lo que obtienes algo como esto:

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

En python, join es un método en el objeto de cadena pero que arroja un error si le pasa algo que no sea una cadena como elemento para unir, por lo que la misma construcción es algo como:

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

Hay muchas de estas pequeñas diferencias que se acumulan con el tiempo.

Además, no puedo pensar en una mejor manera de introducir errores lógicos invisibles que hacer que los espacios en blanco sean significativos.


29
Mi experiencia es que hacer que los espacios en blanco sean significativos ayuda a que los errores lógicos desaparezcan. Es mucho más confuso que el espaciado y la sintaxis no estén de acuerdo.
Nosredna

5
En lenguajes con comienzos y finales y en lenguajes con llaves y en ensamblador, he visto código pegado incorrectamente y causar problemas más tarde. Eso es siempre un problema. ¿Ha tenido muchos problemas con personas que pegan Python mal?
Nosredna

5
El espacio en blanco no es significativo en Python: secnetix.de/~olli/Python/block_indentation.hawk . Es casi imposible introducir "errores invisibles" debido a la sangría en Python (tiene que modificar la configuración de su editor) mientras que, por supuesto, es completamente posible introducir errores invisibles debido a la sangría en cualquier otro idioma, simplemente sangrando incorrectamente. @fields: Entonces, no copie el código a través de skype o HTML. Caray.
Lennart Regebro

7
Es correcto que Python se queje si intenta agregar cadenas que no son cadenas, como en un Join. Esto se debe a que explícito es mejor que implícito. Hay muy pocas conversiones automáticas en Python, y la razón es que tienden a generar problemas, especialmente en lenguajes dinámicos, ya que las cosas terminan no siendo del tipo que esperabas. Seguro que el método "" .join () se siente al revés al principio, pero esa es la razón. En realidad, no tiene sentido en la lista ...
Lennart Regebro

8
Dios todopoderoso ... Te refieres a tipado estático, no tipado fuertemente. Python está fuertemente tipado, también Ruby: stackoverflow.com/questions/520228/… Tampoco puede agregar una cadena a un entero en Ruby. Me estoy cansando de corregirle, compruebe sus datos antes de responder en el futuro.
Lennart Regebro

15

La verdadera respuesta es ninguna Python ni Ruby son mejores o peores candidatos para un marco web. Si desea objetividad, debe escribir algún código en ambos y ver cuál se ajusta mejor a sus preferencias personales, incluida la comunidad.

La mayoría de las personas que defienden uno u otro nunca han utilizado el otro idioma en serio o están "votando" por sus preferencias personales.

Supongo que la mayoría de la gente decide con quién entran en contacto primero porque les enseña algo nuevo (MVC, pruebas, generadores, etc.) o hace algo mejor (complementos, plantillas, etc.). Solía ​​desarrollar con PHP y entré en contacto con RubyOnRails. Si hubiera sabido acerca de MVC antes de encontrar Rails, lo más probable es que nunca hubiera dejado atrás PHP. Pero una vez que comencé a usar Ruby, disfruté de la sintaxis, características, etc.

Si hubiera encontrado Python y uno de sus frameworks MVC primero, ¡probablemente estaría alabando ese lenguaje!


11

Python tiene una gran cantidad de marcos similares a Rails. Hay tantos que dice una broma que durante la charla típica en PyCon al menos un framework web verá la luz.

El argumento de que la metaprogramación de Rubys lo haría más adecuado es IMO incorrecto. No necesita metaprogramación para marcos como este.

Así que creo que podemos concluir que Ruby no es mejor (y probablemente ni peor) que Python a este respecto.


8

Porque Rails está desarrollado para aprovechar el conjunto de características de Rubys.

Una pregunta igualmente sin sentido sería "¿Por qué Python es más adecuado para Django que Ruby?".


4

Supongo que no deberíamos discutir las características del lenguaje per se, sino más bien los acentos que las comunidades respectivas hacen en las características del lenguaje. Por ejemplo, en Python, reabrir una clase es perfectamente posible pero no es común; en Ruby, sin embargo, reabrir una clase es algo de la práctica diaria. esto permite una personalización rápida y sencilla del marco según los requisitos actuales y hace que Ruby sea más favorable para los marcos tipo Rails que cualquier otro lenguaje dinámico. De ahí mi respuesta: uso común de clases de reapertura.


1

Algunos han dicho que el tipo de metaprogramación requerido para hacer posible ActiveRecord (un componente clave de los rieles) es más fácil y más natural de hacer en ruby ​​que en python; todavía no conozco Python;), por lo que no puedo confirmar personalmente esta declaración.

He usado rieles brevemente, y su uso de catchalls / interceptores y evaluación dinámica / inyección de código le permite operar a un nivel mucho más alto de abstracción que algunos de los otros marcos (antes de su tiempo). Tengo poca o ninguna experiencia con el marco de Python, pero he escuchado que es igualmente capaz, y que la comunidad de Python hace un gran trabajo apoyando y fomentando los esfuerzos de Python.


3
De hecho, este tipo de "magia" a menudo está mal visto en Python; por ejemplo, code.djangoproject.com/wiki/RemovingTheMagic
ephemient

2
Creo que la "magia" (trucos de metaprogramación) por el bien de la "magia" siempre debe estar mal vista; el código más simple, pero igualmente poderoso y expresivo, siempre debe ganar, pero hay casos en los que la única forma de proporcionar la funcionalidad y la sintaxis exactas quieres requiere "magia" - y en esos casos, la "magia" es indispensable;)
Faisal Vali

1

Creo que la sintaxis es más limpia y Ruby, al menos para mí, es mucho más "agradable", ¡tan subjetivo como es!


-1

Dos respuestas:

a. Porque rails fue escrito para ruby.

si. Por la misma razón, C es más adecuado para Linux que Ruby.


Dado el contexto de la pregunta, la respuesta no tiene ningún sentido.
Lorefnon

-6

Todo esto es TOTALMENTE "IMHO"

En Ruby hay UN marco de aplicación web, por lo que es el único marco que se anuncia para ese lenguaje.

Python ha tenido varios desde el inicio, solo por nombrar algunos: Zope, Twisted, Django, TurboGears (en sí mismo una mezcla de otros componentes del marco), Pylons (una especie de clon del marco Rails), y así sucesivamente. Ninguno de ellos es compatible con Python en toda la comunidad como "EL que se debe usar", por lo que toda la "corriente" se distribuye en varios proyectos.

Rails tiene el tamaño de la comunidad únicamente, o al menos en la gran mayoría, debido a Rails.

Tanto Python como Ruby son perfectamente capaces de hacer el trabajo como marco de aplicaciones web. Utilice el que le guste a USTED (y a su equipo de desarrollo potencial) y en el que pueda alinearse.


7
ruby tiene múltiples marcos de aplicaciones web: Nitro, Merb, Camping ... por nombrar algunos
Corban Brook

5
Agregue: Sinatra e incluso una aplicación Rack básica para aplicaciones web muy rápidas y mínimas también.
Kris

2
-1 "En Ruby hay UN marco de aplicación web" demasiado categórico ... para una declaración falsa. Nitro, Merb, Camping, Sinatra
Maximiliano Guzman

2
Las opiniones desinformadas de ambos lados son exactamente la causa de confusión para los recién llegados que están tratando de resolver todo esto. También significa que uno podría perderse algo que realmente apreciaría si supiera mejor.
Walt Jones

3
Creo que su punto fue que Rails tiene una gran participación en la comunidad Ruby que Django en la comunidad Python, lo cual es válido
pjb3
Al usar nuestro sitio, usted reconoce que ha leído y comprende nuestra Política de Cookies y Política de Privacidad.
Licensed under cc by-sa 3.0 with attribution required.