Lenguajes dinámicos frente a tipos estáticos para sitios web [cerrado]

Estoy totalmente en desacuerdo A medida que los sistemas crecen, los lenguajes tipificados estáticamente aseguran la solidez a nivel de los componentes y, por lo tanto, la flexibilidad a nivel del sistema.

Además, el ejemplo dado por el autor realmente no tiene ningún sentido. Parece como si este tipo no supiera que el polimorfismo se puede lograr de otra manera que no sea la tipificación de pato.

Hay una cantidad de personas que dicen que los lenguajes dinámicos son superiores, pero eso generalmente se basa en su falta de experiencia con los sistemas de tipo expresivo que, por ejemplo, admiten subtipos estructurales, tipos de datos algebraicos y funciones de primer orden.

En primer lugar, tenga en cuenta que el autor de la declaración anterior está hablando sobre el desarrollo de sitios web. Así que está preocupado por el desarrollo de presentación , y ahí es donde cree que Scala no sería una buena opción ...

Habiendo dicho eso, tengo una buena experiencia con el desarrollo web. He trabajado durante al menos 8 años exclusivamente con él, 5 de ellos en agencias digitales.

Y, sí, en mi experiencia, un lenguaje compilado tipificado estáticamente en la capa puede ser un gran obstáculo. El contenido debe cambiarse constantemente, mucho más a menudo que los requisitos empresariales. Y generalmente esto debe ser realizado por un equipo distinto (los desarrolladores "front-end"). Normalmente saben mucho sobre HTML, JavaScript, estándares web, CSS, pero no sobre lenguajes de servidor como Java y C #. También asumen que cualquier tipo de cambio en una plantilla está inmediatamente disponible; No se utilizan para compilar y escribir errores. Y tienen razón: los idiomas escritos de manera estática son muy buenos para los requisitos complejos y difíciles, como el acceso a datos y las reglas comerciales, pero no tan buenos para el desarrollo de interfaces.

De hecho, es uno de los principales beneficios de usar un lenguaje de plantilla especializado e interpretado como Velocity . Su facilidad de uso, potencia y flexibilidad son adecuadas para los desarrolladores de la capa de presentación. Y luego los usuarios del lado del servidor son libres de usar un lenguaje serio y estático en cualquier otro lugar ...

Sin embargo, también estoy de acuerdo en que Scala es algo diferente. Al ser al mismo tiempo mucho menos detallado y mucho más expresivo que Java, creo que podría ser utilizado para el desarrollo de presentaciones, por lo que tal vez podría usarse con éxito como lenguaje de plantilla. Y si también podría combinarse en un marco como Play (que compila el sitio web automáticamente después de cada cambio), podría ser un ganador EN MI HUMILDE OPINIÓN. Aún así, incluso Play ha optado por un lenguaje de plantilla (dinámico) similar a Groovy, que no es una buena señal.

Para resumir: el problema con Scala está mucho más relacionado con el hecho de que se compila. De hecho, su mecanismo de inferencia de tipos hace que casi se olvide de que también se escribe de forma estática.

(Y lo siento por mi inglés. Déjame saber si algo no está claro, intentaré arreglarlo)

Creo que el texto (y la mayoría de las respuestas) están mezclando lenguajes estáticamente tipificados y excesivamente verbosos . Por supuesto, la intersección es muy grande (especialmente cuando se consideran solo los idiomas más comunes); Pero hay algunos ejemplos interesantes de lenguajes no verbosos y estáticos: Go, Haskell, Scala, Rust ...

Le recomiendo que lea Strong Typing vs. Strong Testing de Bruce Eckel . El principal argumento es que la calidad del software se reduce a las pruebas. Puedes probar de muchas maneras diferentes. Los compiladores prueban algunas cosas en tiempo de compilación: intenta almacenar una cadena en una variable int y es probable que te ladre. En lenguajes dinámicos, muchas de las pruebas ocurren en tiempo de ejecución. En última instancia, no importa cuando se realiza la prueba. Solo tiene que pasar. La hora en que no gana compilando en lenguajes dinámicos se pierde la prueba en tiempo de ejecución. Lo pruebas todo con firmeza, ¿verdad?

