PHP y Ruby: ¿cómo aprovechar ambos? ¿Y vale la pena? [cerrado]

8

Como habrás notado en el título, esta no es una pregunta "PHP o Ruby", o una pregunta "PHP vs. Ruby". Esta es una pregunta sobre cómo aprovechar PHP + Ruby en el mismo negocio.

Yo mismo soy un desarrollador de PHP, amo el lenguaje por su conveniencia y amo especialmente el ecosistema de recursos que lo rodean: Joomla, Drupal, Wordpress, Symfony2, Doctrine2, etc. Sin embargo, el lenguaje en sí puede ser un poco decepcionante a veces. .

OTOH, Ruby parece un lenguaje muy hermoso y, al estudiarlo superficialmente en varios aspectos, podría decir que es más delgado que Python como lenguaje per se. Sin embargo, por lo que he visto, solo hay RoR haciendo ruido, y no me gusta mucho RoR (principalmente porque su capa de modelo).

Como co-CEO y CTO de mi empresa, estoy tratando de pensar fuera de la caja, ya que quiero comenzar a centrarme en el lado humano de la tecnología y ver si es sensato usar PHP y Ruby. Aquí hay algunos pensamientos al azar:

  • Las personas de Ruby parecen ser programadores más adecuados que las personas de PHP (en términos de promedios), sé que la declaración anterior es un tanto descabellada porque se puede escribir PHP muy bueno y bien diseñado, pero diría que la cultura del programador de Ruby es mejor que PHP's.
  • Lo que pasa con Ruby es que parece más adecuado para un desarrollo rápido, realmente no sé si este es solo el caso de RoR, pero sí sé que hay ciertas prácticas (tal vez no tan buenas) como el parcheado de monos que permiten a los negocios necesita ser satisfecho más rápido.
  • Desde el punto de vista del marketing (sí, a veces es necesario aprovechar el BS de marketing por el bien de su empresa) Ruby parece mejor mientras PHP tiene algunos estigmas.
  • PHP 5.4 está trayendo rasgos , y eso es mejor / más limpio que los mixins. Eso realmente podría hacer que PHP sea tan delgado como Ruby, o más, para ciertas cosas.

Ahora, concretamente, mis preguntas:

  • ¿Un programador de PHP querría aprender Ruby ?, sé que sí, pero a la inversa, ¿un programador de Ruby querría aprender PHP?
  • ¿Qué tipo de proyectos o situaciones serían más adecuados para Ruby que no son adecuados para PHP?
  • ¿Cuál es el ecosistema real de Ruby ?, aparte de RoR, no he visto otras tecnologías / frameworks publicitados (he visto RSpec, pero confieso ser un novato total en lo que realmente consiste BDD y sus implicaciones).
  • Suponiendo que hay un cierto tipo de proyectos ideales para Ruby, ¿habría algún momento en el que sea mejor moverlo a PHP? Sé que PHP puede manejar muchas cosas, pero he leído que Ruby tiene sus limitaciones al escalar (¿o es eso RoR ?, ¿o es una tontería para ambos?).
  • Finalmente y lo más importante, ¿sería sensato mantener proyectos en dos idiomas ?, o ¿es simplemente estúpido? Como dije, parece que Ruby es más ágil a corto plazo y eso puede hacer que un proyecto suceda y tenga éxito, pero no estoy tan seguro de eso a largo plazo.

Estoy buscando ideas principalmente de personas que conozcan bien las fortalezas y debilidades de los lenguajes, preferiblemente ambos, y el ecosistema de Ruby en la práctica real, es decir: marcos y aplicaciones como las que cité del ecosistema de PHP.

dukeofgaming
fuente

Respuestas:

7

Tenga en cuenta, mientras lee mis respuestas, que mi experiencia en PHP (> 10 años) es mucho mayor que mi experiencia en Ruby (unas pocas semanas jugando con él; todavía no hay un proyecto en vivo).

¿Un programador PHP querría aprender Ruby?

Personalmente, llegué a Ruby mientras buscaba un lenguaje más limpio para el desarrollo web (especialmente cuando se trata de la conciencia de cadena multibyte) y las secuencias de comandos del lado del servidor (mis secuencias de comandos bash OSX siempre parecen tener una molestia o dos cuando se ejecutan en mi Servidor FreeBSD).

