2010-05-23 16 views
5

Planeo agregar una mejor función de búsqueda a mi sitio, así que pensé que lo escribiría en C y usaría el CGI como medio para acceder a él. Pero parece que Perl es el lenguaje más popular cuando se trata de material basado en CGI. ¿Porqué es eso? ¿No sería más rápido programado en C o código de máquina?¿Por qué Perl se usa comúnmente para escribir scripts CGI?

¿Qué ventajas, si las hay, existen para escribirlas en un lenguaje de scripting?

Gracias.

+0

posible duplicado de [¿Cuáles son las razones para elegir un lenguaje de scripting sobre C#?] (Http://stackoverflow.com/questions/1193912/what-are-reasons-to-choose-a-scripting-langu age-over-c) – Quentin

+1

@David: esta pregunta parece ser específicamente sobre Perl versus C para scripts CGI. –

+0

Las respuestas son las mismas. – Quentin

Respuesta

3

La mayor ventaja de utilizar Perl es CPAN.

+4

oh, claro, * ahora * todo se trata de CPAN, pero en el pasado, todos obtuvieron sus CGI de Perl del Archivo de Script de Matt. (lo cual no fue algo bueno, luego lo descubrieron). – Joe

2

La manipulación de cadenas, a menudo una gran parte del desarrollo web, es bastante dolorosa y propensa a errores en C, en parte debido a la falta de gestión de memoria automática. Tenga en cuenta que a menudo, el tiempo de ejecución del script no es el cuello de botella o puede eludirse mediante los mecanismos de almacenamiento en caché adecuados. En muchos casos, es una buena idea elegir un idioma que maximice la productividad del desarrollador en lugar de sacrificar innecesariamente el tiempo de desarrollo para obtener mejoras de rendimiento que pasarán desapercibidas para el usuario del sitio.

Este principio general, sin embargo, no se aplica completamente en su caso, ya que un motor de búsqueda podría beneficiarse de un código optimizado de bajo nivel. Sin embargo, esto no significa que tendrás que hacer todo en C: se sabe que el intérprete PHP es muy lento, pero como la mayoría de las funciones de la biblioteca se implementan en C, puedes salirte con la tuya. Recomiendo escribir la aplicación en el idioma de alto nivel que elija y solo volver a implementar las partes en C que se han identificado como cuellos de botella.

6

Seguridad, por un lado. Si escribe en C, debe tener mucho cuidado para asegurarse de que todo el manejo de las cadenas sea correcto para que no introduzca desbordamientos de búfer, etc. En cualquier lenguaje de scripting decente, alguien más ya lo hizo por usted. Es posible que tenga otros agujeros de seguridad, pero a menos que haya un error en el tiempo de ejecución o en un módulo de extensión, no tendrá un desbordamiento de búfer. Este beneficio no se limita a los lenguajes de scripting; Los lenguajes compilados como Java y C# también lo proporcionan, y es obtenible (aunque con frecuencia más difícil) en C++ con std::string y C con una buena biblioteca de cadenas.

Securitywise, Perl tiene otra característica útil que no se ve en muchos otros sistemas: modo "contaminación". Esto evita que ciegamente ingrese información del usuario a otros sistemas como parte de una consulta de base de datos, línea de comando, etc. Esto es una excelente ventaja al escribir scripts CGI, ya que su script morirá limpiamente antes de pasar la entrada de usuario no inspeccionada al shell para ejecución. El modo Taint no es perfecto, ya que el proceso de untar depende de que el programador haga las cosas correctamente, pero al menos ayuda a atrapar las rutas de código que no alcanzó.

Además, en este punto, Perl se ha utilizado durante mucho tiempo para la creación de scripts CGI, por lo que ya existe una gran cantidad de bibliotecas, marcos, etc. para facilitar la escritura de nuevas secuencias de comandos. Además CPAN tiene código para hacer casi cualquier cosa.

+1

Aunque estas son buenas características de Perl, rara vez me encuentro con cualquiera que haya elegido Perl por ellas. De hecho, muy pocas personas parecen usar el modo de contaminación o saber qué es un búfer (mucho menos qué desbordamiento haría). –

+1

Desearía que la gente lo considerara solo por esas razones; sin embargo, alguien me dio un guión de shell el mes pasado y quería que lo expusiera como un CGI. (¿Comprobación de manchas? ¿Qué es qué?) – Joe

+0

Sin embargo, puede envolver el script de shell con un envoltorio CGI de Perl. –

3

Además de las respuestas ya mencionadas, para las aplicaciones web básicas, la velocidad de transferencia de red es un cuello de botella más común que la elección del idioma. Por lo general, es más fácil escribir aplicaciones web en Perl que en C, por lo que una pequeña diferencia en la velocidad del tiempo de ejecución no justifica el esfuerzo adicional necesario para crear la aplicación. De hecho, C se usa a veces para ciertas partes de aplicaciones web muy intensivas en cómputo.

4

OK, el resto de las respuestas dieron muy buenas razones objetivas.Simplemente para la corrección, he aquí una evaluación subjetiva para darle un poco de color:

me escribió:

  • software de CGI en C puro (por dinero, profesionalmente). Esto incluyó la creación de toda la biblioteca CGI (que estaba en los días previos a que las bibliotecas CGI estuvieran disponibles).
  • bibliotecas de CGI en Perl
  • cosas de CGI en Perl usando CPAN.

En base a estas experiencias, la C pura dio la mayor satisfacción en cuanto a "Mira este logro técnico genial que hice". Especialmente cuando eso era en los días en que CGI era brillante y el HTML estático era el contenido principal en todas partes.

El Perl CGI roll-my-own fue mucho más fácil técnicamente que C one debido a todos los motivos objetivos enumerados en otras respuestas.

Y los proyectos de CPAN Perl fueron los únicos que proporcionaron un tiempo de respuesta de entrega bastante decente y me permitieron concentrarme en la construcción de la lógica comercial en lugar de la plomería.

19

En la época en que CGI se estaba haciendo popular, Perl era el lenguaje más fácil de usar. La gente podía recoger "bebé Perl" muy rápidamente, y como el programa era un archivo de texto, podían cargarlo fácilmente y pasarlo. Desde que Perl comenzó su vida como un lenguaje de administración de sistemas, muchos servidores ya lo tenían instalado. Cuando llegó el momento de hacer una secuencia de comandos CGI en algún servicio de alojamiento, Perl probablemente ya estaba allí. No solo eso, una secuencia de comandos de Perl es prácticamente la misma en cualquier plataforma, por lo que lo que escribió localmente probablemente funcionó exactamente igual en una máquina diferente.

Era más rápido programar para "programadores accidentales" en el gran esquema de cosas porque tenían menos que aprender antes de poder hacer un programa útil; Podrían comenzar sin nada y tener un programa Perl funcionando en una hora, incluso si solo lo estuvieran cargando. No tenían que preocuparse por todas las cosas que vienen con la escritura y la compilación de un programa en C, y luego transferirlo a otro host (que podría ser una plataforma diferente).

Perl tiene un punto de apoyo rápido, y todavía se ven los efectos de eso hoy. Si Perl tuviese que empezar de cero hoy, no creo que necesariamente vencería a cualquier otra cosa. PHP sin duda se ha hecho cargo de la multitud de inicio rápido y de gama baja (y para la mayoría de ellos, probablemente sea la herramienta correcta al principio).

No pasó nada que Perl tuviera muchas funciones de procesamiento de texto. Algunas personas hablan sobre CPAN, pero eso apenas existía cuando Perl comenzó a llamar la atención por la programación de CGI.

Sin embargo, Perl no es tan especial para la programación CGI como solía ser. Todavía hace todas las cosas geniales que siempre tiene, pero ahora varios otros idiomas se han puesto al día tanto en funcionalidad, disponibilidad y conciencia de la comunidad.

Empecé a programar cosas de CGI en 1994, y todavía veo cuán sorprendente y alucinante es la mayoría de los frameworks. Realmente desearía haber tenido Seaside en ese entonces porque nunca se sabe sobre todas las cosas estúpidas que te hacen otros frameworks. Cuánto mejor hubiera sido el mundo si todos hubiéramos aprendido Smalltalk en su lugar. :)

