¿Cuáles son los beneficios (y desventajas) de un lenguaje débilmente tipado?

Question

Soy un gran admirador de PHP y obviamente es un lenguaje muy débilmente tipado. Me doy cuenta de que algunos de los beneficios incluyen la independencia general de cambiar los tipos de variables sobre la marcha y tal.

Lo que me pregunto son los inconvenientes. ¿Qué se puede sacar de un lenguaje fuertemente tipado como C que de otro modo no se puede obtener de un tipo débilmente tipado como PHP? También con la configuración de tipo (como double ($ variable)), se podría argumentar que incluso un lenguaje de tipo débil puede actuar igual que uno fuertemente tipado.

So. Débil-tipo. ¿Cuáles son algunos beneficios que no incluí? Más importante aún, ¿cuáles son los inconvenientes?

Answer 1

La citada ventaja de tipos estáticos es que hay clases enteras de errores capturados en tiempo de compilación, que no pueden alcanzar el tiempo de ejecución. Por ejemplo, si tiene una clase o interfaz estáticamente estátizada como parámetro de función, entonces no va a pasar accidentalmente un objeto del tipo incorrecto (es decir, sin un molde explícito e incorrecto).

Por supuesto, esto no le impide pasar el objeto incorrecto del tipo correcto, o una implementación de una interfaz donde le ha dado las funciones correctas pero hacen las cosas incorrectas. Además, si tiene una cobertura de código del 100%, diga la gente de PHP/Python/etc, ¿a quién le importa si detecta el error en tiempo de compilación o en tiempo de ejecución?

Personalmente, he tenido momentos divertidos en idiomas con tipado estático y momentos divertidos en idiomas sin. Rara vez es el tema decisivo, ya que nunca he tenido que elegir entre dos idiomas idénticos que no sean el tipo de tipeo y normalmente hay cosas más importantes de las que preocuparse. Encuentro que cuando uso lenguajes tipados estáticos deliberadamente "me apoyo en el compilador", tratando de escribir código de tal manera que, si está mal, no compila. Por ejemplo, hay ciertos refactores que puede realizar haciendo un cambio en un lugar, y luego arreglando todos los errores de compilación que resultan, repita hasta la compilación limpia. Hacer lo mismo ejecutando un conjunto de pruebas completo varias veces puede no ser muy práctico.Pero no es inaudito que los IDE automaticen los mismos refactores en otros idiomas, o que las pruebas se completen rápidamente, por lo que se trata de lo que es conveniente, no lo que es posible.

Las personas que tienen una preocupación legítima más allá de la conveniencia y la preferencia de estilo de codificación son las que trabajan en pruebas formales de la exactitud del código. Mi impresión ignorante es que la deducción de tipo estático puede hacer la mayoría (pero no la totalidad) del trabajo que hace el tipado estático explícito, y ahorra un desgaste considerable en el teclado. Entonces, si tipeo estático obliga a las personas a escribir código de una manera que hace que sea más fácil probarlo, luego bien podría haber algo de ese punto de vista. Digo "si": no lo sé, y no es como si la mayoría de las personas probaran su código de tipo estático de todos modos.

cambiar los tipos de variables sobre la marcha y tales

Creo que es de dudoso valor. Siempre es muy tentador para hacer algo así (Python/Django):

user = request.GET['username'] 
# do something with the string variable, "user" 
user = get_object_or_404(User,user) 
# do something with the User object variable, "user" 

Pero en realidad, si el mismo nombre puede utilizar para diferentes cosas dentro de una función? Tal vez. Probablemente no. La "reutilización", por ejemplo, las variables enteras para otras cosas en los lenguajes tipados estáticamente tampoco se fomenta masivamente. El deseo de no tener que pensar en los nombres de variables concisos y descriptivos, probablemente el 95% del tiempo no debe anular el deseo de código inequívoco ...

Por cierto, por lo general significa débil escritura que se producen conversiones de tipo implícitas, y fuerte mecanografía significa que no. Según esta definición, C está débilmente tipado en lo que respecta a los tipos aritméticos, así que supongo que eso no es lo que quieres decir. Creo que se considera ampliamente que la tipificación completa es más una molestia que una ayuda, y que "escribir completamente débilmente" (cualquier cosa se puede convertir a cualquier otra cosa) no tiene sentido en la mayoría de los idiomas. Entonces, la pregunta sobre cuántas conversiones implícitas se pueden tolerar antes de que se vuelva demasiado difícil de descifrar. Ver también, en C++, la dificultad actual para decidir si implementar operadores de conversión y constructores no explícitos de una arg.

Answer 2

Se ha escrito un libro sobre este tipo de cosas. Hay una compensación inherente; con un lenguaje débilmente tipado, muchas molestias simplemente dejan de serlo. Por ejemplo, en Python nunca tendrá que preocuparse de dividir un float por un int; agregando un int a un list; argumentos de las funciones de escritura (¿sabías que OCaml tiene operadores especiales +. Para agregar float s porque (+) envía int a int s); olvidando que una variable puede ser nula ... ese tipo de problemas simplemente desaparecen.

En su lugar vienen toda una serie de nuevos errores de tiempo de ejecución: de Python [0]*5 da, esperar a que, [0,0,0,0,0]! OCaml, a pesar de la molestia de la tipificación fuerte, detecta muchos errores de con su compilador; y esta es precisamente la razón por la cual es bueno. Es una compensación.

