👵🏻 👨‍🍳 🧓🏾 La escritura dinámica no es una herramienta de desarrollo. Esto no tiene sentido (pésimo) 📬 🏴‍☠️ 👩🏿‍🤝‍👩🏽

Hay muchas cosas en la programación que entiendo muy mal. Tantos que a veces me preguntan: ¿en qué eres bueno?

Entiendo los tipos y el diseño de una API conveniente y confiable. Pero para una buena mitad de los desarrolladores, estas cosas no significan nada. Porque usan la tipificación dinámica y no tienen idea de qué problemas y por qué los resuelvo.

Durante la mayor parte de mi vida, solo los saludé con la mano y pasé de largo. Estos tontos no entienden las cosas obvias, y no me comprometí a explicarle a cada apodo js por qué su código no es desarrollo, sino prototipos de juguetes. Pero el tiempo pasa, y la cantidad de idiotas no piensa en disminuir, en lugar de trasladar toda su industria de front-end a un guión de tiempo estático, estos burros comienzan a usar todo tipo de cosas, escriben toneladas de pruebas y recurren a cualquier truco imaginable, solo para no entender tipos.

Hay muchas cosas controvertidas en el mundo cuando, dependiendo de lo que quieras obtener, la verdad se transfiere de una balanza a otra, sin dejar lugar para ninguna verdad última en última instancia. Hace un par de años ya escribí sobre mecanografía, pero era joven, estúpido y cobarde. Tenía una posición, pero para no parecer un idiota, la oculté cuidadosamente detrás de discusiones filosóficas sobre lo complicado que es todo y lo difícil que es para los adherentes trabajar. diferentes modelos de mecanografía juntos.

Pero hoy vine aquí para decir:

La escritura dinámica es una mierda infernal, y los ingenieros que creen en este enfoque están seriamente equivocados.

Echar un vistazo. La escritura estática es algo que me permite expresar algunas de las condiciones bajo las cuales el código no puede funcionar como instrucciones adicionales para el compilador. Es decir, sé que esta función solo funciona con dichos objetos, los describo en su firma y obtengo una garantía: un objeto de un tipo diferente no se transferirá a la función. Además, los tipos me permiten decirle al compilador cómo funciona mi código. El compilador podrá usar esta información para llevar a cabo optimizaciones y, por ejemplo, para darme pistas. Diferentes herramientas de desarrollo pueden usar información de tipo para refactorizar automáticamente, hacerlo de manera segura y con la garantía de que la mierda no se rompe. El código de tipo en sí hace que la base del código sea comprensible y acerca sus conjuntos de instrucciones a los procesos que describe con este código.

Los opositores a la escritura estática dicen que todas estas cosas son innecesarias. Me dicen que

Los errores que detectan tipos no merecen el esfuerzo de escribir código para estos tipos.

¿Seriamente? ¿Seriamente? ¿Somos demasiado vagos para escribir personajes? Hermano Piensas durante cinco horas e imprimes diez minutos. Eres ingeniero, así que trata de averiguar de qué tipo de comodidad estás hablando. Y no olvide que con o sin tipeo estático, más de una vez describirá en su base de código las estructuras de los objetos con los que trabajará. Pero si usa estadísticas, el compilador y el IDE pueden hacer el trabajo por usted. Y revise su código en busca de errores que describan estos objetos. Si es demasiado vago para escribir anotaciones de tipo en las funciones, use el lenguaje de inferencia de tipos o genere usando extensiones al IDE.

Si pisa fuerte que las anotaciones inflan la base del código, recuerde, maldición, todos nuestros principios sobre el hecho de que lo explícito es mejor que lo implícito, que una de las tareas importantes de la base del código es ser comprensible y legible, tanto por una persona como por una máquina. Si eres demasiado vago para trabajar en tu cabeza tonta para entender en qué tipos de aplicaciones funcionará tu aplicación, entonces tengo malas noticias para ti. Para escribir algo que funcione, todavía tienes que hacer este trabajo. Solo hazlo, no estarás determinado, sino a pedido. Como resultado, describirá el proceso, pero no lo pondrá en su cabeza y la calidad de su código responderá. Errores, incoherencia y muletas.

