tag - ¿Por qué Ruby tiene Rails mientras que Python no tiene un marco central?
parser html python (11)
Esta es una (n) pregunta histórica, no una pregunta de comparación entre idiomas:
Este artículo de 2005 habla de la falta de un marco central único para Python. Para Ruby, este marco es claramente Rails. ¿Por qué, históricamente hablando, sucedió esto para Ruby pero no para Python? (¿O sucedió, y ese marco es Django?)
Además, las preguntas hipotéticas: ¿Python sería más popular si tuviera un solo y buen marco? ¿Sería Ruby menos popular si no tuviera un marco central?
[Por favor, evite discusiones sobre si Ruby o Python son mejores, lo cual es demasiado abierto para responder.]
Editar: Aunque pensé que esto era obvio, no estoy diciendo que otros frameworks no existan para Ruby, sino que el más grande en términos de popularidad es Rails. Además, debo mencionar que no estoy diciendo que los frameworks para Python no sean tan buenos (o mejores que) Rails. Cada marco tiene sus pros y sus contras, pero parece que Rails, como dice Ben Blank en uno de los comentarios a continuación, ha superado a Ruby en términos de popularidad. No hay ejemplos de eso en el lado de Python. ¿POR QUÉ? Esa es la pregunta.
¿El rubí sería menos popular sin Rails? absolutamente.
¿Sería Python más popular con un verdadero marco? ¿Quieres decir a diferencia de varios? Tal vez quién sabe. En cualquier caso, la mayoría está de acuerdo en que Django es un muy buen marco.
¿Por qué, históricamente, le sucedió a Ruby? Porque DHH eligió a Ruby después de hacer su propia investigación.
Para agregar a la respuesta sobre Rails haber hecho un gran avance debido a la ''convención sobre la configuración'', también hay otra razón y es que Rails ha estado utilizando magníficamente las capacidades de meta-programación de Ruby. Gran parte de la magia de Rails que ha contribuido a eliminar gran parte del dolor del desarrollo de aplicaciones web surgió a través de este inteligente uso de la meta-programación Ruby.
Como lo veo, Rails puso a Ruby en el mapa. El hecho simple es que antes de Rails, Ruby era un lenguaje esotérico menor, con muy poca adopción. Ruby debe su éxito a Rails. Como tal, Rails tiene un lugar central en el ecosistema Ruby. Como delgado señala, hay otros marcos web, pero va a ser muy difícil superar a Rails como líder.
Python, por otro lado, tenía una curva de adopción muy diferente. Antes de Rails, Python se usaba mucho más que Ruby, y también tenía varios frameworks web en competencia, cada uno construyendo lentamente sus electores. Django ha hecho un buen trabajo al consolidar el soporte y convertirse en el líder en el mundo del framework web de Python, pero nunca será el One True Framework simplemente por la forma en que se desarrolló la comunidad.
Estoy de acuerdo con Ned. Apuesto que más del 90% de las instalaciones de Ruby no tienen otro propósito que ejecutar Rails. Rails domina a Ruby: no existe una sola aplicación que domine a Python, principalmente porque la comunidad de Python es algo más grande que la comunidad de Ruby.
La respuesta técnica real es que hay tres enfoques principales para el desarrollo web en Python: uno está basado en CGI, donde la aplicación se construye exactamente como una antigua aplicación Perl única para ejecutar a través de CGI o FastCGI, por ejemplo, Trac ; luego está Zope , que es un marco bizarro sobredimensionado con su propio concepto DB, un extraño concepto equivocado de desarrollo de software a través de la web, etc. (pero Plone sigue siendo bastante popular); y luego está Django (y Turbogears , etc.), que está guiado por la misma filosofía de herramientas que Rails (se puede argumentar quién llegó primero o quién lo hizo mejor). Mucha gente probablemente acepte que el enfoque Django / Rails / CakePHP es mejor que los enfoques anteriores, pero como el lenguaje más antiguo, Python tiene muchos más marcos heredados que todavía están tratando de evolucionar y mantenerse relevantes. Estos marcos se mantendrán porque ya hay una participación del desarrollador para ellos. Por ejemplo, en retrospectiva, muchas personas probablemente dirían que Zope (especialmente ZODB) fue un error terrible, pero Zope 3 es mucho mejor que Zope 2, y ya hay compañías enteras construidas alrededor de las tecnologías Zope.
No creo que sea correcto caracterizar a Rails como ''el'' único '''' central ''marco de Ruby.
Otros marcos para Ruby incluyen Merb, Camping y Ramaze.
... que de alguna forma invalida la pregunta.
Python no es un pony de un solo truco. Por lo tanto, no hay un único "marco central" para ello. Mucha gente escuchó hablar por primera vez de Python como "otro buen lenguaje OO" o uno de los muchos usos que se le dio.
Para ser justos, Ruby tampoco es un pony de un solo truco. Es solo que muchas personas consideraban a Rails como la "aplicación asesina" que les permitía ver un lenguaje que antes no era conocido. Sospecho que muchas personas nunca oyeron hablar de Ruby antes de Rails, pero eso de ninguna manera es lo único que Ruby puede hacer.
Rails fue un tanto revolucionario en su enfoque extremo de "convención sobre configuración" que lo diferenció de casi cualquier otra cosa y lo convirtió en la "aplicación asesina" de Ruby, causando que mucha gente notara a Ruby en primer lugar.
Entonces la pregunta es realmente "¿Por qué David Hansson decidió escribir Rails en Ruby en lugar de Python?"
Recuerda que Ruby había existido durante mucho tiempo antes de que se creara Rails. Según Wikipedia, Ruby se creó a mediados de los 90; Rails no apareció hasta 2004. Ruby es simplemente el lenguaje que David Hansson eligió para Rails.
Y sí, diría que Ruby es para Rails como Python para Django .
Tendría que aceptar que Django es básicamente el equivalente de "Rails for Python". ¿Por qué tomó tanto tiempo? La respuesta simple es demasiadas opciones.
En Python, hay muchos sistemas de solicitud / respuesta, reescritores de URL, ORM, lenguajes de plantillas, etc. que pueden crear una pila web en docenas de configuraciones diferentes. De hecho, esto es exactamente lo que Pylons y TurboGears hacen es proporcionar una pila confiable y predecible para construir aplicaciones web MVC.
Lo que Django hizo de manera diferente fue que encapsularon todo. En lugar de ir por la ruta de componentes, construyeron un sistema contiguo. Construyeron su propio ORM, su propio lenguaje de plantilla, su propio sistema de middleware, etc. Su razonamiento era que no existía un sistema unificado como este para Python.
Si siguió las noticias, ha leído que Merb and Rails se fusionarán. Este es un buen movimiento en mi humilde opinión. Creo que es por el objetivo común que tienen los desarrolladores: quieren un marco simple para webdev, que viene con un asignador OR, enrutamiento, lenguaje de plantilla, etc. que se ajusta a la mayoría de las tareas.
Mira este artículo sobre por qué nunca veremos Python-on-Rails . El autor brinda algunas de las razones básicas por las cuales Python nunca tuvo y nunca tendrá un marco central. Podría agregar, yo mismo, que Java tampoco tiene uno, y por las mismas razones.
Según el autor, Rails está estrictamente vinculado a su "implementación", que es Ruby. Rails fue adoptado por muchos desarrolladores y Ruby fue solo parte de eso. Rails funciona perfectamente con Ruby (o Ruby wanna-bes como Groovy), pero lo más importante, como muchas otras respuestas dicen, Rails lideró el camino hacia la adopción de Ruby.
Esta es la razón por la cual Rails-for-Python no funcionará, o al menos lo que las personas se han enfocado con Rails no es correcto. No se trata de la implementación o la calidad del marco, se trata del patrón de adopción. Se trata de poner el marco en primer plano, y la implementación en la parte posterior, incluso si esto no fue intenciones de los desarrolladores de Rails (aunque tal vez son inteligentes y esta era su intención).
Básicamente, no se puede lograr que un grupo de personas amantes del lenguaje se reúnan en torno a un marco único. En el lado de Java, mientras que Spring es muy querido, no es Rails en términos de popularidad en la comunidad de Java. En una comunidad madura, los desarrolladores tienen sus propias ideas sobre qué metáforas funcionan y qué no funcionan en un marco. Esta es la razón por la cual Rails conduce a Ruby y no al revés (generalmente, en su mayoría, no en todos los casos).