Barrapunto

Precisamente yo hice mi proyecto de fin de carrera sobre ese mismo tema.

Mi opinion: mod_perl esta bien para cosas mas o menos pequennas, para cosas mayores los servlets eran mucho mas faciles de manejar.

Y los servlets eran bastante mas rapido y consumian menos memoria en cuando tenias unas pocas de peticiones simultaneas.

La comparacion se hizo con apache 1.3 y apache jserv en 1999.

Estoy de acuerdo con el contertulio anterior, de todos modos yo no he tenido problemas en escalar aplicaciones con mod_perl, si bien entiendo que los servlets proporcionan ventajas interesantes, entre las cuales yo creo que se lleva la palma la atomización y la flexibilidad que deriva del uso de servlets, ya que mod_perl es más rígido. Igualmente interesante es la reusabilidad de los servlets que se cargan y permanecen disponibles para otras peticiones (persistencia) mientras que CGI requiere una carga, un uso y un die. Y si hay otro usuario, otra carga, otro uso y otro die.

Definitivamente me inclino por servlets. CGI tradicional era y es una gran idea pero se está viendo creo yo relegado por los servlets :-)

El debate del enlace comienza así:
I'm about to start work on a web application which will collect information from the user and return a document based on that information.

Para el caso en que plantea, una aplicación web que simplemente recoja y manipule información lo más aconsejable sería usar cgi´s en perl de toda la vida por varias razones:
En el caso de no disponer del mod_perl, instalarlo es más sencillo que tener que instalar un contenedor de servlets como Tomcat.
A la hora de procesar información y en general programar, por su naturaleza de lenguaje de script perl es bastante más flexible que Java.
Java te obliga a programar mediante poo, para aplicaciones pequeñas esto puede ser un engorro con Perl puedes elegir cómo hacerlo.

La potencia de los Servlets se nota cuando se usan en un Servidor de aplicaciones combinados con páginas jsp, Beans e inclusos portlets en entornos críticos donde se realizan muchas peticiones y es importante la velocidad de respuesta ya que es donde se aprecia realmente la función del contenedor de servlets o de beans.

...obviositicamente, una de las ventajas mas importantes de mod_perl sobre los servlets, es que el primero es perl, y el otro java, y yo (mismamente) no se java. -Y como se dice por ahi-, "usa ...lo que quieras de entre lo que sepas".

Pues eso, que veo a la peña hablando de CGI cuando MODPERL es otra cosa distinta.
Si queréis hablar de CGI adelante, ya casi nadie lo utiliza por desfasado. Si queréis hablar de MODPERL adelante, la unión más bella que jamás he visto con apache, aunque todo hay que decirlo, no he visto más uniones que ésta.

Sinceramente creo que hay dos ventajas realmente diferenciales, el resto es todo ruido :-)

1) CPAN

2) Hacer algo bien hecho en Java requiere al menos el doble de tiempo que algo bien hecho en perl.

2.bis) perl es hermoso y Java apesta !

Creo que no hay discusion, la cambiamos por una entre perl, python y ruby? :-)

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 ...

Como esto es barrapunto, en cualquier discusión "tecnología X vs tecnología Y" y sin necesidad de leer los comentarios, ya sabemos que se van a polarizar dos tendencias:

A) Los fundamentalistas del software libre, también mal llamados talibanes (que el mullah Omar no se quede con vuestras caras por usurpar su dialéctica y capacidad de persuasión con argumentos irrefutables como "la tecnología Y es mejor porque es libre"). Son los mismos que le instalan furtivamente una Debian 3.0 Woody a su primo de 12 años, cuando éste le pide que le ayude a configurar su nueva tarjeta gráfica.

En este caso esta claro que se decantan por Perl, un lenguaje en principio solo entendible por esquizofrénicos, aunque bastante potente sin duda, tan potente como una sierra circular enchufada y sin seguro debajo de la almohada. O lo que es lo mismo: "mañana" me contarás que es lo que has programado anoche, si puedes contarlo.

B) Los patéticos aficionadillos (pobrecitos habladores en su mayoría) que dan su humilde opinión en función de: su experiencia personal y profesional, la experiencia acumulada de otros coleguas profesionales, las demandas del mercado y otras cosas tan insignificantes como criterios objetivos y conceptos básicos de programación.

En este caso dirán que en principio la comparación "mod_perl" vs "servlets" no tiene sentido si no se especifica la dimensión del proyecto y la carga que va a soportar, así como su ciclo de vida y mantenibilidad. En caso de ser forzados a elegir, elegirán java, de la misma manera que eligirian estudiar inglés como segundo idioma en lugar de mongol khalkha con grafía tradicional (vertical).

Mi patética aportación:

* Java -> Proyectos con gran complejidad en la lógica de negocio y que han de ser mantenible por un grupo de personas, a ser posible del mismo planeta.

* mod_perl -> Webs dinámicas conceptualmente simples (como barrapunto), que van a ser mantenidas por un puñado de frikis sin cobrar un duro y que funcionarán o dejarán de hacerlo sin que nadie se dé por aludido (Y esto va por los editores de barrapunto, que hace un mes o así que la inserción de comentarios falla más que una escopeta de feria). Aunque, después de todo, para estas cosillas ya está PHP. ¿O no?