Los opositores a la escritura estática dicen que los errores de captura temprana no son tan importantes.

Alo. Su tablero de tareas está lleno de errores que los desarrolladores permitieron. La reparación de errores es una gran parte de todo el trabajo en la industria. Pasamos miles de millones de horas humanas para corregir errores ridículamente ridículos. ¿Escribes código sin errores? o solo tienes errores inteligentes? Sí, el infierno nadó allí. Si el compilador no comprobó por usted que cerró la llave, créame, tendríamos cientos de errores con una llave abierta.

Cuando piensa en dónde puede ocurrir un error y dónde no, aparece una ilusión peligrosa de que usted tiene el control de la situación y ha previsto todos los casos. He estado trabajando durante siete años, nunca ha habido tal cosa que haya previsto todos los casos. Como se trata de un caso especial del problema del vendedor ambulante, NUNCA puede prever todos los casos. Ni siquiera puedes considerar lo más común y probable. Cuándo, quién y en qué situación escribirá el código con un error crítico, en qué módulo y cómo lo hará: usted, maldita sea, no tiene idea. Todo lo que puede hacer es reducir la posibilidad de un error. Así que reduzca, le pagan dinero loco por esto.

Opositores de los tipos de contraste de tipeo estático con pruebas.

No diré que son idiotas, diré que simplemente no lo pensaron bien. Aquí está la verdad obvia para usted: las pruebas registran que el código existente funciona bajo ciertas condiciones. Y los tipos garantizan que el código que aún no se ha escrito se escribirá bajo ciertas condiciones. Se necesitan pruebas. Se necesitan tipos. Todavía reduce las posibilidades de que todo se caiga. En un mundo donde tenemos un presupuesto para discutir con el equipo durante cinco horas qué está mal con nuestro Edge, habrá tiempo para agregar anotaciones y un par de pruebas.

Los nerds del mundo dinámico dicen que la escritura estática priva al código de flexibilidad.

No entiendo de qué tipo de flexibilidad están hablando. Incluso en el empobrecido C #, el sistema de tipos me permite no tener control sobre los tipos de datos cuyo tipo no me importa. Siempre puedo demostrarle al idioma que aquí, dicen, escuchen aquí, no puedo describir qué es esta cosa, pero sé con certeza que tiene ese campo, de este tipo o de este tipo. Y solo trabajaré con él. Cualquier lenguaje escrito estáticamente lo permite. Y flexibilidad y libertad para escribir código que simplemente no puede funcionar: no necesito tanta flexibilidad.

Los adolescentes de JS dicen que la escritura estática cambia el enfoque de la tarea a la descripción del tipo.

Y digo que la descripción de los tipos es la descripción del proceso que automatizas. En la programación orientada a objetos, en la programación funcional, en cualquier otra programación, describimos cosas del mundo real, y nuestro código contiene el conocimiento sobre ellas, sin el cual no puede funcionar. Seguirás haciendo este trabajo.

Si el sistema de tipos de un idioma específico no le permite describir su dominio de forma correcta y segura, este es un problema de un idioma en particular, y no de la escritura estática en general. Esto es normal y, específicamente, en este lenguaje, utiliza todo tipo de objetos y dinámicos en lugares, pero siempre que puede obtener garantías, las obtiene.

Escribí código con escritura dinámica y estática. Con estricto y no estricto, con estructura y nominativo.

Solo el dinámico me hizo sentir fuertemente que estaba escribiendo un pseudocódigo infantil que funcionaría solo si las estrellas convergieran.

La escritura dinámica es un juguete, algo que funcionará cuando decidas codificar algo en uno y olvidarte de él. Cuando planea desarrollar, cuando otras personas trabajarán con su código, cuando el código salga a la venta y comience a resolver los problemas del usuario, actualizándose una vez a la semana, la escritura dinámica es absolutamente inaceptable. Solo recuerda esto y cambia las extensiones de tus archivos de .js a .ts.

Y mira mi podcast: hay un nuevo problema

La escritura dinámica no es una herramienta de desarrollo. Esto no tiene sentido (pésimo)