¿Por qué JavaScript y Python son tan populares, incluso para aplicaciones web a gran escala, a pesar de todo el odio por ser tipeado dinámicamente?

Esta pregunta lleva a la esencia del argumento: lenguajes tipados dinámicamente versus lenguajes estáticamente tipados, que regresa a un argumento que se originó al menos hace 40–50 años.

Sí, la gente estúpida siempre ha existido 🙂

La respuesta simple es ni es mejor ni peor.

Si alguien dice que uno es mejor que el otro, éste expresa una opinión personal, principalmente religiosa que práctica.

Si los lenguajes estáticamente escritos fueran realmente mejores que los dinámicos (u opuestos) no habría otro, ¿verdad? Pero ellos existen. Aún más, si hay un solo lenguaje de programación que sea perfecto y cubra todos los casos y patrones de uso posibles, no habría otros, ¿verdad? Pero aparecen nuevos lenguajes de programación y se hicieron populares todos los días. Entonces, ¿qué está mal? Obviamente el argumento en sí.

Así que ya sabes, hay un mundo para todo. Los idiomas escritos dinámicamente tienen un mejor uso en algunos casos, los idiomas escritos estáticamente son mejores en otros casos. Ambos existen juntos, y un buen programador debería ver los lenguajes de programación como herramientas: podría golpear un clavo con una piedra, pero probablemente el martillo sea mejor para eso. El martillo en sí mismo no es muy útil si quieres cortar un árbol.

Los codificadores podrían discutir entre sí, qué lenguaje de programación es mejor y qué estilo es mejor, porque los codificadores en general se asocian y dependen de un cierto lenguaje de programación y estilo de programación.

No los programadores, pensó.

Utilizan y combinan las mejores herramientas disponibles para lograr un objetivo más alto, teniendo en cuenta muchas limitaciones.

De nuevo, no hay una respuesta correcta sobre cuál es mejor. Todas las respuestas son incorrectas porque el argumento es incorrecto.

Y sí, JavaScript y Python son populares y crecen, porque satisfacen ciertos nichos mejor que cualquier otra alternativa. Ciertamente, no escribiría un controlador en tiempo real en ninguno de esos idiomas, debido a su sobrecarga y la imprevisibilidad de ejecución. Pero tampoco escribiría un procesamiento de texto grande o manipulación DOM en asm.

Cada herramienta es mejor en ciertas áreas y en cierto uso.

Cuando diseña un proyecto, incluso debe considerar problemas que no son técnicos en sí mismos, como las restricciones relacionadas con sus recursos (qué lenguaje de programación conocen, por ejemplo) o sus clientes, etc.

Por lo tanto, siempre que no discuta cuál es mejor (martillo o pala), no debe discutir ni entrar en argumentos sobre cuál es mejor: lenguajes dinámicos o estáticamente tipados, procedimientos u OOP o programación funcional, SOAP vs REST , Y así sucesivamente y así sucesivamente. Esas son herramientas. Aprenda a usarlos mejor, conozca sus ventajas y desventajas.

Soy una de esas personas que ensalzará las virtudes del tipeo estático, pero también uso lenguajes tipados dinámicamente. A veces para grandes proyectos. ¿Por qué habría de hacer eso?

Estoy trabajando en uno ahora que es muy grande. Tiene una parte que es un sitio web pequeño y público, otra parte que es un portal para usuarios registrados y otra parte que es una API para una aplicación móvil. El sistema es grande y tiene muchos datos en movimiento. ¿Por qué lo construí en django / Python entonces?

Bueno, solo lo construí en django. El pequeño sitio público se traduce a 8 idiomas y se actualiza a menudo, pero solo de forma pequeña entre las dos docenas de páginas. Es un candidato perfecto para django-cms, ya que hace que sea muy fácil para diferentes personas (traductores) administrar el contenido en varios idiomas en el CMS, publicar cambios de forma incremental, y dado que ese contenido se sirve principalmente desde el caché del servidor, esencialmente no tiene procesamiento y muy poco acceso a la base de datos, por lo que es bastante rápido para su audiencia.

