Barrapunto

Se está diciendo mucho por aquí que CGI != modperl, pero también se está diciendo que servlets = jsp y eso es erroneo. Un servlet es un class java y los jsp's son , digamos, parecidos a los preprocesadores como PHP y ASP. Yo personalmente he visto cosas pequeñísimas hechas con servlets (un noticiario) y era como matar moscas a cañonazos y un sistema de contabilidad en perl (sql-ledger creo que era) que iba un poquito lentorro con media carga y era muy complicado de mantener el código.

Yo creo que la discusión está mal centrada.

La cosa es que, como para casi todo, cada cosa tiene su nicho, y Java tiene un buen conjunto de servidores de aplicaciones y business-logic engines (jboss,bea weblogic,etc...).
Con respecto a lo del CPAN ... el JDK actual tiene un surtido framework, y ya el .NET framework ni hablemos ...

La gente que está diciendo el tema de "Slashdot funciona con modperl!" Si bueno ... pero no es una aplicación que realice las transacciones en tiempo real (lapso de publicación) y también cachea contenidos (la pagina principal, plantillas, etc...). Y tampoco recibe tantas tantas visitas ni tanta tanta carga.

La gente también opta por Java por el mantenimiento del código. Es más facil aprender Java que Perl y hoy en día mucha gente conoce Java, al menos para hacer applets. Un programador Java puede "recolocarse" y comenzar a programar servlets en poco tiempo y crear un código más mantenible que un programador que programa en Perl ("un jeroglifico para que???" :D ) Por eso los ejecutivos están optando por Java para casi todo lo que suene a "business-logic" o "workflow", no se quieren vender a un código que solo entiende el que lo ha creado.

Y bueno, viendo el rumbo que lleva Perl 6 ... se va a parecer un "poquito" a Java ...

Creo que con Zope también se puede utilizar el lenguaje Perl para desarrollar métodos.¿Alguien tiene experiencia con Zope?¿Qué rendimiento ofrece?
Una prueba interesante que se podría realizar sería correr un código perl (alguno típico que se utilice para pruebas de rendimiento) en un script cgi, en mod_perl e integrado en Zope para comprobar el rendimiento. ¿Quién ganaría?

> Se está diciendo mucho por aquí que CGI != modperl, pero también
> se está diciendo que servlets = jsp y eso es erroneo. Un servlet
> es un class java y los jsp's son , digamos, parecidos a los
> preprocesadores como PHP y ASP.

De hecho un JSP *es* un Servlet. El aspecto, sí, es el de un ASP, y se pueden hacer bien o mal (separar presentación del "negocio" o mezclarlo todo a lo bruto) pero al llamar a un JSP se crea un Servlet con su funcionalidad y es este objeto el que se ocupa de las peticiones...

La diferencia entre mod_perl y el modelo de servlets/j2ee es mucho más profunda: java trabaja al nivel de aplicación, por encima del HTTP, mientras que mod_perl te permite trabajar al nivel del HTTP y participar de forma íntima en cada una de las fases del procesado de una petición HTTP, desde que llega hasta que se responde, y qué se responde: he realizado aplicaciones con suma facilidad en Perl que interceptan, por ejemplo, las peticiones de autenticación de una web, autentican contra un LDAP de forma segura (utilizando usuarios de binding controlados) y generan una cookie correspondiente antes de continuar tratando la petición (esto, por ejemplo, permite un modelo de seguridad en la que no se obligue al usuario a comenzar desde el principio si su sesión caduca, simplemente, si se autentica, puede seguir como estaba antes... muy cómodo por ejemplo para correos y otras aplicaciones similares web, que siempre jode un montón cuando después de escribir un e-mail muy largo lo pierdes porque te caducó la sesión: hay otras formas de resolver esto, pero esta es sencilla y transparente, y está tirada de implementar, cumpliendo con la LOPD, y demás gaitas...).

Desde luego Apache::Registry te permite programar aplicaciones en plan servlets con suma facilidad (con persistencia, compiladas, múltiples hilos con un mismo intérprete, etc... igual o mejor que un tomcat) pero además puedes ir a bajo nivel, y eso permite conseguir, con la rapidez y potencia de programación del Perl, que el Apache se convierta, en cierta manera, en tu aplicación dedicada... Tan escalable como escalable es el Apache (si no hacemos trampas, claro), lo que no es moco de pavo...

lo cual no quiere decir que sea lo mejor para aplicaciones con tráfico muy pesado, pero usando un modelo REST en vez de SOAP, tenemos todos los beneficios de un modelo superior y un lenguaje/entorno muy potente, muy maduro, abierto, con una gigantesca librería (CPAN ya no cabe en un DVD) y con una gran comunidad de desarrolladores/empresas que lo usan y apoyan.

pero bueno, cada uno que use lo que sepa
salue!