Es refrescante de vez en cuando leer artículos que no hablan sólo de lo brutal que es AJAX, o de los fácil que es escribir un sitio con Ruby / Rails o de lo mucho que apesta Java. Uno de los colaboradores regulares de O’Reilly escribió un articulo titulado “7 reasons I switched back to PHP after 2 years on Rails“.

No, el articulo no es sobre si PHP es mejor o si Java es mejor o si Ruby / Rails es la siguiente cura contra el cancer. Es sobre como utilizar las herramientas con las que estamos más cómodos (noten que el autor tuvo que contratar a desarrolladores que escribian en Ruby porque el no lo hacia tan bien) y con las que mejores podemos hacer el trabajo (si, todas tienen sus bondades y defectos).

Por cierto, los comentarios a favor y en contra del articulo son de antología. Algo me dice que aquí ocurrirá algo similar.

La moraleja: Sea pragmático y haga lo que sabe hacer mejor :)


10 Respuestas a “Cuando Ruby / Rails se raja: La historia del PHP que si pudo”

  1. 1 myself

    Me parece que el articulo es una falacia, de paso no contiene ejemplos de lo que esta hablando, ademas mezcla ruby y rails como lo mismo casi todo el tiempo.

    De paso tu titulo tambien es malo, ni siquiera esta acorde con el articulo donde el autor menciona que cualquier cosa que se haga en ruby se puede hacer en php, de hecho es cierto, lo podemos extender: lo mismo que se hace en ruby se puede hacer en cualquier otro lenguaje.

    En resumen, el autor volvio a php porque es un mal programador. Por cierto, su pagina parece un sitio de SPAM. www.cdbaby.com

  2. 2 Roman Gonzalez

    En verdad que, como dije antes: Rails es muy bueno para un tipo de aplicaciones y cada lenguaje/framework debe ser usado para lo que fue destinado.

    Cuando el amigo josevnz (aka Kodegeek) dice: “Sea prágmatico y haga lo que sabe hacer mejor” _yo considero_ que eso no tiene sentido, al menos no en el ámbito de la programación; si supiera hacer las cosas bien en Prolog eso implica que ¿Voy a hacer mi aplicación Web en eso? NO. El mundo de la programación no es así, este avanza, y muy rápido; al ser “pragmatico” todo el tiempo, antes de darte cuenta te quedas atras con los que defienden Prolog o COBOL (u otros pre-historicos :-P) como _mejor_ solución para problemas actuales.

    Hay que saber que herramienta es mejor para el tipo de problemas que estamos afrontando, y saber asumir cuando tenemos que “aprender a desaprender” (PDF). No tiene gracia realizar la implementación en Rails cuando tienes una metodología JEE o PHP metida en la cabeza (como por ejemplo no usar las convenciones Rails ó amar SQL en vez de usar un ORM), lo mismo aplica en el caso contrario. Si ese fuera el chiste, todos los lenguajes serían iguales, cosa que no es.

    El amigo Derek Sivers (Creador de CDBaby) tal vez tenía en mente usar Ruby como PHP o PHP como Ruby, lo cual “no es”, te vas por “The Ruby Way” ó por “The PHP Way”. Hasta el mismo autor del post asume su falta de entusiasmo por aprender bien el uso de Rails y de analizar el código del Framework (Punto 3), algo que cualquier programador que esté usando Rails de la manera correcta haría, ya que esta bien documentado y bien hecho. Si no lo entiende, el problema no es el código, es usted… que no sabe suficiente Ruby.

    Otro problema clave en esto es el hecho de cambiar TODOS tus proyectos de empresa a Rails (Punto 2), aún si tienes que entrenar a 85 personas para lograrlo, eso no es mas que antojo, esa no es la manera de hacer las cosas, ni aunque tuvieras al mismo DHH sentado al lado tuyo tendrías exito.

    Cito una frase que lei en algun libro de programación o patrones (no me acuerdo ya de cual :-$). “La calidad de un lenguaje está en la cantidad de patrones de diseño que necesita para lograr buenas implementaciones, cuando un lenguaje esta _bien pensado_ la cantidad de patrones de diseño que necesita es menor.”

    Muy bueno el post (a pesar de mis diferencias en la manera de pensar ;-) ).

    Saludos.

  3. 3 myself

    @Roman Gonzalez: estoy muy de acuerdo contigo, deberias contestar en tu blog =)

  4. 4 josevnz

    Cesar,

    Cuando yo escribía acerca de ser pragmático, me refería al lenguaje o framework apropiado. No existe una bala de plata con la que puedes matar todos tus proyectos y esta fiebre con Ruby me recuerda a la que hubo con PHP varios años atrás.

    Al buen entendedor pocas palabras.

    “_yo considero_ que eso no tiene sentido, al menos no en el ámbito de la programación; si supiera hacer las cosas bien en Prolog eso implica que ¿Voy a hacer mi aplicación Web en eso? NO.”

    Más de una vez (y sobre todo para aplicaciones pequeñas) basta con escribir un CGI en cualquier lenguaje, sin meterse con Rails, Jafa Faces, etc. Luego cuando la aplicación crece se cambia (lenguaje y framework incluido). Eso es una parte del ciclo de vida del software y por supuesto parte del ‘refactoring’.

    “La calidad de un lenguaje está en la cantidad de patrones de diseño que necesita para lograr buenas implementaciones, cuando un lenguaje esta _bien pensado_ la cantidad de patrones de diseño que necesita es menor.”

    ¿Es por eso que todo el mundo habla de Rails y no de Ruby? Hasta de donde yo recuerdo un framework es una coleción de patrones de diseño los cuales te dicen como hacer las cosas (Rails way, JSF way, Struts way).

    Finalmente el hecho de que el autor (con todos sus problemas) haya podido mejorar su código PHP sin necesidad de un framework dice mucho de hasta donde las herramientas gobiernan la forma como trabajamos y resolvemos problemas (si solamente tienes un martillo entonces todos los problemas te pareceran un clavo).

    Saludos.

  5. 5 Roman Gonzalez

    @kodegeek

    “Cuando yo escribía acerca de ser pragmático, me refería al lenguaje o framework apropiado. No existe una bala de plata con la que puedes matar todos tus proyectos”.

    Si ese es el caso estamos hablando exactamente de lo mismo, es tonto tomar a Ruby/Rails como una solución a todos tus problemas, no es viable.

    “Más de una vez (y sobre todo para aplicaciones pequeñas) basta con escribir un CGI en cualquier lenguaje, sin meterse con Rails, Jafa Faces, etc”

    ¿Realmente la _mayoría_ de la gente lo pensaría como una opción a la hora de desarrollar un proyecto que se sabe que va a ser mas grande que un “hola mundo”?, Mi punto al decir que “no vamos a desarrollar esta app en Prolog o cualquier otro vejete” es que hay que saber aceptar cuando una tecnología/lenguaje se queda atras ó esta no es practica como solución para el problema que se tiene.

    “¿Es por eso que todo el mundo habla de Rails y no de Ruby? Hasta de donde yo recuerdo un framework es una coleción de patrones de diseño los cuales te dicen como hacer las cosas”

    Completamente válida esa observación, los frameworks no son sólo una colección de patrones de diseño (como ActiveRecord en el caso de rails, o un ServiceToWorker en el caso de JEE), sino también una colección de metodologías (CoC, DRY por parte de Rails e IoC por parte de JEE/Spring).

    Que bueno que se llegen a tener algunos aciertos en la manera de pensar :-).

    Saludos.

  6. 6 Fernando

    Yo hace 6 meses que estoy en Ruby On Rails y vengo de estar desarrolando 4 años en php, la verdad el framework me parece interesante, pero en un gran proyecto me quedo con PHP lejos, y en eso tiene razon el articulo, que lo que hace este Framework perfectamente lo podes hacer en PHP , otra cosa es el tema de las consultas, si uno realiza grandes listados, o muestra mucha informacion es necesario usar consultas sql directamente por que se ve que la gente que diseña rails le fascina hacer consultas ( y aparte es necesario por la trasparencia de la base de datos) asi que mi opinion es que si es un proyecto chico usen Rails, si es a gran escala usen PHP, por que la perfomance que van a obtener va a ser mucho mejor

  7. 7 hkadejo

    Pues bueno, aunque rails es lo de moda aparentemente y sus ventajas tendra como es obvio, yo soy desarrollador JAVA…y pues todo lo que se hace en rails y php…en Java se hace con igual eficiencia o mayor…asi de sencillo…si quieren una aplicacion empresarial Java es lo unico que tendrian que tener en los labios….bueno es mi opinion.

  8. 8 myself

    todo lo que se hace en ruby se puede hacer en php, igualmente todo lo que se hace en php se puede hacer en ASM, sin duda.

    asm y php son lenguajes horribles, tampoco hay duda.

  9. 9 myself

    ah por cierto, la implementacion de ruby2 que esta proxima a salir es mucho mas rapido que la implementacion de PHP actual

    Si rails es una moda con ruby1, va a hacer una moda muuuuuy larga con ruby2

  10. 10 José

    Hola… bien, he estado por instrucción propia y por curiosidad de lo que he podido ver en internet a utilizar RoR, confieso que poco he interactuado con java, sin embargo algunas cosas he hecho en desarrollos de aplicaciones bancarias, con php si he logrado tener experiencia, sin embargo mi fuerte es perl, me gusta mucho el lenguaje c, pero en éstos últimos 4 meses he estudiado poco, pero detenidamente, al lenguaje ruby (puro), es un lenguaje pegajoso, y cuando tuve la oportunidad de conocer el framework rails junto con el ruby, el RoR, pues que nota! es super fácil, me parece como si estuviera aprendiendo visual basic, lo veo demasiado sencillo, pero creo que le falta mucho madurar sobre en lo que se refiere al uso de los plugin, lo veo sinceramente cerrado al framework, pero en sí me gusta mucho, ahora bien, he leido algunos artículos, y creo que cada uno de ellos tiene una tendencia a favor o en contra del RoR, la intención de mi escrito es darles a conocer un artículo al cual no estoy de acuerdo para nada en el “análisis” que supuestamente hacen en referencia a el principio del fin de RoR, el link es el siguiente y lleva por titulo: ¿Ruby on Rails está muerto? y el link es: http://www.programacion.com/noticia/1516/ (disculpen el plugin del wordpress no permite envío de tags para link, por el spam), honradamente no sé si los señores conocen en realidad al lenguaje ruby en profundidad o algunos de los lenguajes que colocan en contraste al mismo, pero en realidad creo que si como dicen allí que java y php han reaccionado ante el RoR, no creo que cuando evolucione el RoR a una nueva versión o nazcan nuevas herramientas se dirá que está muerto, no lo creo honradamente y más aún cuando se están por ver nuevas versiones del lenguaje ruby…

Añade un Comentario





RSS feeds

Suscríbete a nuestros RSS Feeds