El portal requiere un poco más de recursos, pero no mucho. Principalmente es para que las personas se registren y compren licencias para el servicio. Entonces, si bien puede haber un millón de miembros, es probable que solo haya unos pocos miles de usuarios conectados en un momento dado, y en su mayoría solo necesitarán acceso a sus propios datos de usuario. Todo está almacenado en una base de datos postgres, que se escalará verticalmente para manejar el volumen creciente con el tiempo, y no necesita ser particularmente rápido. Hay algunos procesos, en los que los usuarios pertenecen a grupos y podrán ver información sobre otros usuarios en sus grupos, pero con buenas claves externas que son bastante rápidas, ya que esperamos, como máximo, unos pocos miles de usuarios. en un grupo, con solo unas pocas docenas o menos como el caso más común. Entonces, nada demasiado extenuante aquí, nada que django / Python / postgres no pueda manejar. Esto también se traduce a 8 idiomas, pero estamos utilizando traducciones precompiladas de django en el portal ya que las etiquetas de los campos de formulario no cambian muy a menudo, y esas traducciones precompiladas son rápidas.

Luego está la aplicación. De aquí proviene el tráfico y el procesamiento reales. El tráfico esperado dentro de 2 años es del orden de decenas de millones de solicitudes por día, con horas pico de unos pocos millones de solicitudes por hora. Ay. Entonces, construí esa parte en php, en su propio servidor. Para ser más específico, es php en bruto, sin el desorden que hace que php apesta; solo escuche las solicitudes entrantes, trátelas y devuelva una respuesta. Para ser claros, odio el php como lenguaje, con la pasión de mil soles ardientes. Pero aquí es donde brilla php. Toda la API es solo un centenar de líneas de código, sin bibliotecas o marcos adicionales, sin clases o herencia u otro tipo de cruft agregado para ralentizar las cosas. Es increíblemente rápido. Las pruebas de carga sugieren que puede manejar fácilmente unos pocos millones de solicitudes por hora, por lo que creo que estará bien con unas pocas decenas de millones de solicitudes por día, especialmente una vez que comencemos a generar nuevos nodos basados ​​en el tráfico.

Tampoco utilicé postgres para la base de datos para esa parte. No porque no pueda manejar el tráfico, sino porque el tráfico es bastante específico. Esta parte debe distribuirse y escalar horizontalmente con el tráfico, por lo que necesitaba una base de datos que lo haga mejor que postgres, ya que postgres se escala mejor verticalmente que horizontalmente. Los datos tampoco son relacionales en este nivel, es esencialmente una colección de documentos de forma variada, codificados en un solo identificador. Además, nada del tráfico actualizará los registros existentes, en su lugar creará nuevos registros, lo que significa que no habrá colisión en la sincronización, y Mongo es bueno para capturar toneladas de nuevos registros y sincronizar en toda la red en segundo plano.

Así que ahora tengo un sistema muy pequeño y simple que se puede replicar en todo el mundo ejecutando solo mongo y php, que pueden usar geo-dns para transportar el tráfico al servidor más cercano. Esto recibe todo el tráfico de alta velocidad, almacena y agrega los datos importantes, y los pone a disposición de los usuarios del portal a través de una API simple. Mientras tanto, el portal django / postgres y el sitio público manejan los datos del usuario, las licencias, etc. sin ser estresados ​​por el tráfico masivo de la aplicación.

Por cierto, la aplicación es una aplicación Cordova multiplataforma escrita en iónico. Por lo tanto, la aplicación es principalmente JavaScript, que también se escribe dinámicamente. Pero dado que cada aplicación solo envía un mensaje a la vez, tampoco tiene que ser increíblemente rápido.

Así que aquí estoy, odiando los idiomas escritos dinámicamente mientras construimos simultáneamente un sistema muy grande y de alto tráfico en tres idiomas escritos dinámicamente. ¿Por qué? Porque esto no es religión, y uso la herramienta adecuada para el trabajo, independientemente de cómo me sienta acerca de esas herramientas.

