Programar una computadora no es una labor trivial. Hoy en día se tienen un sinfín de herramientas y rutinas que simplifican la vida del programador, pero que funcionan como "cajas negras" en donde no sabemos a ciencia cierta qué está pasando dentro de ese código. Ya Brian Kernigham dijo (en una entrevista), que la programación ya se había vuelto fastidiosa. Uno carga su programa en Python e incluye N bibliotecas de terceros. Uno espera, decía Kernigham, que todo salga bien y que no haya errores. ¿Pero si algo falla? ¿A qué biblioteca particular le echamos la culpa?
Pero claramente hoy no podemos programar todo desde cero. No quiero imaginar pensar en escribir un sistema como Google Maps, por ejemplo, sin un número enorme de bibliotecas. Por ello, usar componentes, bibliotecas, rutinas de otros, es casi un "mal necesario", pues aunque no queramos creerlo, muchas rutinas que se escriben contienen errores sutiles, que muchas veces no salen a la luz hasta que ocurren situaciones muy específicas.
Por ejemplo, Adobe Photoshop, uno de los programas más robustos que conozco, tiene un listado de los problemas y bugs que pueden ocurrir. No es un drama y es parte del ciclo del software. D hecho, peor aún, hace unos 30 años Intel sacó un procesador que cometía un error en ciertas condiciones en su matemática de punto flotante. Un error que les debe haber sido muy costoso, pues todos esos procesadores simplemente ya no se podían usar.
Pues bien, en el software que estoy contínuamente mejorando, sobre un sistema para estudiar táctica, uso un componente que pinta en la pantalla un tablero de ajedrez y además, ya tiene programadas las reglas del juego, incluso la captura al paso. Usando la base de problemas del método del carpintero (que puede descargarse de este enlace), hallé que el ejercicio 157 (véase siguiente diagrama, más abajo), al realizar la jugada ganadora, 1.Tg8, mi sistema hace la jugada del negro, Rxg8 pero de pronto, antes de que pueda continuar, aparece una torre negra en f8. Me sorprendió porque no sabía qué había hecho el componente para de pronto, aparecer una torre negra de la nada.
Después de ejecutar la jugada 1.Tg8, el sistema responde con Rg7-g8 y entonces, ¡aparece la torre negra en f8!
El círculo rojo indica dónde aparece la torre. Sospeché que el componente veía eso como enroque corto y lo hacía entonces. En el código interno del componente el sistema dice: si había una pieza (presumiblemente el rey negro), en e8 y ahora aparece en g8, entonces, la torre negra debe ir a f8 y desaparecer lo que haya en h8. Pero curiosamente, el componente no verifica, antes de hacer estas jugadas, que en e8 y h8 haya piezas negras, De hecho, la jugada 1.Tg8 tiene originalmente la torre blanca en e8.
¿Cómo corregir esto? Había que meterse en el código fuente. Pero he aquí que decidí preguntarle a Gemini AI de Google y como respuesta me dijo cómo modificar el código fuente. Hice lo que me dijo y listo, bug solucionado.
Notable poder resolver estos problemas en minutos, aunque confieso que me llevó algunas horas depurar el código para ver qué pasaba.
