ARTDEPARTMENT
ARTDEPARTMENT
Durante casi una lapso, un pequeño detalle del idioma turco estuvo provocando que el habla de programación Kotlin —uno de los pilares del incremento flamante para Android— generara errores aparentemente inexplicables. Lo que comenzó como un mensaje en un foro en 2016 terminó convirtiéndose en un sorprendente hito de la historia de la ingeniería de software: un idioma humano que consiguió 'romper' un habla de programación.
En marzo de 2016, el ingeniero turco Mehmet Nuri Öztürk publicó un mensaje en el foro de Kotlin. Su código no compilaba, y el compilador mostraba un error críptico:
Unknown compiler message tag: INFO
Nadie sabía qué significaba. Kotlin acababa de editar su traducción 1.0, y todo indicaba que se trataba de un parecer beocio. Sin secuestro, pasaron meses antiguamente de que otro programador, Muhammed Demirbaş, sospechara que el problema no tenía nulo que ver con el código… sino con el idioma del sistema activo.
En la veterano parte de lenguas con alfabeto latino, la pagaré "I" se convierte en "i" al producirse a minúsculas. Pero en turco existen dos variantes de la pagaré:
Así, mientras "INFO".toLowerCase() en inglés produce "info", en turco devuelve "ınfo", con una ı sin punto. Esa diferencia minúscula provocaba que el compilador de Kotlin no encontrara la categoría de mensaje esperada y fallara con un error incomprensible.
El error se documentó oficialmente como KT-13631: "Compilation fails on Turkish locale because of locale-sensitive uppercasing". Pero quedó enterrado entre cientos de tickets y no se solventó. Nadie sospechaba que aquel detalle iba a causar más estragos primaveras posteriormente.
La carrera de programador en 2017 y en el futuro (con Javier Santana)
En 2018, Kotlin lanzó su traducción 1.3 con una de sus funciones hado: las corrutinas, un sistema para manejar tareas asíncronas de modo elegante. Fue entonces cuando el problema lingüístico resurgió con fuerza.
El desarrollador turco Kemal Atlı reportó un error al renovar su app:
java.lang.NoSuchMethodError: No static method boxİnt(I)Ljava/lang/Integer;
La secreto estaba en el nombre del método: boxİnt(), con una “İ” mayúscula con punto. El compilador, al suscitar código para las corutinas, usaba la función capitalize() para construir nombres de métodos como boxInt(). Pero, al ejecutarse en un sistema configurado en turco, convertía “int” en “İnt”, y el compilador buscaba un método que no existía.
Ese error concreto se resolvió en 2019 al especificar explícitamente el uso del idioma inglés en la emplazamiento a capitalize(Locale.US). Pero ya era evidente que el problema iba mucho más allá de una simple función.
Dos primaveras posteriormente, otro desarrollador turco, Muhittin Kaplan, reportó un nuevo parecer: su sencillo software con intArrayOf() fallaba con un NoSuchMethodError. De nuevo, el culpable era el mismo: el método decapitalize() había devuelto "ıntArray" (con ı sin punto) en puesto de "intArray".
Finalmente, la respuesta del equipo de Kotlin fue convincente: agenciárselas y corregir todas las operaciones de cambio de mayúsculas/minúsculas dependientes del idioma en el compilador. En total, 173 líneas de código y 53 archivos fueron modificados, reemplazando las funciones toLowerCase(), toUpperCase(), capitalize() y decapitalize() por versiones independientes del 'locale'.
En mayo de 2021, con el divulgación de Kotlin 1.5, el histórico bug KT-13631 se cerró oficialmente, cinco primaveras posteriormente de su primer reporte.
El impacto fue tan profundo que el equipo de JetBrains publicó la propuesta KEEP-223: “Locale-agnostic case conversions by default”, para rediseñar por completo la forma en que Kotlin maneja las conversiones de mayúsculas y minúsculas.
A partir de Kotlin 1.5 se introdujeron las nuevas funciones uppercase() y lowercase(), que ignoran el idioma del sistema. Y desde Kotlin 2.1 (noviembre de 2024), el uso de las antiguas toLowerCase() y toUpperCase() genera un error de compilación. Incluso capitalize() desapareció definitivamente, reemplazada por replaceFirstChar { … }.
En otras palabras: el idioma turco obligó a cambiar la biblioteca standard de Kotlin y a redefinir funciones que existían desde su origen.
Al final, un carácter sin punto fue suficiente para confundir compiladores, cercar proyectos y atañer a los ingenieros de JetBrains a replantear cómo su habla debía entender el texto. Pero el problema no estaba en la argot turca ni en los programadores de Kotlin, sino en una presunción que demostró ser injustificada: que el 'alfabeto inglés' (la variable inglesa del alfabeto latino, siendo precisos) era el standard universal para la informática.
Vía | Medium
Imagen | Marcos Merino mediante IA
En Genbeta | "Usar habla natural no simplifica el trabajo". En 1979, esta divisa de la programación ya vio venir los riesgos del 'vibe coding'
Compartir este artículo
Consultoria Personalizada
¡Si aun no tienes presencia en internet o
necesitas ayuda con tus proyectos, por favor, escribenos!
En ARTDEPARTMENT nos especializamos en brindar soluciones para que tu negocio, empresa o proyecto sea visible en internet.