Antes de intentarlo, había estado jugando con Lisp, Perl, Python y Node.js. Eventualmente abandoné a Lisp debido a la falta de un editor adecuado (es emacs o nada, y odio los emacs con venganza), la rareza en la construcción de una aplicación web (hay herramientas, pero no se sienten naturales de usar) y la peculiaridad ocasional (te estoy mirando car, cdry cons). Rápidamente descarté a Perl tan apestoso como PHP cuando se trata de la conciencia de cadena multibyte. No me gustaba mucho Python (es solo una cuestión de sabor; no tengo razones válidas). Y aunque prometedor, acaricio a Node.js como demasiado joven y sobrevalorado. (También consideré a Erlang, pero nunca fui más allá de un tutorial).

Por el contrario, ¿querría un programador Ruby aprender PHP?

(...) Finalmente y lo más importante, ¿sería sensato mantener proyectos en dos idiomas?

Aquí solo puedo hablar por mí mismo, pero cuanto más juego con Ruby, más ganas tengo de vomitar cada vez que leo o escribo código PHP.

¿Qué tipo de proyectos o situaciones serían más adecuados para Ruby que no son adecuados para PHP?

Cualquier cosa que implique el manejo de cadenas UTF-8, por ejemplo, que posiblemente incluye todo lo relacionado con la web. Es como, sí, en PHP están las mb_*funciones; y las Intlclases; y el /umodificador para las preg_*funciones; y ... Como adicto a PostgreSQL, he llegado a tomar el manejo de UTF-8 como un hecho. Es el tipo de cosas por las que no quiero preocuparme, especialmente cuando se trata de bibliotecas, más allá de los problemas específicos de la localidad, como el caso y la recopilación.

(Ruby no es absolutamente perfecto a este respecto, por cierto. Python es un poco mejor . Pero prefiero tener mixins. En 15 años de codificación, rara vez he necesitado clasificar cadenas no ASCII fuera de una base de datos, o manejar el caso más allá de transliterar bits y piezas que lo convierten en un URI).

Las secuencias de comandos de Shell son otra. PHP también se puede usar para este tipo de cosas, pero las inconsistencias y el desorden del lenguaje lo hacen mucho menos agradable.

¿Cuál es el ecosistema real de Ruby ?, aparte de RoR, no he visto otras tecnologías / frameworks publicitados (he visto RSpec, pero confieso ser un novato total en lo que realmente consiste BDD y sus implicaciones).

En realidad, hay varios otros frameworks además de Rails: Merb, Camping, Ramaze, Sinatra, etc. Es solo que RoR recibió mucha publicidad desde el principio.

He leído que Ruby tiene sus limitaciones al escalar (¿o es eso RoR ?, ¿o es una tontería para ambos?).

También lo ha hecho PHP. :-)

Personalmente, creo que es una tontería para Ruby. Al escalar, en cualquier idioma, observa los cuellos de botella y trabaja en ellos uno por uno. A partir de ahí, escalas vertical y horizontalmente.