EDITAR:

Para poner esto en una perspectiva completamente diferente, comencé un proyecto durante el fin de semana para convertir un garaje en una habitación. El primer paso es reemplazar las puertas del garaje con marcos de pared. Para ser claros, odio balancear un martillo sobre mi cabeza. Es una mierda, y nada sobre la construcción es más agotador. Por lo tanto, la mayoría de la gente diría “¡Usa tornillos, el taladro los hace fáciles de manejar!” Pero hay un problema. Los tornillos no tienen la misma resistencia al corte que los clavos de enmarcado. El problema es que la gente piensa que las paredes deben ser rígidas. Pero las paredes, especialmente las paredes exteriores, se flexionan, con el viento, los cambios de temperatura, etc. Si la unión entre dos pernos se flexiona y tiene tornillos que la sujetan, los tornillos ceden y se cortan la primera vez que la pared se flexiona más allá de la resistencia al corte del tornillo. Las uñas son flexibles. Si esa misma articulación es sostenida por las uñas, la uña tiene el margen de maniobra para extraer una pequeña cantidad, o deformarse para que coincida con un perno giratorio, sin perder su agarre en ambos lados de la articulación. Claro, después de algunas décadas de flexión estacional, las uñas pueden comenzar a salir o debilitarse, pero los tornillos se rompen la primera vez que se flexionan.

Así que aquí estoy, odiando tener que balancear un martillo sobre mi cabeza, mientras uso un martillo para clavar clavos porque es la herramienta adecuada para el trabajo, independientemente de lo que siento por ellos. Mientras tanto, django es una pistola de clavos neumática. 😉

La única razón por la que JavaScript es “exitoso” es porque es el único idioma admitido por todos los navegadores. Entonces, si te gusta la programación web del lado del cliente, no tienes otra opción. JS no es la única opción debido a sus méritos, sino por razones políticas. Durante años, Microsoft empujó sus lenguajes visual básico y JScript, pero solo trajeron dolores de cabeza a los desarrolladores debido a sus incompatibilidades con el JavaScript de Netscape. Más recientemente, Google creó Dart, pero sus intenciones de imponer una mejor alternativa a JS fracasaron por completo. ¿La razón? Falta de soporte por parte de otros navegadores.

La situación de Python es diferente. Se usa en la programación web, pero en el lado del servidor. Allí, las opciones son infinitas, pero aún así muchos desarrolladores y compañías lo eligen. ¿Por qué? Porque sus ventajas son mayores que sus debilidades.

Como lenguaje dinámico de secuencias de comandos, no puede competir en velocidad con ningún lenguaje de tipo estático. Pero compite con éxito en velocidad de desarrollo. Python es muy fácil de aprender, escribir y leer. Es muy flexible y expresivo y requiere mucho menos repetitivo y líneas de código para una tarea determinada. Viene con una gran cantidad de bibliotecas de soluciones preparadas para todo tipo de problemas y, finalmente, es muy divertido.

A menudo, su velocidad inferior no es un problema. Y cuando es así, los desarrolladores pueden solucionar un cuello de botella en particular mediante la implementación de algunos bits en C.

Es más o menos como comparar un Ferrari con un Honda Civic. Puedes decir que el primero es mucho más rápido. Concedido. También es mucho más caro, requiere más mantenimiento, los servicios son más caros, no tiene suficiente espacio para el equipaje, etc. El Civic en cambio, no es tan rápido, pero su velocidad es más que adecuada para el conductor promedio. En realidad, la mayoría de los conductores nunca superarían sus límites.

Tenga en cuenta que hoy en día, el éxito de una startup se basa en su velocidad de desarrollo. Ser el primero en el mercado es clave. Nadie quiere ser Pepsi. Todos quieren ser Coca Cola. El envío primero es crucial, incluso si su primer prototipo no es tan rápido como una versión altamente ajustada escrita en Java o C (eso habría requerido el triple de tiempo para escribir y probablemente un equipo más grande).

