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

13

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?

Bradford
fuente
66
Me parece que no consideraron un lenguaje / paquete con una jerarquía de objetos adecuada. No es necesario verificar si el control que está moviendo es Buttoncuando WebControlcontiene toda la información que necesita y todos los controles se derivan de ella.
Mateo leyó el
55
Sí, @Matthew - suena como alguien que realmente no conoce el polimorfismo
Nicole
8
También - Twitter puede ser popular, pero es no , ya que su sitio es una obra maestra de la ingeniería.
Nicole

Respuestas:

39

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.

back2dos
fuente
1
¿Cómo caen las funciones de primer orden en la misma categoría que el subtipo estructural y los tipos de datos algebraicos? Hace que parezca que los lenguajes dinámicos no tienen funciones de primer orden, lo que claramente no es cierto (Scheme, Common Lisp, Erlang, Smalltalk, ...).
Frank Shearar
21
+1 para "Parece que este tipo no sabe que el polimorfismo se puede lograr por otros medios que no sean escribir pato".
Nicole
1
@Frank Shearer: lo que quiero decir es que son compatibles con el mismo tipo de seguridad que cualquier otro valor. Hay varios lenguajes estrictamente escritos que admiten valores de función, pero no distinguen entre firmas.
back2dos
1
No estoy de acuerdo también, por eso estoy seleccionando esto como la respuesta.
Bradford
8

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).

rsenna
fuente
1
En segundo lugar, solo mira el desastre de JSP / STRUTS cuando intentaron hacer de Java un lenguaje web.
James Anderson
8

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 ...

Javier
fuente
2
Definir "excesivamente". A medida que los programas se vuelven cada vez más complejos, y su ciclo de vida útil y ciclos de mantenimiento aumentan, la probabilidad de que alguien que no sea el autor original deba depurar o modificar cualquier parte del código sigue creciendo. Cuando se encuentra en esa situación, generalmente está bajo el control, y cuanta más información haya disponible de inmediato sobre exactamente qué datos está tratando y qué puede hacer mejor. He depurado Delphi de otras personas y JavaScript de otras personas, y Delphi es mucho más fácil debido a la información detallada y de tipo.
Mason Wheeler
1
Solo una nota al margen: algo como TypeScript (JavaScript, con información de tipo estático) podría ser una forma directa de probar la teoría del OP. Mi corta exposición a la que ha sido bastante agradable - una vez al convertir algunos JavaScript para mecanografiado, lo que realmente me ayudó a encontrar que no había manera posible para un determinado método que se llama, y no produce un error .
Katana314
5

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.

Roger escaso
fuente
1
"Los compiladores prueban algunas cosas en tiempo de compilación: intente almacenar una cadena en una variable int y probablemente ladrará. En lenguajes dinámicos, muchas de las pruebas ocurren en tiempo de ejecución".: Es cierto, cuando uso un lenguaje dinámico sucede para escribir muchas pruebas que reemplazan la verificación de tipos. Utilizando un lenguaje estático, puedo hacer que mis pruebas se centren más en la lógica empresarial.
Giorgio
@Giorgio Interesante, rara vez tengo algún tipo de lógica de verificación en mis pruebas.
favor
@pllee: a veces no es directamente una lógica de verificación de tipo, pero las pruebas verifican algún comportamiento que un sistema de tipo estático habría aplicado de todos modos.
Giorgio
Bruce Eckel parece ser solo otra persona que ha pasado años tratando con lenguajes excesivamente detallados (Java, C ++, ...) y luego saltando al primer tren diferente (Python) que encuentra. Está pasando la mitad del artículo alabando la gran sintaxis de Python. No tiene nada que contribuir a este debate debido a la falta de conocimiento.
ziggystar
Pero si intenta almacenar una cadena en una variable int en un lenguaje dinámico, asegúrese de no notarlo hasta que ejecute / pruebe la aplicación y la vea en acción. Pero en la práctica del mundo real (más de 17 años de desarrollo) ¡Raramente veo esto como la causa principal de un error! ¡Nunca! Pero incluso si lo es, ¿lo notas y lo arreglas? ¿Cual es el problema? Es como si todo el argumento se basara en un caso marginal muy técnico. ¡No es un gran problema! Por otro lado, el beneficio de la tipificación dinámica es que el desarrollo es dramáticamente más rápido.
Manachi
2

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.

Guiman
fuente
El acoplamiento flojo es bueno. Pero no se requieren lenguajes dinámicos para lograrlo. Verá, la Web tiene que ver con el acoplamiento suelto realizado a través de HTTP, y la mayoría de los servidores web y navegadores están escritos en lenguajes estáticos. Los lenguajes dinámicos brillan en las aplicaciones de secuencias de comandos cuando necesita un código fácilmente modificable en tiempo de ejecución, sin invocar una gran cadena de herramientas.
9000
2

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.

Anillo de martin
fuente
1

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.

Lennart Regebro
fuente
Creo que vale la pena señalar que Scala es un poco especial porque usa inferencia de tipos y, por lo tanto, no pertenece a la misma categoría de escritura estática que Java.
Winston Ewert
1

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 ;-))

umlcat
fuente
0

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.

Nemanja Trifunovic
fuente