Reemplaza el idioma de tu mascota cuando sea apropiado (no ejecutaría un servidor de chat o algún servicio financiero de alto rendimiento en PHP o Ruby, por ejemplo). Pero, en general, en mi experiencia, el lenguaje no es el núcleo del problema al escalar, no importa cuán lento sea: la arquitectura es. (Si el lenguaje fuera el núcleo del problema, los sitios se escribirían principalmente en C, C ++, C #, Java, Lisp, Erlang, etc. Cada uno de estos últimos supera a PHP y Ruby en uno o dos órdenes de magnitud).

Para RoR, no puedo decir. Solo lo miré superficialmente. Sin embargo, entiendo completamente por qué o cómo RoR satisfaría a un diseñador gráfico o un estudiante de CS. Insultó todo lo que he dado por sentado como desarrollador de bases de datos.

Sin embargo, más tarde me topé con Zed Shaw (un tipo que escribió un servidor web Ruby). Entre otras cosas, se burló del creador de Rails por no poder mantener sus propios servidores de producción funcionando durante más de 4 minutos en promedio. (Esto ha mejorado desde entonces).

Denis de Bernardy
fuente
Estoy totalmente de acuerdo en que después de aprender los conceptos básicos de Ruby, PHP ahora me da náuseas y vómitos. En cuanto a Rails, el objetivo de Active Record es ser un ORM y dejar que los desarrolladores, que pueden no estar bien versados ​​en el diseño de bases de datos, hagan cosas básicas de la base de datos mientras se mantienen fuera de la mayoría de los problemas. Si puede escribir SQL mientras duerme, entonces Active Record se sentirá bastante restrictivo y tal vez incluso "tonto". Pero creo que vale la pena, aunque solo sea para hacer que sea más fácil escribir código bueno que escribir código malo, o peor, código con agujeros de seguridad.
Michael Hampton
2

Francamente, sus preguntas no me parecen claras, pero intentaré responderlas de todas formas.

¿Un programador de PHP querría aprender Ruby ?, sé que sí, pero a la inversa, ¿un programador de Ruby querría aprender PHP?

Sin ofender, pero esta pregunta no tiene respuesta. Realmente depende de demasiados factores, muchos de los cuales están vinculados a la personalidad del programador. Respuesta fácil: por supuesto, ¿por qué no? Es una herramienta más para crear sitios web.

¿Qué tipo de proyectos o situaciones serían más adecuados para Ruby que no son adecuados para PHP?

En cuanto a los proyectos, ambos son igual de adecuados (si mal no recuerdo, el rubí corre más lento, aunque esto es para tomar con una pizca de sal desde AFAIK, stackchange está construido con RoR [nunca leí los puntos de referencia reales]). Una situación que encajaría una más que la otra es si tiene la intención de utilizar un marco particular, o si su equipo está formado por personas que tienen más experiencia en uno de los dos idiomas. Realmente no creo que haya ningún tipo determinado de proyecto que sea "ideal" para un lenguaje específico. Realmente se reduce a los detalles de cada proyecto (e incluso entonces, las diferencias serían sutiles).

¿Cuál es el ecosistema real de Ruby ?, aparte de RoR, no he visto otras tecnologías / frameworks publicitados.

Ruby on Rails es una parte enorme del éxito de Ruby. Ruby mantuvo un idioma desconocido hasta que RoR salió. Hay muchos proyectos interesantes construidos en Ruby, pero nada se acerca en términos de éxito y aceptación por parte de la comunidad. Hay CMS construidos sobre RoR que son bastante conocidos. Lovd by Less por ejemplo.

Suponiendo que hay un cierto tipo de proyectos ideales para Ruby, ¿habría algún momento en el que sea mejor moverlo a PHP?

El único caso que puedo imaginar es justo después de la creación de prototipos con Ruby, si cree que PHP cedería a un desarrollo más rápido. Pero una vez que se inicia un proyecto, ¿cómo piensa "moverlo a PHP"? Puerto todo el código que se ha escrito?

Finalmente y lo más importante, ¿sería sensato mantener proyectos en dos idiomas?

Si no tienes una bazuca apuntada a tu cabeza, absolutamente no.
Si te refieres a mantener dos proyectos completamente diferentes en dos idiomas diferentes, entonces absolutamente. No creo que vaya a pasar mucho tiempo con el mismo idioma. Por ejemplo, salto constantemente de un idioma a otro. Domino solo unos pocos, pero sé lo suficiente de los demás para salir de cualquier situación (hasta ahora). Soy autónomo, por lo que las personas que trabajan en empresas pueden tener una experiencia diferente. Pero mi punto es que mantener diferentes proyectos en diferentes idiomas es fácil (suficiente) y divertido.

Xananax
fuente
2
Hace poco leí que stackxchange está construido en ASP.NET MVC. No es que sea alemán para tu publicación, pero pensé en mencionarlo.
kinakuta
tienes razón, editaré mi publicación para corregir eso.
Xananax
+ 1 para el "Si no tienes una bazuca apuntando a tu cabeza, absolutamente no". Mezclar idiomas en el mismo proyecto es problemático porque todos los encargados del proyecto deben conocerlos a ambos, y es difícil encontrar un desarrollador que sea lo suficientemente bueno en ambos idiomas. Por supuesto, si hay una separación clara entre cada parte (como por ejemplo, back-end y front-end) puede tener una excusa. Pero es como llamar a problemas.
Carlos Campderrós
No me refería a un solo proyecto en ambos idiomas, sino a tener algunos proyectos en PHP y otros en Ruby.
dukeofgaming
Mi mal entonces. No sé si su pregunta no está clara o si estaba bajo la influencia de lo que estaba trabajando (motor de marcado en php con vista previa en js, exactamente como stackxchange), por lo que dos analizadores en dos idiomas deben generar exactamente el mismo resultado). Si te refieres a tener diferentes proyectos en diferentes idiomas, entonces, por supuesto, absolutamente. Siempre necesito unos días para aprender un idioma que no has usado en mucho tiempo, pero vuelve muy rápido.
Xananax
0