Dado que, una preferencia por lenguajes compilados con sistemas de tipo rígido en lugar de lenguajes dinámicos es solo eso: una preferencia. Algo así como los boxeadores contra los calzoncillos o las correas frente a las bragas francesas. No hay una respuesta correcta o incorrecta. Llévelos con la actitud correcta y solo hay impresionantes.

Estoy de acuerdo con eso en la mayoría de los casos si, porque admitámoslo, cuando tratas con clientes en una plataforma web, la flexibilidad es una necesidad.

Los lenguajes tipificados estáticamente son más robustos y seguros que los tipificados dinámicamente, pero cuando comienzas a adaptar el código para que actúe de una manera que no debía ser y lo necesitas rápido, las soluciones parecen complejas y rígidas. p>

Por lo tanto, si tiene el cambio para combinar tecnologías, recomendaría crear un núcleo en un lenguaje estático (el núcleo no cambia mucho) y utilizarlo dinámicamente para la interacción del usuario.

Creo que el autor de este post no ha investigado al propio Scala. Aunque estoy de acuerdo en que Java y C # tienen limitaciones y son un poco inflexibles para el desarrollo web, Scala es un lenguaje de tipo estático que es muy diferente de lo que normalmente se piensa cuando se escucha eso. Scala permite la tipificación de pato y también una versión segura de tipo de parches de mono (mediante conversiones implícitas). Eso hace que las bibliotecas de programación sean un poco más complejas porque tendrá que pensar en tipos, pero si solo usa una biblioteca como Lift, se parece mucho a un lenguaje dinámico, excepto que el compilador le informará sobre errores obvios en los que simplemente no lo usa. Correcto. Personalmente, creo que el marco web de lift no tiene que esconderse del rubí sobre rieles o similar. Eche un vistazo a los ejemplos de código aquí o aquí y decide por ti mismo. Me desarrollé bastante durante un tiempo y nunca tuve una situación en la que tuve un error de tipo y aunque "Ah, hombre, si esto fuera dinámico, funcionaría" ... porque si fuera dinámico, simplemente no me habría dicho eso. hubo un error hasta que se bloqueó durante el tiempo de ejecución.

Personalmente creo que lo que dicen es cierto para cualquier sistema, no solo para los sitios web. Necesitará escritura estática cuando hable con el hardware, ya que todo lo demás, la tipografía dinámica tiene los mismos inconvenientes y beneficios, independientemente de lo que haga, y lo mejor depende del gusto y los problemas específicos de cada proyecto.

Respuesta rápida práctica: Depende del tamaño y complejidad del tamaño de la web. Pequeño sitio web, programa dinámico. lang., gran sitio complejo, estática progr. lang.

Respuesta aburrida extendida: Muchos desarrolladores insisten en que un sitio web debe realizarse con un programa dinámico. langr pero la verdad es que, eventualmente, las herramientas de desarrollo web tienden a usar o emular lenguajes de tipo estático.

Tuve que trabajar con PHP varias veces y, tarde o temprano, tuvimos que agregar una gran cantidad de código que verifica los tipos de datos dados, eso está implícito en un programa tipográfico estático. lang.

Lagn mecanografiado. También ayuda el uso de I.D.E. (s), que requiere una gran cantidad de verificación de tipo.

(presentado por el progenitor vecino. & compilador del diseñador ;-))

Estoy de acuerdo. Cuando observo la mayoría del código de C # de front-end web, hay una gran cantidad de conversión de cadenas y datos de serialización a cadenas. Básicamente, HTTP como protocolo es un buen ajuste para lenguajes dinámicos.