-2

En el momento CGI se inventó en los primeros días de la web, era la única manera de hacer cualquier tipo de procesamiento dinámico de solicitudes web, como responder a los formularios que se envían o hacer clic en un mapa de imagen.El software del servidor web en sí podría entregar solo contenido estático, por lo que se necesitaban programas externos para manejar las cosas interactivas.

Los primeros webmasters probablemente también eran administradores de sistemas que a menudo estaban bien versados ​​en Perl. Recuerdo que los primeros servidores httpd NCSA venían con programas CGI de muestra escritos en Perl, C y shell. Los scripts de shell se descartaron bastante rápido porque eran inseguros y no eran aptos para nada más que programas CGI realmente cortos. Los programas C funcionaron bien, pero Perl fue mucho más conveniente.

Mi conjetura es Perl despegó como el lenguaje estándar de facto para usar con CGI por varias razones:

  • Los administradores del sistema estaban familiarizados con ella.
  • Las bibliotecas rápidas y seguras se volvieron ampliamente disponibles; el módulo CGI.pm se envía de serie con Perl.
  • Perl ofrece un buen compromiso entre la velocidad y la facilidad de desarrollo.

No hay ninguna razón por la cual Perl tiene que ser utilizado; cualquier lenguaje que pueda funcionar con variables de entorno Unix es adecuado.

Dicho esto, CGI ha caído en desgracia debido a que es muy lento en relación con los idiomas que se ejecutan en el espacio de direcciones del servidor web, como PHP.

+4

El último párrafo es un poco dudoso, técnicamente hablando, aunque estoy seguro * usted * entiende que CGI es una interfaz y ** no ** un idioma, su escritura hace que sea fácil para otros malinterpretar y combinar los dos términos. Además, la lentitud es la latencia debido a la sobrecarga de inicio de proceso repetido.Los problemas de velocidad con CGI se han abordado de dos maneras principales: incorporando intérpretes de lenguaje dinámico en el servidor web (Apache + mod_php, mod_ruby o mod_perl) y utilizando aceleradores CGI como FastCGI o SpeedyCGI. Además, los scripts PHP se pueden (y se usan) con CGI para proporcionar contenido web. – daotoad

+1

PHP se ejecuta con frecuencia como CGI en proveedores de hosting –

0

creo que el beneficio para el uso de un lenguaje de script, es más la gente es mucho más productivo el uso de un lenguaje dinámico nivel más alto que se está utilizando C.

Mucha gente parece que preocuparse por la velocidad, pero en realidad, normalmente está bien ... y si se convierte en un problema, la mayoría de los lenguajes de scripting tienen un mecanismo de extensión donde puedes escribir módulos en C y aún así usarlos en el lenguaje de scripting de nivel superior (como XS en perl o pitones c-api)

Cuestiones relacionadas