Answer 3

recta de Wikipedia:

The advantage claimed of weak typing is that it requires less effort on the part of the programmer than strong typing, because the compiler or interpreter implicitly performs certain kinds of conversions. However, one claimed disadvantage is that weakly typed programming systems catch fewer errors at compile time and some of these might still remain after testing has been completed.

Eso es aproximadamente el mismo que diría. Sin embargo, tenga cuidado con la relativa ambigüedad de estos términos ("tipado fuerte" y "tipado débil") ya que las conversiones implícitas desdibujan la línea.

Fuente: http://en.wikipedia.org/wiki/Weak_typing

Answer 4

Débil y fuerte son términos cargados. (¿Quieres ser un programador de lenguaje débil?) Dinámico y estático son mejores, pero me imagino que la mayoría de las personas preferiría ser un programador dinámico que uno estático. Yo llamaría un lenguaje PHP promiscua (Eso no es un término cargado;))

PHP:

garbage_out = garbage_in * 3; // garbage_in was not initialized yet 
"hello world" + 2; // does this make sense? 

Permitir que las variables sin inicializar crea muy difícil encontrar errores de faltas de ortografía. Permitir operaciones en tipos no relacionados es casi siempre un error que debe ser reportado. La mayoría de los lenguajes dinámicos interpretados no permiten estas cosas por una buena razón. Puede tener un lenguaje escrito dinámicamente sin permitir basura.

Answer 5

Ver this table, que muestra los resultados del operador PHP == aplicado a pares de valores principales vacíos u otras de diversos tipos, tales como 0, "0", NULL y "". El operador no es conmutativo, y la tabla es bastante intuitiva, por decir lo menos. (No es que tenga mucho sentido preguntar si una cadena es igual a una matriz, para ser justos, pero puede hacer eso en un lenguaje débilmente tipado, que es la trampa, y puede que Turing lo ayude si el lenguaje lo intenta para "ayudarte")

Answer 6

Tienes que entender que PHP fue creado para el contexto de las aplicaciones web.Todo en el contexto de la web es una cadena. Por lo tanto, es muy raro que una tipificación fuerte sea beneficiosa.

Answer 7

He estado usando tanto lenguaje fuertemente tipado (como Java) como de tipo débil (como JavaScript) desde hace algún tiempo. Lo que he encontrado es que la conveniencia de los idiomas de tipo débil es excelente para aplicaciones pequeñas. Desafortunadamente, a medida que la aplicación aumenta de tamaño, se vuelve imposible de administrar. Se vuelve demasiado para realizar un seguimiento en su cabeza y tiene que empezar a depender de su IDE y del compilador cada vez más o su codificación se detiene. Es entonces cuando los lenguajes fuertes de tipo mecanografiado comienzan a ser más útiles, con la aplicación crece mucho.

Dos ejemplos que me vuelven loco constantemente en el JavaScript débilmente tipado son el uso de bibliotecas externas que no están completamente documentadas y refabricadas.

Bibliotecas externas: cuando se trata de un lenguaje fuertemente tipado, el código de la propia biblioteca proporciona documentación propia. Cuando creo una variable de tipo Persona, el IDE puede inspeccionar el código y decir que hay un getFirstName(), getLastName() y getFullName(). En los lenguajes de tipo débil, este no es el caso ya que una variable puede ser cualquier cosa, tener cualquier tipo de variable o función y tener argumentos de función que también podrían ser cualquier cosa (no están definidos explícitamente). Como resultado, un desarrollador tiene que apoyarse mucho en la documentación, búsquedas en la web, foros de discusión y su memoria de usos pasados. Creo que puede llevar horas buscar cosas en JavaScript para bibliotecas externas, mientras que con Java, simplemente presiono el "." clave y aparece todas mis opciones con la documentación adjunta. Cuando encuentre bibliotecas que no estén completamente documentadas al 100%, puede ser muy frustrante con los lenguajes de tipo débil. Recientemente me encontré preguntando "¿Qué es argumento 'argumento' en la función 'dibujar'?" cuando se utiliza jqplot, una biblioteca de JavaScript bastante bien pero no completamente documentada. Tuve que pasar una o dos horas investigando el código fuente antes de finalmente darme por vencido y encontrar una solución alternativa.

Refactorización: con los lenguajes fuertemente tipados, me puedo refactorizar rápidamente con solo cambiar el archivo que necesito cambiar y luego corregir los errores del compilador. Algunas herramientas incluso se refactorizarán con un simple clic de un botón. Con los idiomas de tipo débil, debe hacer una búsqueda y luego reemplazar con cuidado y luego probar, probar, PRUEBA y luego probar un poco más. Raramente está completamente seguro de haber encontrado y arreglado todo lo que rompió, especialmente en aplicaciones grandes.

Para necesidades simples y pequeñas aplicaciones, estas dos preocupaciones son mínimas o inexistentes. Pero si está trabajando con una aplicación con cientos de miles o millones de líneas de código, los lenguajes de tipo débil lo volverán loco.

Creo que muchos desarrolladores se enojan por esto y lo convierten en una discusión emocional porque a veces nos damos cuenta de que hay un enfoque correcto y otro incorrecto. Pero cada enfoque tiene sus méritos: sus propias ventajas y desventajas. Una vez que reconozca que deja de lado la emoción y elija la mejor para usted para lo que necesita en este momento.