Los problemas de rendimiento se pueden solucionar más tarde. Pero llegar en segundo lugar al mercado es inaceptable. Es por eso que Google, Dropbox, Quora y muchos otros usan Python. Saben lo que están haciendo y no les importan los críticos en StackOverflow.

No son malas elecciones y, en muchos casos, uno de los idiomas de tipo dinámico es la opción “correcta” para una nueva aplicación. No existe el mejor idioma para todos los proyectos y, como todos los esfuerzos de ingeniería, la elección de herramientas (incluidos los idiomas) será un compromiso. JavaScript permite utilizar el mismo lenguaje en el front-end y el back-end, lo que _puede ser un gran impulso para la productividad, ya que es casi seguro que tendrá que lidiar con JavaScript en su front-end. No tener que lidiar con dos marcos de prueba y tener a todos sus ingenieros capaces de depurar y trabajar en todo el código (incluso si los chicos de back-end no quieren tocar DOM y CSS pueden ayudar) es un gran problema.

Ahora, los lenguajes de tipo dinámico a largo plazo son (IMO) más difíciles de mantener con el tiempo que un lenguaje de tipo estático, especialmente Java. La razón por la que esto no es un problema mayor es que la mayoría de los nuevos esfuerzos deben “fallar rápidamente” si no van a ser un éxito, la inversión inicial en un lenguaje más detallado y estático no vale la pena el desarrollo superior inicial costo para llegar al primer lanzamiento del producto. Además, si su producto es realmente exitoso, el esfuerzo adicional para hacer que su código sea mantenible incluso en algo como Python, Ruby, JavaScript, etc. no es insuperable. Facebook ha estado haciendo que PHP haga cosas que la mayoría de las tiendas de desarrollo no creían que fuera posible desde hace mucho tiempo.

JavaScript y Python tienen un gran número de bibliotecas disponibles, y ambos se pueden usar para crear servidores muy eficientes (las operaciones asincrónicas le brindan la mejor arquitectura de servidor, y ese es el método de operación predeterminado en JavaScript; puede usar extensiones de Python para el mismo beneficio).

Debido a que puede hacer mucho simplemente instalando la biblioteca adecuada, ambas son formas populares de iniciar proyectos. Y los proyectos a menudo comienzan pequeños y crecen grandes con el tiempo.

¿Es aconsejable crear servicios complejos en lenguajes dinámicos sin tipo? Voy a decir que no, no lo es.

Es por eso que ha habido un gran aumento en la popularidad de TypeScript y Flow, que agregan anotaciones de tipo estático a JavaScript, y lenguajes transpilados como Elm, que son nuevos lenguajes que incluyen escritura estática pero crean JavaScript como salida.

Si bien soy un gran admirador de las pruebas unitarias, creo que el 80% de las pruebas escritas para lenguajes dinámicos en realidad existen debido a la falta de seguridad de tipos. Estoy usando TypeScript en este momento, y solo pruebo la lógica lo suficientemente compleja como para realmente necesitarla. Y, sin embargo, todavía refactorizo ​​con confianza los principales fragmentos de código, sabiendo que TypeScript en sí mismo detectará cualquier conexión deficiente entre las diferentes partes del código.

Algunas de las refactorizaciones han sido tan graves que dudo que las pruebas unitarias existentes me hubieran protegido: el equivalente a mover el código del cliente al servidor, cambiando la forma en que la aplicación funciona internamente. Entonces, en un entorno de tipo dinámico, también habría necesitado reescribir las pruebas unitarias.

Y no subestimes el otro extremo: puedo cambiar el nombre de un miembro sin preocuparme por romper el código. Las herramientas de TypeScript solo saben dónde se usa el nombre del miembro.

He escuchado cosas aún más impresionantes sobre Elm, como una base de código de línea de 35,000 que nunca arrojó un error de tiempo de ejecución, después de estar en vivo durante más de un año.

