Scripting: Ruby on Rails versus PHP

28-01-2006 Luis Artola

En diferentes foros yo se habla de otra cosa: Ruby on Rails. Se trata de un framework para programar webs en Ruby.

Ruby es un lenguaje de scripting que sabe aprovechar lo mejor de la programación de scripting y de la programación orientada a objetos. Esto, al parecer, le combierte en una solución muy productiva que te permite crear webs de forma rápida y sencilla. “On Rails” es un framework MVC + Active Record cuya principal característica es que te lleva “por unos railes”. A lo que se refiere esto es a que establece una serie de convencionalismos para que tengas el código perfectamente ordenadito. Esto resuelve parte de la problemática típica de los lenguajes de scripting, donde los programadores tendemos a crear código poco elegante, poco ordenado y bastante chapucero, mientras que en otros lenguajes, como Java, todo suele estar más ordenado.
Particularmente no he programado nada todavía en Rails, pero me pica el gusanillo. Lo que más me echa para atrás es que no se trate de un lenguaje c-like (con sintáxis tipo C) como Java o PHP. No me apetece aprender otra manera de escribir código.

Sin embargo hay otra cosa que me escama. ¿Por qué Martin Fowler (estoy enamorao) nunca habla de PHP? Siempre que habla de Ruby on Rails (al parecer le encanta) lo compara con Python o Java. ¿Por que no habla de PHP (o de ASP)?

Me gustaría que un gurú de su categoría me estableciera una buena comparación entre ambas soluciones. (Espero que Martin me lea y lo haga :-D )

