sábado, 9 de septiembre de 2017

El peligroso, salvaje e indispensable GOTO

Para Dante,
aunque sea con cerca de
30 años de retraso.


En marzo de 1968, el científico de computación holandés Edsger W. Dijkstra (conocido en occidente como Edgar Dijkstra) publicó el influyente artículo "Go To statement considered harmful" (La instrucción Go To considerada dañina) en el boletín de Comunicaciones de la ACM (Association for Computing Machinery), también conocida como CACM. En este artículo señalaba que el uso creciente del salto incondicional estaba ocasionando que los programas se volvieran ilegibles y muy propensos a errores y reflexionaba y disertaba como el mantener cierta disciplina en la programación permitiría hacer no solamente programas legibles y confiables, sino hacerlos más grandes y propensos a modificarlos en vez de rehacerlos (es decir, hacerlos más flexibles).

Por un lado, esto dio inicio a la disciplina llamada Programación Estructurada donde todo el flujo del programa está basado en bloques bien definidos y que no deben traslaparse ni intereferir entre sí.

Pero esto también ocasionó una gran polémica que, aunque es muy técnica y se ha ido acallando, sigue siendo escabrosa.
Desde el principio muchos programadores protestaron porque la sentencia GO TO era su principal herramienta de control de flujo, no había otra cosa; en 1974 el propio Donald Kunth (matemático considerado el mayor experto en algoritmos computacionales y profesor emérito en Stanford) arguía que a veces el uso del GO TO mejoraba la eficiencia de ejecución, de forma era mejor alternativa que el detrimento en legibilidad; en 1978 los diseñadores del lenguaje C, Brian Kernighan y Dennis Ritchie dijeron que "se podía abusar infinitamente del GO TO", pero de todas maneras lo incluyeron en las especificaciones de C.
El también científico de la computación, el suizo Niklaus Wirth, jefe del equipo de diseño de los lenguajes académicos Euler, Algol W, Pascal, Modula, Modula-2 y Oberon (que por cierto era el editor del CACM cuando se publicó la carta de Dijkstra), diseñó los lenguajes para impulsar la disciplina del estructuralismo en la programación, aunque incluyó el GO TO por si acaso. Esto dio origen a una de las preguntas más peliagudas y difíciles que influyen aun ahora en el diseño de lenguajes modernos: ¿las reglas en la sintaxis del lenguaje usado fomentan la buena programación?

El lenguaje JAVA, por ejemplo, tiene reservada la instrucción goto aunque no la usa. Esto es principalmente porque en los lenguajes modernos se usa pero con formatos muy específicos y con nombres diferentes: son la sentencias exit, continue, break y exception (o try-catch); esto es, hay que ver su uso, es equivalente a la función que desempeñaba el goto:

exit. Salida incondicional de un programa.
continue. Salta incondicionalmente a la siguiente iteración en un ciclo.
break. Sale incondicionalmente de un ciclo.
exception (o try-catch). Esta es la instrucción menos parecida al GO TO, aparentemente, pero si uno analiza su funcionamiento, su objetivo es casi el mismo: cuando se ejecutan algunas sentencias y operaciones ocasionan errores (por ejemplo, en una operación cuando se intenta dividir ente cero o cuando se le pide a la máquina que lea un número, pero la entrada contiene letras o símbolos no numéricos) y en este caso, se ejecuta la sentencia exception (o la parte equivalente, catch) que sirve como etiqueta o punto de entrada para ejecutar una subrutina o un bloque para manejar el error (recuperarse o al menos morir graciosamente). Esto es el equivalente a una sentencia GO TO condicionada y la ejecución de un bloque etiquetado:

if [ocurrió un error] goto excepcion
excepcion:
{ ....
   líneas de código para manejar el error
   ....
   ....
}

En resumen:

  • La sentencia GO TO no es mala per se, solamente cuando se usa sin control y en exceso es cuando es dañina.
  • La sentencia GO TO ya amaestrada se usa actualmente para manejo de excepciones, por ejemplo, mediante sentencias ejecutables ya más evolucionadas.
  • La sentencia GO TO se puede usar cuando el uso de otras sentencias o estructuras de control puedan conducir a un flujo complejo del programa (nota. Cuidado en este caso, si pasa esto, puede ser indicador de que el flujo completo del programa necesite rediseñarse, si nos gana la flojera, puede pasarnos lo mismo que al monito de la historieta del principio del post: en vez de un bug horriblito, le salió un velocirraptor salvaje).



5582.30

domingo, 25 de junio de 2017

IAs al rescate (o no le tengo miedo a las IAs, es solamente precaución).




Una de las tendencias tecno-sociales en este principio de siglo es el miedo a las Inteligencias Artificiales (IAs en español, AIs en inglés). Miedos que van desde la mítica y paranoica singularidad (las IAs se van a volver tan poderosas y capaces que van a igualar y a superar al ser humano [ver el post del blog hermano “El blog de GodMakers: De singularidades muy singulares]) hasta los muy reales temores de que muchos trabajos que antes realizaban los humanos, ahora ya van a ser hechos por las IAs. Este miedo existe desde el s. XVIII (centuria de 1700) en los albores de la revolución industrial, cuando se empezaron a usar telares mecánicos operados a pedales y maquinas de vapor para perforar y operar pozos de agua y, sobre todo, para servir de motor en lanchas y barcos. En el s.XIX (centuria de 1800), de hecho, surgió un movimiento llamado Ludismo que defendía las ideas antimáquinas y pro-trabajo humano. Pero existe el pequeño detalle que matemáticamente se puede demostrar que todas las protestas luditas son inútiles e incluso dañan la economía. Tal como lo pregonaba el buen Dr. A (Isaac Asimov), el progreso tecnológico no se puede parar, es como pedirle al cuerpo humano que consuma menos oxígeno mientras tratamos de correr más rápido (en mi otro blog, “Entre la Maldición y las Estrellas” tengo una serie de ensayos que tratan sobre este tema (Futuro I, II, III y IV). No se puede para el avance de la automatización, no se van a poder parar la implantación de agentes IA para la ciberseguridad industrial, tal como lo muestra este post. El avance tecnológico y su interacción con los seres humanos hace que la tecnología sea tan complicada que solamente puede ser manejada y mantenida de forma eficiente por las IAs (por ejemplo, las tecnologías de la nube y los ciberataques de parte de hackers y terroristas hacen que este punto se vuelva tan complejo, que su desarrollo y mantenimiento de parte de las IAs es casi obligatorio). Por supuesto que los beneficios económicos van a ser enormes (se calcula un impacto de 1.1 trillones de dólares en la economía global). Socialmente, se han hecho a un lado los temores y se han hecho estudios tanto a favor como en contra del desplazamiento laboral de las IAs, tal como lo muestra este artículo. No son noticias ni buenas ni malas, lo único que se muestra es información que muestra tendencias que tienen más de 200 años. Quizá lo que se necesite sea un cambio de modelo económico en vez de estarle poniendo parches.


5516.64