interpreted-language - guia - qgis manual

¿Por qué se interpretan tantos idiomas web en lugar de compilados? (15)

¿Por qué los lenguajes como C no se utilizan para el desarrollo web? ¿Seguramente la velocidad aumenta desde que se compilará sería útil para sitios de carga pesada?

Los lenguajes de script son la única opción para el desarrollo web hace mucho tiempo. Ahora tenemos otras alternativas (Java, .NET ...) por lo que la situación no es tan mala.

C como una plataforma no fue muy exitosa para el desarrollo web ya que es difícil construir un módulo que pueda cargarse y ejecutarse desde el servidor web / de aplicaciones, pero uno de los primeros marcos para construir aplicaciones web dinámicas fue módulos ISAPI para IIS de Microsoft que principalmente desarrollado en C ++ y donde compilado.

C se usó para aplicaciones web desde el principio; escribí varios scripts CGI en él.

Con el tiempo, sin embargo, los lenguajes más productivos (C # y Java, por ejemplo, pero no exclusivamente, por supuesto) han demostrado ser "lo suficientemente eficientes" para las aplicaciones web. Tenga en cuenta que tanto C # como Java se compilan en código intermedio y luego se compilan JIT, logrando un rendimiento de código nativo "aproximado". ¿Por qué querríamos usar C en su lugar?

Incluso los lenguajes tradicionalmente "genuinamente interpretados" como PHP a menudo se compilan en el momento de la ejecución en estos días, hasta donde yo sé. (Mi conocimiento de PHP en particular es de segunda mano. Tal vez siempre se haya compilado ... Y del mismo modo, estoy seguro de que hay plataformas web que todavía se interpretan).

Es principalmente porque es rápido y simple cambiarlos sobre la marcha. Los lenguajes compilados requieren un entorno de desarrollo que debe coincidir con el servidor. Con un script puede usar una herramienta ftp y editar el texto directamente y luego guardarlo. Esta capacidad de hacer esto desde cualquier computadora de cualquier sistema operativo o tipo ha salvado mi vida (o la vida de mis sitios web) muchas veces.

Gran pregunta La razón se debe básicamente a la evolución de la web. Piénselo en pasos:

1) Texto básico en la ''red'' -> 2) Se agregó una ''marca'' al texto -> 3) se forman la etiqueta "centro" y la "marquesina". que progreso !!! -> 4) scripting en el cliente !!! 5) -> hmm ... ¡secuencias de comandos en el servidor!

Si bien formé esta respuesta para ser un poco tonto, es realmente cierto. El interenet, y muy especialmente la "web", ha sido un proceso evolutivo sorprendente. Realmente, los requisitos para los lenguajes más potentes (y los lenguajes más performantes) solo han sido algo más reciente.

Además, mira las herramientas. Hice mi PHP en el bloc de notas (y algunas otras aplicaciones simples). Cuando estaba haciendo el desarrollo web por primera vez, mi computadora no tenía suficiente espacio en el disco duro para admitir Visual Studio 2008 :)

Side Point Sin embargo: Hubo aplicaciones ".exe" (creo que las publicaciones de " SunBiz " en un "exe") y algunas aplicaciones de cgi compiladas durante un tiempo, pero fueron mucho menos.

Intenta hacer un análisis / manipulación de cadenas en C an en Perl / PHP y sabrás.

Por cierto, ¿por qué tantas personas afirman que el rendimiento ya no es un problema? Puede que no sea un problema para pequeñas páginas web / blogs, pero las aplicaciones web a gran escala aún deben ser ajustadas para el rendimiento (cpu / network / memory), sin importar si están escritas en java, php o ruby.

La mayoría de las aplicaciones web hablan con una base de datos. La abrumadora mayoría de estas aplicaciones dedican casi todo su tiempo a comunicarse con la base de datos. Por lo tanto, para cualquier solicitud dada a la aplicación, hay una pequeña cantidad de procesamiento en el servidor de aplicaciones y luego una larga pausa mientras se espera la base de datos. Dado que un porcentaje tan pequeño del tiempo de cualquier solicitud se gasta en el código real del servidor de aplicaciones, la optimización de dicho código escribiéndolo en C / C ++ solo obtendrá una pequeña mejora, probablemente no notable, en el tiempo de respuesta.

Entonces, en lugar de enfocarse en C / C ++ y guardar hasta el último ciclo de la CPU, tiene más sentido preocuparse por la productividad del desarrollador. Los desarrolladores son muy caros. Y, por lo general, son mucho más productivos en un lenguaje de scripting o incluso en Java que en C / C ++.

Por supuesto, hay excepciones a esto. Y si algunas solicitudes a su aplicación son intensivas en CPU o memoria, deberían escribirse en C / C ++. Pero, para el resto de su aplicación, es mejor que se concentre en la optimización de sus algoritmos, estructuras de datos, comunicación con la base de datos y la productividad del desarrollador que en la optimización de su idioma.

Los lenguajes de scripts tienen las siguientes ventajas sobre C:

Mucho más rápido desarrollo
Hoy, todos los relevantes para esta pregunta se compilan en tiempo de ejecución. En algunos casos, esto puede hacer que sean más rápidos que un programa C equivalente, por lo que el rendimiento ya no es un problema.
El mantenimiento cuesta mucho menos
Puede desarrollar usando métodos ágiles (como pruebas unitarias) que resultan en códigos mucho mejores. Sí, puedes hacer eso en C, también, pero es mucho más esfuerzo.
Cuando estás haciendo desarrollo web, tienes marcos enormes que hacen la mayor parte del trabajo por ti.
Están mucho más abiertos al cambio. Una nueva característica puede tardar tanto como unos minutos en implementarse.
Si algo no funciona, puede iniciar sesión en su servidor, iniciar un editor de texto en la consola y solucionar el problema, a veces sin tener que reiniciar.

