Lenguajes dinámicos vs estáticos para sitios web [cerrado]

Esta declaración sugiere que los idiomas tipados estáticamente no son ideales para sitios web:

Contrastaré eso con la construcción de un sitio web Al renderizar páginas web, a menudo tiene muchos componentes interactuando en una página web. Tiene botones aquí y pequeños widgets por allá y hay docenas de ellos en una página web, así como posiblemente docenas o cientos de páginas web en su sitio web que son dinámicas. Con un sistema con una superficie realmente grande como esa, usar un lenguaje estáticamente tipado es bastante inflexible. Probablemente me resultaría doloroso programar en Scala y renderizar una página web con él, cuando quiera presionar interactivamente los botones y demás. Si todo el sistema tiene que ser coherente, como todo el sistema tiene que escribir check solo para poder mover un botón, creo que puede ser realmente inflexible.

^{Fuente: http://www.infoq.com/interviews/kallen-scala-twitter}

¿Es esto correcto? ¿Por qué o por qué no?

Estoy totalmente en desacuerdo. A medida que los sistemas crecen, los lenguajes de tipo estático aseguran robustez a nivel de componente y, por lo tanto, flexibilidad a nivel de sistema.

Además, el ejemplo dado por el autor realmente no tiene ningún sentido. Parece más bien como si este tipo no supiera que el polimorfismo se puede lograr por otros medios que no sean escribir patos.

Hay varias personas que afirman que los lenguajes dinámicos son superiores, pero eso generalmente se basa en su falta de experiencia con 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 la presentación , y ahí es donde cree que Scala no sería una buena opción ...

Dicho esto, 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 de tipo estático en la capa de presentación puede ser un gran obstáculo. El contenido debe cambiarse constantemente, con mucha más frecuencia que los requisitos comerciales. Y, por lo general, esto debe hacerlo un equipo distinto (los desarrolladores "front-end"). Normalmente saben mucho sobre HTML, JavaScript, estándares web, CSS, pero no mucho sobre lenguajes del lado del servidor como Java y C #. También asumen que cualquier tipo de cambio en una plantilla está disponible de inmediato ; no están acostumbrados a compilar y escribir errores. Y tienen razón: los lenguajes estáticamente tipados son muy buenos para requisitos difíciles y complejos, como el acceso a datos y las reglas comerciales, pero no tan buenos para el desarrollo de interfaces.

Ese es, de hecho, 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 chicos del lado del servidor son libres de usar un lenguaje serio y estático escrito 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 usarse para el desarrollo de presentaciones, por lo que tal vez podría usarse con éxito como un lenguaje de plantilla. Y si también pudiera combinarse con 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 tipo Groovy (dinámico), que no es una buena señal.

En resumen: el problema con Scala está mucho más relacionado con el hecho de que está compilado. De hecho, su mecanismo de inferencia de tipo casi te hace olvidar que también está tipado estáticamente.

(Y perdón por mi inglés. Avíseme si algo no está claro, intentaré arreglarlo).

Creo que el texto (y la mayoría de las respuestas) están mezclando lenguajes estáticamente escritos y lenguajes excesivamente detallados . 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 detallados y de tipo estático: Go, Haskell, Scala, Rust ...

Te animo a leer Bruce Tyck Strong Typing vs. Strong Testing . Su argumento principal es que la calidad del software se reduce a pruebas. Puedes probar de muchas maneras diferentes. Los compiladores prueban algunas cosas en el momento de la compilación: intente almacenar una cadena en una variable int y probablemente le ladrará. En lenguajes dinámicos, muchas de las pruebas ocurren en tiempo de ejecución. En última instancia, no importa cuándo se realicen las pruebas. Solo tiene que suceder. A la hora de ganar no compilando en lenguajes dinámicos se pierden las pruebas en tiempo de ejecución. Pruebas todo de forma robusta, ¿verdad?

Dado eso, la preferencia por los lenguajes compilados con sistemas de tipo rígido frente a los lenguajes dinámicos es solo eso: una preferencia. Como boxeadores versus calzoncillos o tangas versus bragas francesas. No hay una respuesta correcta o incorrecta. Úselos con la actitud correcta y solo hay algo increíble.

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

Los lenguajes tipados estáticamente son más robustos y seguros que los tipados dinámicamente, pero cuando comienzas a adaptar el código para actuar de una manera que no debe ser y lo necesitas rápido, las soluciones se ven complejas y rígidas.

Entonces, si tiene el cambio para fusionar tecnologías, recomendaría crear un núcleo en un lenguaje estáticamente tipado (el núcleo no cambia mucho) y usar dinámicamente para la interacción del usuario.

Creo que el autor de esta publicación no ha investigado al propio Scala. Si bien 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 bastante diferente de lo que normalmente piensas cuando escuchas eso. Scala permite escribir pato también como una versión de tipo seguro de parches de mono (a través de conversiones implícitas). Eso hace que las bibliotecas de programación sean un poco más complejas porque tendrá que pensar en los 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 donde simplemente no lo usa. Correcto. Personalmente, creo que el marco web de elevación no tiene que esconderse de Ruby on Rails o similar. Echa un vistazo a los ejemplos de código aquí o aquíy decide por ti mismo. Me desarrollé en ascensor durante bastante 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 que 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á la escritura estática cuando hable con el hardware, ya que todo lo demás la escritura dinámica tiene los mismos inconvenientes y beneficios, sin importar lo que haga, realmente, y lo mejor depende del gusto y los problemas específicos de cada proyecto.

Respuesta rápida práctica: depende del tamaño y la complejidad del tamaño de la web. Pequeño sitio web, programa dinámico. lang., sitio web complejo grande, programa estático. lang.

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

Trabajé con PHP varias veces y, tarde o temprano, tuvimos que agregar mucho código que verifica los tipos de los datos dados, que está implícito en un programa de tipo estático. lang.

Mecanografió Lagn. también ayuda al uso de IDE (s), que requiere mucha verificación de tipo.

(traído por su vecino programador y diseñador del compilador ;-))

Estoy de acuerdo Cuando miro la mayoría de los códigos C # de front-end web, hay muchas transmisiones de cadenas y datos de serialización a cadenas. Básicamente, HTTP como protocolo es una buena opción para lenguajes dinámicos.