Escribir pequeñas herramientas y aplicaciones con un lenguaje dinámico es rápido y fácil. Reunir las herramientas de TypeScript requiere cierto esfuerzo, aunque lo están facilitando. Si está utilizando WebPack o Babel de todos modos, es trivial agregarlo. Y los beneficios de escribir código (con autocompletado preciso) y de mantener su código correcto son simplemente sorprendentes.

Entonces, sí, creo que todas las bases de código grandes se beneficiarían del uso de tipos. Con la madurez de TypeScript, incluso lo considero una mejor práctica de 2016.

La gente los encuentra fáciles. Recuerdo que primero usé TCL / TK, fue tan fácil, simplemente funcionó e hizo lo que se le dijo.

Sin embargo, a medida que pasa el tiempo y comienzas a trabajar en proyectos más grandes, se vuelven menos fáciles, y aunque tengo mucho cariño por TCL / TK, nunca lo volvería a usar.

Supongo que dudo en decir que Python es una opción * terrible *, solo creo que hay mejores opciones. No es como si Python costara $ 10 y Java cuesta $ 9999 + impuestos, ambos son gratuitos, por lo que, aunque Python podría no ser una elección terrible (JavaScript es, sin embargo), es solo que no vale la pena molestarse mientras haya mejores alternativas.

Creo que, como regla general, los lenguajes dinámicos son malas elecciones para proyectos grandes, pero eso no quiere decir que sea un error elegir uno. La clave para comenzar un sitio como Quora es, en algún momento, ganar dinero. La calidad del código no importa, la facilidad de mantenimiento no importa, lo único que importa es que hagas algo lo suficientemente bueno como para atraer VC y en algún momento atraer suficientes apostadores para mirar tus anuncios, luego con suerte venderás todo el kaboodle a Google o similar.

Quora no es en realidad una aplicación empresarial, es un sitio web, es un sitio web que falla con frecuencia, pero no importa, porque es solo un sitio web. El software de grado empresarial tiene más que ver con la confiabilidad, es por eso que tienes COBOL de 40 años ejecutándose en un mainframe en los bancos, porque la confiabilidad es crítica , con Quora no lo es.

Estamos en una industria impulsada por la moda, nos guste o no, los idiomas se elegirán porque son geniales , no por ningún tipo de lógica, realmente lo harán.

Realmente no creo que haya más razones por las que JavaScript sea popular que por qué Katy Perry es popular, lo escuchan, les gusta, lo eligen. Eso es. Se apegan emocionalmente a él, y alentarán a otros a apegarse también, se sentirán menospreciados cuando se les critique.

Creo que Python y JavaScript son populares porque la gente los aprende, los encuentra fáciles, se quedan con ellos. Sé que lo hice, escribí Python durante 15 años, y solo en los últimos 5 me di cuenta de que, en realidad, no fue tan genial.

Sin embargo, hizo el trabajo, y eso es lo que va a importar a las personas que crean sitios web como este.

Hay grandes ventajas con los lenguajes sin tipo / blob, así que supongo que hay diferentes escuelas de pensamiento aquí.

Simplemente no hay alternativa a Javascript en la interfaz. Puede usar Typecript (etc.), pero de todos modos eso se compila a Javascript.

Hay varias alternativas a Python en el backend, y Python tampoco es el lenguaje de backend más popular. PHP es. Eso también se escribe dinámicamente.

Érase una vez, los arquitectos diseñaron edificios con acero y hormigón. Pero cuando se volvieron codiciosos y construyeron demasiados edificios demasiado rápido, los malos diseños colapsaron bajo cientos de toneladas de material pesado, aplastando todos los bytes pobres en su interior.

Por lo tanto, se contrataron arquitectos nuevos, más jóvenes y con menos experiencia, y prometieron resolver este problema utilizando solo material débil, débil y liviano que los constructores endebles, débiles y fáciles de controlar podrían construir muy rápidamente. Claro, los edificios todavía se cayeron, de hecho siempre se cayeron, todo el tiempo, pero no se aplastó mucho. Las personas y sus bytes solo llevaban paraguas donde quiera que fueran.

Un día, un lobo grande y malo vino a la ciudad …