Al leer, tenga en cuenta que soy un desarrollador de Ruby on Rails y que respondo desde ese ecosistema. Mis puntos de vista estarán sesgados en esa dirección.

¿Un programador PHP querría aprender Ruby ?, sé que sí, pero a la inversa, ¿un programador Ruby querría aprender PHP?

Absolutamente no, en la mayoría de los casos. No solo porque no me gusta PHP (no me gusta, pero lo uso), sino porque los conjuntos de herramientas tienen diferencias ideales fundamentales. Hay muchas herramientas como rake y rspec que ayudan con algunas de TDD en el mundo del rubí. En la mayoría de los tutoriales de ruby ​​(y ciertamente rieles) la prueba es lo primero. Eso no quiere decir que no pueda hacer esto en PHP, es solo que las convenciones son diferentes. Y las diferencias convencionales entre los dos idiomas son, en general, directamente opuestas.

¿Qué tipo de proyectos o situaciones serían más adecuados para Ruby que no son adecuados para PHP?

Aplicaciones de escritorio, scripts de shell, aplicaciones MVC (rieles nuevamente) y pequeñas aplicaciones de consola. No es que ninguno de estos se pueda hacer con php, Ruby solo tiene un mejor soporte. Cuando escribo una aplicación Rails (lo siento), a menudo escribo scripts en ruby. Esto permite que mis scripts de implementación o configuración estén en el mismo lenguaje que mi aplicación, donde con PHP ni siquiera trataría de escribir un script de shell en PHP. Solo usaría bash. He escrito aplicaciones Ruby QT y aplicaciones MVC (tanto Rails como no) y ruby, y sus bibliotecas circundantes simplemente "funcionan mejor" para esos casos.

¿Cuál es el ecosistema real de Ruby ?, aparte de RoR, no he visto otras tecnologías / frameworks publicitados (he visto RSpec, pero confieso ser un novato total en lo que realmente consiste BDD y sus implicaciones).

Esto es una especie de error. RoR es popular porque hace bien su trabajo, pero puede haber otros conjuntos de herramientas / pilas que usan ruby ​​en su núcleo. Son menos populares porque están entrando en un espacio que ya tiene alternativas. Por mi parte, me gusta escribir aplicaciones GUI rápidas en ruby. Pero python, C #, VB, LISP, etc., etc. ya pueden hacer esto. RoR fue un cambio de juego. Por eso es popular. Lo mismo puede decirse de PHP, denomine un marco PHP popular. Hay algunos, pero elimine productos (como WordPress) de la lista, y no quedará con un montón.

Suponiendo que hay un cierto tipo de proyectos ideales para Ruby, ¿habría algún momento en el que sea mejor moverlo a PHP? Sé que PHP puede manejar muchas cosas, pero he leído que Ruby tiene sus limitaciones al escalar (¿o es eso RoR ?, ¿o es una tontería para ambos?)

Esta es una pregunta difícil y tienes que preguntar, ¿qué idioma es mejor para mi proyecto? Nunca escribiría un blog en Rails. Sé que ese es el ejemplo de tutorial estándar, pero si quieres un blog, entonces WordPress es la herramienta adecuada. Lo mismo se aplica aquí. Si se encuentra con un ejemplo sólido de la necesidad de cambiar los idiomas de Ruby, las limitaciones técnicas que enfrentará también impedirán PHP.

Finalmente y lo más importante, ¿sería sensato mantener proyectos en dos idiomas ?, o ¿es simplemente estúpido? Como dije, parece que Ruby es más ágil a corto plazo y eso puede hacer que un proyecto suceda y tenga éxito, pero no estoy tan seguro de eso a largo plazo.

Ruby es genial a la larga. El mayor obstáculo para el éxito a largo plazo no es el lenguaje, sino el desarrollador. En cuanto al mantenimiento de dos idiomas, depende de cómo defina un proyecto. Tengo algunos proyectos que tienen una gran aplicación en rails, y un blog o sitio de ventas usando wordpress / dupral / some php. Los considero proyectos separados. Diré que cuantos más idiomas termines admitiendo, más difícil será encontrar un buen desarrollador que sea bueno en todos los idiomas. Por ejemplo, uso y recomiendo wordpress, pero no estoy tan "bueno" en PHP como en RoR. Si un cliente realmente quisiera la mitad de su producto principal en PHP y la otra mitad en RoR, realmente tendría que averiguar por qué, y dependiendo de su respuesta probablemente rechazaría el trabajo.

coteyr
fuente