Entonces, en lugar de enfocarse en C / C ++ y guardar hasta el último ciclo de la CPU, tiene más sentido preocuparse por la productividad del desarrollador. Los desarrolladores son muy caros. Y, por lo general, son mucho más productivos en un lenguaje de scripting o incluso en Java que en C / C ++.

Oh, muy, muy cierto. Si el uso de un lenguaje más dinámico afeita a una semana de desarrollador fuera del horario, esa semana de tiempo de programador que no tiene que pagar le comprará un servidor adicional. Tal vez incluso varios servidores, si te gustan muchos baratos en lugar de unas pocas bestias enormes.

Para la mayor parte del mundo (es decir, no Google / Amazon / eBay / etc.), un servidor adicional compensará con creces cualquier pérdida de rendimiento en bruto que pueda resultar de la elección de idioma.

Al menos inicialmente, gran parte del trabajo realizado por código de back-end (que supongo es de lo que estás hablando) estaba orientado al texto. Construyeron páginas directamente desde cero o, por ejemplo, combinando datos de una base de datos con una plantilla.

C no es ... siempre adecuado para el procesamiento de texto. Las cadenas de caracteres C son muy básicas, y aunque el procesamiento de texto en C puede ejecutarse rápidamente, a menudo lleva un poco más de tiempo desarrollarlo y requiere habilidades algo más profundas para hacerlo bien, que los lenguajes que lo ayudan un poco más.

Aquí están mis pensamientos sobre el tema:

Las aplicaciones CGI originales requerían un proceso de sistema operativo propio, que por supuesto es un recurso de recursos. Intentar agrupar todo en un solo proceso tampoco es fácil con el código nativo, ya que si algo sale mal en una aplicación, podría derribar fácilmente todo el servidor. Estas cosas son mucho más fáciles de manejar con un intérprete o una máquina virtual. Por supuesto, puede hacer lo mismo con el código nativo, pero supongo que sería mucho más difícil implementar el marco. Al final, terminarás implementando algo similar a un intérprete o una máquina virtual.
Los idiomas interpretados son portátiles en todos los sistemas operativos.
Por supuesto, el gran beneficio es el impulso productivo que obtienes al usar un lenguaje moderno.
El rendimiento es, por supuesto, importante. Sin embargo, los idiomas interpretados o de VM son cada vez mejores a este respecto (con tecnologías como la compilación de JIT) y se están acercando al rendimiento del código nativo. Además, no es justo comparar solo el tiempo pasado durante el proceso de ejecución. Necesita medir toda la secuencia: recepción de solicitud del servidor, delegación en la aplicación adecuada, ejecución, devolución de resultados al servidor. ¿Sería una aplicación nativa más rápida en todos estos?

Mi empresa usa C ++ (una extensión ISAPI) para nuestra aplicación web. Casi todo se hace en los binarios compilados. También utilizamos un motor de JavaScript para las partes del sistema que requieren secuencias de comandos (sí, JavaScript del lado del servidor). La razón que se cita para este diseño es la velocidad, pero la edad también es un factor ... esta es una antigua base de código. Además, distribuimos nuestro producto a algunos de nuestros clientes para que se alojen ellos mismos, por lo que compilarlo protege nuestro código fuente (muchos idiomas interpretados son trivialmente descompilables, o en el caso de PHP y Perl, nunca compilados en absoluto).

Muchas de las características extremadamente útiles de los lenguajes dinámicos, como la introspección y funciones como eval (), ¿son realmente difíciles / imposibles? para implementar en lenguajes que compilan a código nativo.

Dicho esto, la mayoría de los lenguajes de "secuencias de comandos" compilan (sobre la marcha) algún tipo de código intermedio que luego se interpreta (Python, Ruby, Perl) o incluso JIT compilado en código nativo (JSP, .NET)

Otra buena razón es que en un gran servidor la velocidad de ejecución no es tanto un problema como la velocidad de conexión de todos modos. La mayor parte del tiempo se gasta en enviar y recibir datos, no en números crujientes. Y, de hecho, en ciertos servicios web que hacen muchos cálculos, el hard crunching probablemente se ejecute como un programa compilado.

Además, los idiomas interpretados no necesitan compilación (lo que en un proyecto grande puede llevar tiempo), por lo que es más adecuado para el desarrollo generalmente ágil de soluciones web.

Vale la pena señalar que la mayoría de los lenguajes de scripting (Python, Ruby, etc.) se conectan fácilmente, casi trivialmente, a C. (Acabo de escribir algunas extensiones C para un programa de Python, y me impresionó lo fácil que era). Si un sitio web / aplicación web tiene algunos cuellos de botella debido al uso de un lenguaje de script "lento", uno normalmente puede escribir las secciones de rendimiento crítico en un lenguaje más rápido como C. De hecho, eso es lo que aplicaciones grandes como la búsqueda de Google, Facebook , etc., lo hacen: escriben la interfaz en un lenguaje de scripting y hacen el trabajo pesado con otros lenguajes como C.

Debido a que la industria sufre de un engaño masivo que la velocidad de ejecución no importa (como lo demuestra la respuesta aceptada).

Creo que la verdadera razón es que los lenguajes interpretados son más fáciles de usar si usa un marco existente y hacen que parezca fácil y divertido trabajar en una aplicación web.

Hay muchos, muchos casos en los que realmente necesita realizar operaciones de cifrado de números en aplicaciones web, pero los desarrolladores terminan no haciéndolo (porque son caros) y / o delegan la tarea en un servidor externo: el servidor de la base de datos o algunos otro servidor.

Esto se puede ver en la reciente proliferación de arquitecturas llamadas "micro servicio".