El artículo del blog 'The Clean Code' explora una tendencia preocupante en el desarrollo de lenguajes de programación modernos, específicamente Swift y Kotlin. Ambos lenguajes, aunque con orígenes distintos (Swift derivado de Objective-C y Kotlin de Java), comparten una marcada inclinación hacia la tipificación estática y la imposición de reglas estrictas, lo que, según el autor, podría ser un camino equivocado.
La tipificación estática, en sí misma, no es un problema. Ofrece ventajas, pero el grado de rigidez en Swift y Kotlin es excesivo. Por ejemplo, en Swift, cualquier función que lance una excepción requiere una secuencia de bloques do-try (o alternativas) en toda la pila de llamadas, impidiendo la propagación silenciosa de excepciones. Kotlin impone restricciones similares en la herencia (requiriendo la palabra clave open) y en el manejo de valores nulos (requiriendo comprobaciones explícitas con ?: o bloques if). Esto se justifica, según los desarrolladores de estos lenguajes, para evitar errores comunes como NullPointerException (NPE), apodado el “Bug Billonario”).
El autor argumenta que esta tendencia a 'parchear' los defectos del código con características del lenguaje es una consecuencia de la falta de pruebas exhaustivas por parte de los programadores. En lugar de responsabilizar a los lenguajes por los errores, la responsabilidad recae en los desarrolladores, quienes deberían implementar pruebas rigurosas para detectar y corregir problemas. La proliferación de estas características restrictivas conduce a lenguajes complejos, con una sintaxis intrincada y manuales extensos, requiriendo que los programadores se conviertan en 'abogados del lenguaje' para dominarlos.
La solución propuesta no es evitar los errores a través de la tipificación estática, sino fomentar una cultura de pruebas sólidas. Las restricciones impuestas por estos lenguajes asumen un conocimiento perfecto del sistema antes de su implementación, lo que es irreal. El autor advierte que estas restricciones pueden llevar a cambios masivos en el código cuando se descubre que una clase necesita ser abierta, una función necesita propagar un valor nulo o una excepción necesita ser manejada en un nivel superior. En resumen, el artículo aboga por un enfoque más centrado en la responsabilidad del programador y la importancia de las pruebas, en lugar de depender de características del lenguaje para mitigar los errores.