5 Comentarios

  • 1. Pobrecito hablador  |  enero 28th, 2006 at 12:40 pm

    Hola, no soy Martin pero trabajo realizando ports de Ruby a PHP.

    Cuando pides una página PHP a un servidor Web, este ejecuta de principio a fin todo el código para enviar un salida válida al servidor.
    Eso está bien para una aplicación simple, pero ahora imagina que tengas 100 relaciones complejas en la base de datos. En ese caso PHP tendría que “montar” esas relaciones cada vez, mientras que en otros lenguajes persistentes se puede mantener en memoria el proceso para realizarle peticiones de forma persistente.

    PHP comenzó como un simple lenguaje de plantillas, con lo que no fue concebido como un lenguaje de programación como tal. Ultima mente se ha conseguido con PHP5 una base más sólida en cuanto a referencias de objetos y a excepciones, pero no creo que Martin Fowler se considere PHP como posible solución hasta que no disponga de alguna forma de persistencia real (hay varias emulaciones chungas por ahí) y también tenga soporte para namespaces.

  • 2. Luis Artola  |  enero 28th, 2006 at 1:36 pm

    Me parece muy interesante tu respuesta. Que pena que no hayas dejado nombre y mail. Tu comentario me suscita varias preguntas. Sé que Java tiene mecanismos de persistencia mediante EJB´s o Hibernate, etc. que le permiten mapear objetos a base de datos (ORM, bla, bla..). En Java, también, cuando lanzas un servlet éste no se deja de ejecutar cuando el servidor da una respuesta, y por eso Java funciona con “servidores de aplicaciones” como Tomcat mientras PHP funciona sobre “servidores web” como Apache.

    Sin embargo, yo pensaba que esto diferenciaba a .Net y Java de tooodos los lenguajes de scripting (PERL, PHP, PyTHON, y RoR)… ¿me dices, entonces, que Ruby tiene mecanismos de persistencia, como por ejemplo los de Java?
    Yo se que Ruby maneja sus relaciones con la base de datos mediante un patrón llamado Active Record. Y que ese patrón puedes representarlo tanto en PHP, como en Java como en RoR, etc. ¿No es esto así?
    Me interesaría mucho tu respuesta ya que trabajas con RoR y PHP. También me gustaría saber exactamente en qué consiste tu trabajo, si te apetece hablar de ello.
    Lástima que éste comentario haya sido un anónimo. :-S

  • 3. incognito  |  enero 28th, 2006 at 11:03 pm

    Mmh parece que pobrecito hablador habla de php como CGI, en mi limitado conocimiento (no soy progamador), Ruby como languaje es en mi opinion muy muuuy superior a php, totalmente OO(puedes teclear como si fuera funcional pero en realidad sigue siendo OOP), es intuitivo a mas no poder, y basicamente es una droga, despues de Ruby todos los demas languages parecen muletas para que la computadora entienda, Ruby es para que UNO entienda, el programador[MI opinion].

    Rails puede correr en varios webservers, como CGI(exasperadamente lento,supongo q lo que pobrecito hablador hablaba, cierto para cualquier CGI en cualquier lenguaje sea ruby,php,python,etc), fastcgi(bastante mas veloz pero, la implementacion deja que desear, al menos en apache, algunos recomiendan FCGID en vez de mod_fastcgi pero no he logrado echar a correr en fcgid, aunque estoy en windows), o puedes usar SCGI(como fastcgi pero en codigo nativo de Ruby), tanto fastcgi como SCGI, mantienen una instancia(s) de la aplicacion evitando el overhead(lentitud) de fastcgi y dandole velocidad a la aplicacion, mod_fastcgi tambien funciona con otros lenguages o debe de.

    Ya dije que no soy programador pero Ruby me deja solucionar problemas con F.A.C.I.L.I.D.A.D. por dificil que parezca!! mas que php, lo use antes de conocer Ruby, tambien otros lenguages(brevemente). Rails es casi como Ruby, facil, intuitivo, bien organizado, consistente(casi nunca tengo que buscar los metodos que aplican a x objeto, son casi obvios), usa convencion en su mayor parte, la configuracion es minima y sigue siendo UN SOLO LENGUAGE desde la configuracion(excepto por database.yaml) desde los controladores, ruteos, “templates”, la consola (utilisima! ruby script/console) todo es Ruby. ActiveRecord realmente facilita interactuar con la base de datos pero tambien te deja usar SQL directo, migraciones, estructuracion, organizacion,paginacion,helpers(ayudantes, NO wizards) codigo limpio y facil de leer/comprender.

    Rubydoc:
    http://www.ruby-doc.org/
    Rails tutorial:
    http://rails.homelinux.org/ (en español, algo pasado, aplica a 0.12.1)
    Rails API:
    http://api.rubyonrails.com/
    Rails Howtos (instalacion, ambientes, configuracion)
    http://wiki.rubyonrails.org/rails
    Rails screencasts, los famosos videos.
    http://www.rubyonrails.org/screencasts
    rails cheatsheet : http://www.ilovejackdaniels.com/ruby-on-rails/ruby-on-rails-cheat-sheet/

    Reitero, lejos estoy de ser una autoridad, lo q si puedo decir es Ruby>php y Rails es facil, aprende un poco de Ruby(dale un par de tardes) y luego metete a Rails(empieza usando webrick, no es super veloz, pero es mas facil iniciar/tantear las aguas) no creo q te arrepientas, compara tu mismo, yo ya habia usado Ruby por un par de años y no tuve problemas con Rails(mas bien con apache y fastcgi ).

  • 4. incognito  |  enero 28th, 2006 at 11:06 pm

    correcion el texto

    “tanto fastcgi como SCGI, mantienen una instancia(s) de la aplicacion evitando el overhead(lentitud) de fastcgi y dandole velocidad a la aplicacion”

    deberia ser:

    “tanto fastcgi como SCGI, mantienen una instancia(persistente en memoria) de la aplicacion evitando el overhead(lentitud) de CGI(el cual relee y reprocesa todo el codigo en cada request) dandole velocidad a la aplicacion”

  • 5. Luis Artola  |  enero 29th, 2006 at 2:10 am

    Incógnito, gracias por tu participación.
    ¿no eres programador? Parece que sabes mucho de lo que hablas. Eso me congratula. Prometo dedicarle más atención a Ruby on Rails, veo que está en boca de todo el mundo. (hasta ahora ha sido mi post más exitoso :-D )

Comenta el articulo:

Requerido

Requerido,