¿Qué argumentos hay a favor del tipeo débil?

Esto surgió en una discusión con un amigo, y me encontré en apuros para pensar en algún buen argumento. ¿Qué beneficios confieren los tipos débiles?

El problema con este tipo de discusión es simplemente que los términos "mecanografía débil" y "mecanografía fuerte" no están definidos, a diferencia de, por ejemplo, los términos "mecanografía estática", "mecanografía dinámica", "mecanografía explícita", "mecanografía implícita", " tipificación de pato "," tipificación estructural "o" tipificación nominal ". Diablos, incluso los términos "mecanografía manifiesta" y "mecanografía latente", que todavía son áreas abiertas de investigación y discusión, probablemente estén mejor definidos.

Por lo tanto, hasta que su amigo proporcione una definición del término "mecanografía débil" que sea lo suficientemente estable como para servir como base de una discusión, ni siquiera tiene sentido responder esta pregunta.

Desafortunadamente, aparte de la respuesta de Nick , ninguno de los que respondieron se molestó en proporcionar su definición tampoco, y puede ver la confusión que genera en algunos de los comentarios. Es difícil saberlo, ya que en realidad nadie proporciona sus definiciones, pero creo que cuento al menos tres diferentes, solo en esta misma página.

Algunas de las definiciones más comúnmente utilizados son (y sí, saben que casi ninguno de ellos tiene algún sentido, pero esas son las definiciones que he visto personas usan en realidad):

• escritura débil = escritura insegura / escritura fuerte = escritura segura
• escritura débil = escritura dinámica / escritura fuerte = escritura estática
• mecanografía débil = mecanografía pato / mecanografía fuerte = mecanografía nominal
• tipificación débil = tipificación estructural / tipificación fuerte = tipificación nominal
• escritura débil = escritura implícita / escritura fuerte = escritura explícita
• escritura débil = escritura latente / escritura fuerte = escritura manifiesta
• escritura débil = sin escritura / escritura fuerte = escritura
• escritura débil = conversiones implícitas / escritura fuerte = solo conversiones explícitas
• escritura débil = lanzamientos implícitos o explícitos / escritura fuerte = sin lanzamientos
• escritura débil = conversiones implícitas / escritura fuerte = solo conversiones explícitas
• escritura débil = conversiones implícitas o explícitas / escritura fuerte = sin conversiones
• escritura débil = interpretación / escritura fuerte = compilación
• escritura débil = escritura lenta / fuerte = rápida
• escritura débil = recolección de basura / escritura fuerte = administración manual de memoria
• escritura débil = gestión de memoria manual / escritura fuerte = recolección de basura
• … y muchos otros

Sin embargo, las tres definiciones que parecen usarse más ampliamente son

• mecanografía débil = su estúpido lenguaje de programación horrible / mecanografía fuerte = mi lenguaje de programación súper increíble
• escritura débil = cualquier otro lenguaje de programación / escritura fuerte = el único lenguaje de programación que alguna vez me molesté en aprender (generalmente Java, C # o C ++; curiosamente, las personas que aprenden, por ejemplo, Haskell o Scheme como su primer y único lenguaje, no parecen compartir esta cosmovisión)
• escritura débil = todos los idiomas que no entiendo / escritura fuerte = Java (sustituya con C # o C ++ a voluntad)

A menos que todo el mundo está de acuerdo en una definición de lo "débil escribir" aún es , que ni siquiera tiene sentido pensar en cuáles podrían ser sus ventajas. ¿Ventajas de qué? Peor aún, si no hay una definición en absoluto , entonces todos pueden cambiar sus definiciones para que se ajusten a sus argumentos, y se garantiza que cada discusión se convertirá en una guerra de llamas.

Yo mismo he cambiado personalmente mi propia definición varias veces a lo largo de los años y ahora he llegado al punto en que ya ni siquiera considero que los términos sean útiles. También solía pensar que la escritura débil (en sus diversas definiciones) tiene un lugar en las secuencias de comandos de shell, pero cada vez que tengo que resolver el mismo problema en Bash y PowerShell, me recuerda dolorosamente lo equivocado que estaba.

Recuerde que hay dos conceptos principales que comúnmente se confunden:

Escritura dinámica

Se dice que un lenguaje de programación se tipea dinámicamente cuando la mayoría de su verificación de tipo se realiza en tiempo de ejecución en lugar de en tiempo de compilación. En la escritura dinámica, los valores tienen tipos pero las variables no; es decir, una variable puede referirse a un valor de cualquier tipo.

Las ventajas aquí a menudo se descartan solo para "nuevos" programadores, pero también pueden ser convenientes para cualquier programador:

if (!(arr is Array)) arr = [arr]; // is, instanceof, .constructor ==, whatever

Menos código en cualquier caso en el que de lo contrario tendría que emitir o asignar un nuevo valor:

if (data is Array)) {
    i = data.length; // no i = ((Array)data).length or Array myArr=(Array)data;
}

Mecanografía floja o débil

La escritura débil significa que un lenguaje convierte implícitamente (o emite) tipos cuando se usa.

Beneficios:

• Pase cualquier valor de tipo como parámetro a una función . Útil para devoluciones de llamada, API flexibles y facilita la implementación de cierres.

• Evaluación booleana implícita . Cualquier tipo puede evaluarse como booleano. Esto también tiene beneficios secundarios, como una parte de un ||puede usarse en la asignación sin conversión a booleano:

  var a = param || defaultValue;
  

• De nuevo, menos código:

  var num = 5;
  var str = "Hello";
  input.innerHTML = input.value = num;
  for (var i=0; i < input.value; i++) { ... }
  

  Incluso Java tuvo que ir a la mitad, con la llamada implícita a .toString()cuando se combinan objetos con a String; de lo contrario, los programadores de Java lo maldecirían todo el día (las declaraciones de registro estarían fuera de control).

^{Ambas definiciones son de http://en.wikipedia.org/wiki/Type_system . Lo dijo mejor de lo que pude.}

El argumento principal para escribir débilmente es uno de rendimiento. (Esto es para responder a la pregunta de los OP como se indicó). Hay mucha buena discusión sobre dinámica vs. estática, implícita vs. explícita. etc.

C es el lenguaje de escritura débil más famoso, y no realiza ninguna verificación de tiempo de ejecución o verificación de tiempo de compilación del tipo de variables. En esencia, puedes echar un char *a int *y al idioma no le importaría. Entonces, ¿por qué harías esto?

La programación en C es bastante parecida a la forma en que haría las cosas con el ensamblaje, por lo que hay momentos en los que solo le importa una dirección. No es raro emitir o pasar una void *referencia por esa misma razón. Si sabe cómo está organizada la memoria (una vez más una cuestión de C y ensamblaje), puede hacer algunos cálculos bastante buenos basados ​​en la dirección en la void *para obtener la información que necesita. Esto puede permitirle cortocircuitar el proceso por el que tendría que pasar en Java, por ejemplo.

Si bien la verificación de tipo en tiempo de ejecución no tiene una carga de trabajo extraordinaria, hay momentos en que es suficiente para hacer que una sección crítica sea demasiado lenta. Estoy pensando principalmente en la programación integrada y los sistemas de tiempo real en este caso.

Dicho esto, en la mayoría de los casos, tener un sistema de tipo fuerte que sea el tiempo de compilación verificado o el tiempo de ejecución verificado ayuda más a menudo de lo que duele.

La escritura débil suele ser más fácil de entender para los novatos, por ejemplo, en excel, javascript y vbscript. También intercambia cierta velocidad de desarrollo por posibles errores.

Buen artículo sobre el tema: mecanografía fuerte vs pruebas fuertes