El programador Humble por Edsger W.

Dijkstra Como resultado de una larga serie de coincidencias que entr en la profesin de programacin oficialmente en la primera maana de primavera de 1952 y por lo que he podido encontrar, yo era el primer holands en hacerlo en mi pas. En retrospectiva, lo ms sorprendente fue la lentitud con la que, al menos en mi parte del mundo, la profesin de programacin surgido una lentitud que ahora es difcil de creer. Pero estoy agradecido por dos recuerdos vivos de aquella poca que establecen que la lentitud fuera de toda duda. Despus de haber programado para unos tres aos, tuve una conversacin con A. van Wijngaarden, que entonces era mi jefe en el Centro de Matemticas en Amsterdam, un debate para que me quedar agradecido con l todo el tiempo que yo vivo. El punto era que yo tena que estudiar fsica terica en la Universidad de Leiden, a la vez, y como me pareci que las dos actividades ms duro y ms difcil de combinar, tuve que hacer en mi mente, ya sea para detener la programacin y convertirse en un verdadero, respetable terico fsico, o para llevar a mi estudio de la fsica a una conclusin formal solamente, con un mnimo de esfuerzo, y llegar a ser ....., s qu? Un programador? Pero era una profesin respetable? Porque despus de todo, qu estaba programando? Dnde estaba el slido conjunto de conocimientos que podra apoyarla como una disciplina intelectualmente respetable? Recuerdo muy vvidamente cmo envidiaba a mis colegas de hardware, que, cuando se le pregunt acerca de su competencia profesional, podra al menos sealar que saban todo sobre los tubos de vaco, amplificadores y dems, mientras yo senta que, ante esa pregunta, sera estar de pie con las manos vacas. Lleno de dudas me llamaron a la puerta del despacho van Wijngaarden, pidindole si me poda "hablar con l por un momento", y cuando sal de su oficina un nmero de horas ms tarde, estaba otra persona. Porque despus de haber escuchado a mis problemas con paciencia, estuvo de acuerdo en que hasta ese momento no haba mucho de una disciplina de programacin, pero luego se pas a explicar en voz baja que los equipos automticos estaban aqu para quedarse, que estbamos justo en el comienzo y podra no voy a ser una de las personas llamadas a realizar la programacin de una disciplina respetable en los prximos aos? Este fue un punto de inflexin en mi vida y he completado mi estudio de la fsica formalmente lo ms rpido que pude. Moraleja de la historia por encima de ellas es, por supuesto, que tenemos que ser muy cuidadosos al dar consejos a los ms jvenes, a veces lo siguen! Otros dos aos ms tarde, en 1957, me cas y los ritos matrimoniales holandeses requieren que se declare su profesin y me dijo que yo era un programador. Pero las autoridades municipales de la ciudad de Amsterdam no la acept el argumento de que no haba tal profesin. Y, cranlo o no, pero bajo el ttulo "profesin" mi acto conyugal muestra la entrada ridculo "fsico terico"! Esto en cuanto a la lentitud con la que vi la profesin programacin surgir en mi propio pas. Desde entonces, he visto ms del mundo, y es mi impresin general de que en otros pases, aparte de un posible cambio de fechas, el patrn de crecimiento ha sido muy parecida.

Voy a tratar de captar la situacin en aquellos viejos tiempos en un detalle poco ms, con la esperanza de obtener una mejor comprensin de la situacin actual. Mientras seguimos nuestro anlisis, vamos a ver cuntos malentendidos comunes acerca de la verdadera naturaleza de la tarea de programacin se remonta a ese pasado ya lejano. Los primeros ordenadores electrnicos automticos eran todos nico de una sola copia mquinas y todos se encuentran en un entorno con el sabor excitante de un laboratorio experimental. Una vez que la visin del equipo automtico estaba all, su realizacin fue un reto enorme para la tecnologa electrnica disponible entonces, y una cosa es cierta: no podemos negar el valor de los grupos que decidieron tratar de construir una fantstica pieza de equipo. Para fantsticas piezas de equipo que eran: en retrospectiva, uno slo puede preguntarse que esas primeras mquinas trabajaron en absoluto, al menos a veces. El problema abrumador era conseguir y mantener la mquina en funcionamiento. La preocupacin por los aspectos fsicos de computacin automtica an se refleja en los nombres de las sociedades ms antiguas cientficos en el campo, tales como la Asociacin de Maquinaria de Computacin o la British Computer Society, nombres en los que se hace referencia explcita a la fsica del equipo. Qu hay del programador pobres? Bueno, a decir la pura verdad: l apenas se not. Por un lado, las primeras mquinas eran tan voluminosos que apenas poda moverlos y adems de eso, ellos tienen que mantener tan amplia que era muy natural que el lugar en el que se trat de utilizar la mquina era el mismo laboratorio donde se haba desarrollado la mquina . En segundo lugar, su obra algo invisible fue sin ningn glamour: se puede mostrar la mquina a los visitantes y que era varios rdenes de magnitud ms espectacular que unas hojas de codificacin. Pero lo ms importante de todo, el propio programador tena una vista muy modesto de su obra: su obra deriva toda su importancia a partir de la existencia de esa mquina maravillosa. Debido a que era una mquina nica, l saba muy bien que sus programas tenan slo importancia local y tambin, porque era patentemente obvio que esta mquina tendra una vida til limitada, saba que muy poco de su obra tendra un valor duradero. Por ltimo, hay otra circunstancia que tuvo una profunda influencia en la actitud del programador a su trabajo: por un lado, adems de ser poco fiable, su mquina era generalmente demasiado lento y su memoria era generalmente demasiado pequeo, es decir, se enfrent con un pellizco zapato, mientras que por otro lado su cdigo de pedido por lo general algo extrao sera atender a las construcciones ms inesperados. Y en aquellos das que un programador inteligente deriva una inmensa satisfaccin intelectual de los trucos astutos por medio de la cual se las arregl para exprimir lo imposible en las limitaciones de su equipo. Dos opiniones sobre la fecha de programacin de esos das. Los menciono ahora, voy a volver a ellos ms tarde. La opinin era que un programador muy competente debe ser de mente y rompecabezas muy aficionado a los trucos ingeniosos, la opinon otra era que la programacin no era ms que la optimizacin de la eficiencia del proceso de clculo, en un sentido o en otro. El ltimo dictamen fue el resultado de la circunstancia frecuente que, en efecto, el equipo disponible era un zapato dolorosamente pellizcos, y en esos das uno a menudo encuentra la expectativa ingenua de que, una vez que las mquinas ms potentes disponibles, la

programacin ya no sera un problema, porque entonces la lucha para empujar la mquina a sus lmites ya no sera necesario, y eso era todo lo que la programacin se trata, no? Pero en las prximas dcadas algo completamente diferente sucedi: las mquinas ms poderosas lleg a estar disponible, no slo un orden de magnitud ms potentes, incluso en varios rdenes de magnitud ms potente. Pero en lugar de encontrarnos en el estado de felicidad eterna de todos los problemas solucionados progamming, nos encontramos metidos hasta el cuello en la crisis del software! Por qu? Hay una causa menor: en uno o dos aspectos maquinaria moderna es bsicamente ms difcil de manejar que la vieja maquinaria. En primer lugar, tenemos las interrupciones de E / S, que se producen en momentos impredecibles e irreproducible, en comparacin con la vieja mquina secuencial que se hizo pasar por una completamente determinista autmata, este ha sido un cambio dramtico y muchas canas programador de sistemas da testimonio de la hecho que no debemos hablar a la ligera sobre los problemas lgicos creados por esa caracterstica. En segundo lugar, tenemos mquinas con niveles mltiples tiendas, presentndonos los problemas de la estrategia de gestin que, a pesar de la extensa literatura existente sobre el tema, todava siguen siendo bastante difcil de alcanzar. Esto en cuanto a la complicacin adicional debido a los cambios estructurales de las mquinas reales. Pero llam a esta causa un menor de edad, la causa principal es ... que las mquinas se han convertido en varios rdenes de magnitud ms potente! Para decirlo sin rodeos: siempre y cuando no haba mquinas, la programacin no fue un problema en absoluto, cuando tuvimos un par computadoras dbiles, la programacin se convirti en un problema leve, y ahora tenemos computadoras gigantescas, la programacin se haba convertido en un problema igualmente gigantesco. En este sentido, la industria electrnica no ha resuelto un solo problema, slo ha creado, que ha creado el problema de la utilizacin de sus productos. Para decirlo de otra manera: como el poder de las mquinas disponibles se multiplic por ms de un millar, la ambicin de la sociedad para aplicar estas mquinas creci en proporcin, y fue el programador pobre que encontr a su trabajo en este campo en despiece de tensin entre fines y medios. El aumento de potencia de los equipos, junto con el aumento tal vez ms dramtico de su fiabilidad, soluciones factibles hecho de que el programador no se haba atrevido a soar con unos pocos aos antes. Y ahora, unos aos ms tarde, tuvo que soar con ellos y, lo que es peor, tuvo que transformar esos sueos en realidad! Es una maravilla que nos encontramos en una crisis del software? No, no es cierto, y como pueden suponer, se predijo incluso mucho antes, pero el problema con los profetas menores, por supuesto, es que est a slo cinco aos despus de que usted realmente saber que tena razn. Luego, en el terrible mediados de los sesenta, algo sucedi: las computadoras de la tercera generacin denominada hicieron su aparicin. La literatura oficial nos dice que su relacin calidad / precio ha sido uno de los objetivos principales del diseo. Pero si se toma como "performance" el ciclo de trabajo de los distintos componentes de la mquina, poco le impide acabar con un diseo en el que se alcanza la mayor parte de su meta de desempeo por actividades domsticas internas de necesidad dudosa. Y si su definicin del precio es el precio que hay que pagar por el hardware, poco le impedir terminar wth un diseo que es terriblemente difcil de programar para: por ejemplo, el cdigo de pedido podra ser tal

como para hacer cumplir, ya sea en el progrmmer o en el sistema, las primeras decisiones vinculantes presentar conflictos que realmente no se pueden resolver. Y en gran medida, estas posibilidades desagradables parecen haberse convertido en realidad. Cuando estas mquinas fueron anunciadas y sus especificaciones funcionales se saba, no pocos entre nosotros que se han vuelto bastante miserable, por lo menos yo. Era razonable esperar que tales mquinas podra inundar la comunidad informtica, por lo que era ms importante que su diseo debe ser tan slida como sea posible. Pero el diseo plasmado estas graves fallas que sent que de un solo golpe el progreso de la ciencia de la computacin ha sido retardado por lo menos diez aos: fue entonces que tuve la semana ms negra de toda mi vida profesional. Tal vez lo ms triste es que ahora, despus de todos esos aos de experiencia de la frustracin, la gente todava muchos creen honestamente que alguna ley de la naturaleza nos dice que las mquinas tienen que ser de esa manera. Ellos acallar sus dudas al observar cmo muchas de estas mquinas han sido vendidas, y se derivan de la observacin de que la falsa sensacin de seguridad que, despus de todo, el diseo no puede haber sido tan malo. Pero una inspeccin ms cercana, esa lnea de defensa tiene la misma fuerza convincente el argumento de que el tabaquismo debe ser saludable porque mucha gente lo hace. Es en este sentido que lamento que no es costumbre de las revistas cientficas en el rea de informtica para publicar revisiones de equipos recientemente anunciados casi de la misma manera que se revisan las publicaciones cientficas: revisar las mquinas sera por lo menos igual de importante. Y aqu tengo que hacer una confesin: en los aos sesenta escrib esa revisin con la intencin de presentarlo al MCCA, pero a pesar del hecho de que los pocos colegas a los que el texto fue enviado por sus consejos, me inst a todo ello, no me atrev a hacerlo, por temor a que las dificultades ni para m, ni para el consejo de redaccin resultara ser demasiado grande. Esta represin fue un acto de cobarda de mi parte para que me culpo a m mismo cada vez ms. Las dificultades que prevea eran una consecuencia de la ausencia de criterios generalmente aceptados, y aunque yo estaba convencido de la validez de los criterios que haba decidido aplicar, tem que mi opinin sera rechazado o descartado como "una cuestin de gusto personal" . Sigo pensando que esos exmenes sera extremadamente til y me muero de ganas de verlos aparecer, por su apariencia aceptable sera una clara seal de madurez de la comunidad informtica. La razn por la que he prestado la atencin por encima de la escena hardware es porque tengo la sensacin de que uno de los aspectos ms importantes de cualquier herramienta informtica es su influencia en los hbitos de pensamiento de aquellos que tratan de utilizar, y porque tengo razones para creer que esa influencia es mucho ms fuerte de lo que comnmente se supone. Vamos a cambiar ahora nuestra atencin a la escena software. Aqu, la diversidad ha sido tan grande que debo limitarme a algunas piedras paso a paso. Soy muy consciente de la arbitrariedad de mi eleccin y yo te ruego que no sacar ninguna conclusin con respecto a mi apreciacin de los muchos esfuerzos que se mantendrn sin mencionar. En el principio fue el EDSAC en Cambridge, Inglaterra, y creo que es bastante impresionante que desde el principio la idea de una biblioteca de subrutinas jugado un

papel central en el diseo de la mquina y de la forma en que se debe utilizar. Hace ya casi 25 aos ms tarde y la escena informtica ha cambiado drsticamente, pero la nocin de software bsico todava est con nosotros, y la nocin de la subrutina cerrada sigue siendo uno de los conceptos clave en la programacin. Debemos reconocer las subrutinas cerrados como una de las mayores invenciones de software, sino que ha sobrevivido a tres generaciones de computadoras y que va a sobrevivir un poco ms, ya que es apto para la aplicacin de uno de los patrones bsicos de la abstraccin. Lamentablemente suficiente, su importancia ha sido subestimado en el diseo de los equipos de tercera generacin, en la que el gran nmero de registros nombrados explcitamente de la unidad aritmtica implica una gran sobrecarga en el mecanismo de subrutina. Pero incluso eso no mat al concepto de la subrutina, y slo podemos rezar para que la mutacin no resultar ser hereditaria. El segundo acontecimiento importante en la escena software que me gustara mencionar es el nacimiento de FORTRAN. En ese momento se trataba de un proyecto de gran temeridad y la gente responsable de ello merecen nuestra admiracin. Sera absolutamente injusto culpar por las deficiencias que slo se hicieron evidentes despus de una dcada de uso extensivo: los grupos con un acertado look-ahead de diez aos son muy raros! En retrospectiva, debemos votar FORTRAN como una tcnica de codificacin exitosa, pero con muy pocas ayudas eficaces a la concepcin, las ayudas que ahora se necesita con urgencia que el tiempo ha venido a considerar fuera de fecha. Cuanto ms pronto se puede olvidar que FORTRAN ha existido nunca, mejor, porque como vehculo de pensamiento ya no es suficiente: se desperdicia nuestra capacidad intelectual, es demasiado arriesgado y por lo tanto muy costoso. Destino trgico FORTRAN ha sido su amplia aceptacin, mental miles y miles de encadenamiento de los programadores a nuestros errores del pasado. Rezo todos los das que ms de mis compaeros programadores pueden encontrar los medios para librarse de la maldicin de la compatibilidad. El tercer proyecto que no me gustara dejar sin mencionar es LISP, una empresa fascinante de una naturaleza completamente diferente. Con unos pocos principios muy bsicos en su fundacin, se ha mostrado una notable estabilidad. Adems de eso, LISP ha sido el soporte para un nmero considerable de en un sentido nuestras aplicaciones informticas ms sofisticadas. LISP broma ha sido descrita como "la forma ms inteligente de hacer mal uso de un ordenador". Creo que la descripcin de un gran elogio porque transmite todo el sabor de la liberacin: se ha prestado asistencia a varios de nuestros compaeros humanos con ms talento en el pensamiento de los pensamientos que antes era imposible. El cuarto proyecto que debe mencionarse es ALGOL 60. Mientras que hasta el da de hoy los programadores de FORTRAN todava tienden a entender el lenguaje de programacin en funcin de la aplicacin especfica para la que est trabajando, de ah el predominio de octal y hexadecimal vertederos, mientras que la definicin de LISP es todava una curiosa mezcla de lo que el lenguaje significa y cmo funciona el mecanismo, el famoso Informe sobre el lenguaje algortmico ALGOL 60 es el fruto de un esfuerzo genuino para llevar abstraccin un paso vital ms all y definir un lenguaje de programacin de una manera independiente de la implementacin. Se podra argumentar que en este sentido sus autores han tenido tanto xito que ellos han creado serias dudas en cuanto a si se podra aplicar a todos! El informe gloriosamente demostr el poder de la BNF mtodo formal, ya bastante conocido como Backus-Naur Form, y el poder de su enunciado cuidadosamente Ingls, por

lo menos una cuando es utilizado por alguien tan brillante como Peter Naur. Creo que es justo decir que slo muy pocos documentos tan cortos como este ha tenido una influencia igualmente profundo en la comunidad informtica. La facilidad con que en los ltimos aos los nombres de Algol y ALGOL-como se han utilizado, como una marca sin proteccin, para dar algo de su gloria a una serie de proyectos relacionados a veces apenas ms jvenes, es un cumplido algo chocante para su pie. La fuerza del BNF como un dispositivo que define es responsable de lo que considero como una de las debilidades de la lengua: una sobre-elaborado y no demasiado sintaxis sistemtico ahora podra ser metidos en los confines de muy pocas pginas. Con un dispositivo tan poderoso como el BNF, el Informe sobre el lenguaje algortmico ALGOL 60 debera haber sido mucho ms corta. Adems de que me estoy haciendo muy dudoso acerca mecanismo parmetro ALGOL 60: permite que el programador combinatoria tanta libertad, que su uso seguro requiere de una fuerte disciplina del programador. Adems costoso de implementar parece peligroso. Por ltimo, aunque el tema no sea agradable, debo mencionar PL / 1, un lenguaje de programacin para que la documentacin que establece es de un tamao aterrador y complejidad. El uso de PL / 1 debe ser como volar un avin con 7000 botones, interruptores y asas para manipular en la cabina. Estoy totalmente de no ver cmo podemos mantener nuestros programas de crecimiento firmemente dentro de nuestro dominio intelectual cuando por su barroquismo puro el lenguaje de programacin, nuestra herramienta bsica, que conste - ya escapa a nuestro control intelectual. Y si tengo que describir la influencia PL / 1 puede tener sobre sus usuarios, la metfora ms prxima que me viene a la mente es la de una droga. Me acuerdo de un simposio sobre el lenguaje de programacin de alto nivel de una conferencia dada en defensa de PL / 1 por un hombre que se present como uno de sus usuarios dedicados. Pero en una conferencia de una hora en la alabanza de PL / 1. se las arregl para pedir la adicin de alrededor de cincuenta nuevas "caractersticas", poco suponiendo que la fuente principal de sus problemas podran muy bien ser que no contena ya demasiadas "caractersticas". El orador se muestra todos los sntomas depresivos de la adiccin, la reduccin de como era el estado de estancamiento mental en el que slo se puede pedir ms, ms, ms ... Cuando FORTRAN se ha llamado una enfermedad infantil, lleno PL / 1, con sus caractersticas de crecimiento de un tumor peligroso, podra llegar a ser una enfermedad fatal. Hasta aqu el pasado. Pero no hay ningn punto en cometer errores a no ser que a partir de entonces somos capaces de aprender de ellos. Como cuestin de hecho, creo que hemos aprendido tanto, que dentro de unos aos la programacin puede ser una actividad muy diferente de lo que ha sido hasta ahora, tan diferente que ser mejor que nos preparemos para el choque. Permtanme esbozar para ustedes uno de los futuros posssible. A primera vista, esta visin de la programacin tal vez ya en un futuro prximo puede te parece absolutamente fantstico. Por ello, permtanme aadir tambin las consideraciones que pueden llevar a la conclusin de que esta visin podra ser una posibilidad muy real. La visin es que, mucho antes de los aos setenta se han ejecutado hasta el final, seremos capaces de disear y poner en prctica el tipo de sistemas que ahora estn tensos nuestra capacidad de programacin, a costa de slo un pequeo porcentaje en aos-hombre de lo que cuestan nosotros ahora, y que adems de eso, estos sistemas sern prcticamente libre de errores. Estas dos mejoras van de la mano. En el software de este ltimo aspecto parece

ser diferente de muchos otros productos, donde por regla general una mejor calidad implica un precio ms alto. Los que quieren realmente fiable software descubrirn que tienen que encontrar la manera de evitar la mayora de los insectos para empezar, y como resultado del proceso de programacin ser ms barato. Si desea ms eficaces programadores, descubrir que no deberan perder su tiempo de depuracin, no se deben introducir los insectos para empezar. En otras palabras: los dos objetivos apuntan a la misma modificacin. Un cambio drstico en un perodo tan corto de tiempo sera una revolucin, ya todas las personas que basan sus expectativas para el futuro en la extrapolacin sin problemas del pasado reciente, atractivo para algunas leyes no escritas de la inercia social y cultural-la posibilidad de que esta cambio drstico tendr lugar debe parecer insignificante. Pero todos sabemos que a veces las revoluciones se llevan a cabo! Y cules son las posibilidades de que ste? Parece que hay tres condiciones principales que deben cumplirse. El mundo en general debe reconocer la necesidad del cambio, en segundo lugar la necesidad econmica de que debe ser lo suficientemente fuerte, y, en tercer lugar, el cambio debe ser tcnicamente factible. Permtanme hablar de estas tres condiciones en el orden anterior. En lo que respecta al reconocimiento de la necesidad de una mayor fiabilidad de software, espero que ningn desacuerdo ms. Slo hace unos aos, esto era diferente: hablar de una crisis del software era una blasfemia. El punto de inflexin fue la Conferencia de Ingeniera del Software en Garmisch, octubre de 1968, una conferencia que caus sensacin, ya que se produjo la primera admisin abierta de la crisis del software. Y por ahora se reconoce generalmente que el diseo de cualquier sistema sofisticado grande va a ser un trabajo muy difcil, y cada vez que uno se encuentra con personas responsables de dichas empresas, se los encuentra muy preocupado por la cuestin de la fiabilidad, y con razn. En resumen, nuestra primera condicin parece estar satisfecho. Ya por la necesidad econmica. Hoy en da se encuentra con frecuencia la opinin de que en la programacin de los sesenta ha sido una profesin pagada en exceso, y que en los prximos aos los sueldos de programador se puede esperar para bajar. Por lo general, esta opinin se expresa en relacin con la recesin, pero podra ser un sntoma de algo diferente y muy saludable, a saber. que tal vez los programadores de la ltima dcada no ha hecho tan buen trabajo como deberan haber hecho. La sociedad es cada vez satisfecho con el rendimiento de los programadores y de sus productos. Pero hay otro factor de peso mucho mayor. En la situacin actual, es bastante habitual que para un sistema especfico, el precio a pagar para el desarrollo del software es del mismo orden de magnitud que el precio del hardware necesario, y la sociedad ms o menos lo acepta. Pero los fabricantes de hardware nos dicen que en los precios del hardware prxima dcada se espera que caiga por un factor de diez. Si el desarrollo de software fuera a seguir siendo el mismo proceso torpe y caro como lo es ahora, las cosas se pondran completamente fuera de balance. No se puede esperar que la sociedad a aceptar esto, y por lo tanto debemos aprender a programar un orden de magnitud mayor eficacia. Para decirlo de otra manera: mientras las mquinas fueron la partida ms importante del presupuesto, la profesin de programacin podra salirse con sus tcnicas torpes, pero ese paraguas se pliega rpidamente. En fin, tambin nuestra segunda condicin parece estar satisfecho.

Y ahora la tercera condicin: es tcnicamente factible? Yo creo que puede y le dar seis argumentos en apoyo de esa opinin. Un estudio de la estructura del programa ha puesto de manifiesto que los programas-incluso programas alternativos para la misma tarea y con el mismo contenido matemtico, pueden diferir enormemente en su capacidad de gestin intelectual. Una serie de normas han sido descubiertos, la violacin de que, o bien perjudicar seriamente o destruir totalmente la capacidad de gestin intelectual del programa. Estas normas son de dos tipos. Los del primer tipo son fciles de imponer mecnicamente, a saber. por un lenguaje de programacin elegido adecuadamente. Algunos ejemplos son la exclusin de Gotodeclaraciones y de los procedimientos con el parmetro ms de una salida. Para los de la segunda clase I, por lo menos, pero eso puede ser debido a la falta de competencia de mi lado, no veo forma de imponer mecnicamente, ya que parece que necesita algn tipo de demostrador de teoremas automtico para las que no tengo pruebas existencia. Por lo tanto, por el momento, y tal vez para siempre, las reglas de la segunda clase se presentan como elementos de disciplina requeridos desde el programador. Algunas de las reglas que tengo en mente son tan claras que se puede ensear y que nunca debe ser un argumento acerca de si un determinado programa que viole o no. Ejemplos de ello son los requisitos que ningn bucle deben estar por escrito sin aportar una prueba para la terminacin sin indicar ni la relacin que invariacin no ser destruido por la ejecucin de la sentencia repetible. Ahora sugiero que nos limitemos al diseo e implementacin de programas intelectualmente manejables. Si alguien teme que esta restriccin es tan grave que no podemos vivir con l, puedo tranquilizarlo: la clase de programas intelectualmente manejables es todava bastante rico como para contener muchos programas muy realistas para cualquier problema de capacidad de solucin algortmica. No debemos olvidar que no es nuestro negocio para hacer programas, es nuestro negocio para disear clases de clculos que muestran un comportamiento deseado. La sugerencia de limitndonos a los programas intelectualmente manejables es la base para los primeros dos de mis anunci seis argumentos. El argumento es que uno, ya que el programador slo necesita considerar los programas intelectualmente manejables, las alternativas que se eligen entre son mucho, mucho ms fcil de manejar. Argumento dos es que, tan pronto como hemos decidido limitarnos al subconjunto de los programas intelectualmente manejables, hemos logrado, de una vez por todas, una drstica reduccin del espacio de solucin a considerar. Y este argumento es distinto de un argumento. Argumento tres se basa en la actitud constructiva al problema de la correccin del programa. Hoy en da una tcnica habitual es hacer un programa y despus de probarlo. Pero: programa de pruebas puede ser una forma muy efectiva de mostrar la presencia de errores, pero es completamente inadecuado para demostrar su ausencia. La nica manera eficaz de aumentar el nivel de confianza de un programa de manera significativa es dar una prueba convincente de su exactitud. Pero no se deben hacer primero el programa y luego probar su correccin, porque entonces el requisito de aportar la prueba no hara sino aumentar la

carga del programador pobre. Por el contrario, el programador debe permitir la correccin y la prueba de programa crecer de la mano. Argumento tres se basa esencialmente en la observacin siguiente. Si primero se pregunta cul es la estructura de una prueba convincente sera y, despus de haber encontrado esto, entonces construye un programa de satisfaccin de los requisitos de esta prueba, entonces estos problemas de regularidad que resultan ser una gua heurstica muy eficaz. Por definicin, este mtodo slo es aplicable cuando nos restringimos a los programas intelectualmente manejables, pero que nos proporciona medios efectivos para la bsqueda de una satisfactoria entre estos. Argumento cuatro tiene que ver con la forma en que la cantidad de esfuerzo intelectual necesario para disear un programa depende de la duracin del programa. Se ha sugerido que existe una especie de ley de la naturaleza que nos dice que la cantidad de esfuerzo intelectual necesario crece con el cuadrado de la longitud del programa. Pero, gracias a Dios, nadie ha sido capaz de demostrar esta ley. Y esto se debe a que no tiene por qu ser cierto. Todos sabemos que la nica herramienta mental por medio de la cual una parte muy limitada de razonamiento puede cubrir una multitud de casos se denomina "abstraccin", y como resultado la explotacin efectiva de su poder de abstraccin debe ser considerada como una de las actividades ms importantes de un programador competente. En este sentido, valdra la pena-mientras que sealar que el propsito de la abstraccin no es ser vago, sino para crear un nuevo nivel semntico en el que se puede ser absolutamente preciso. Por supuesto, he intentado encontrar una causa fundamental que evitar que nuestros mecanismos de abstraccin de ser suficientemente eficaces. Pero no importa lo mucho que lo intentara, no encontramos una causa. Como resultado de ello me inclino a suponer-hasta ahora no ha sido desvirtuado por la experiencia que por la aplicacin adecuada de nuestra capacidad de abstraccin, el esfuerzo intelectual necesario para concebir o entender un programa no necesita crecer ms que proporcional a la duracin del programa. Sin embargo, un subproducto de estas investigaciones pueden ser de mucha mayor importancia prctica, y es, de hecho, la base de mi argumento cuarto. El subproducto fue la identificacin de un nmero de patrones de abstraccin que desempean un papel vital en el proceso de los programas que componen. Basta que hoy se conoce acerca de estos patrones de abstraccin que podra dedicar una conferencia a cerca de cada uno de ellos. Lo que la familiaridad y el conocimiento consciente de estos patrones de abstraccin implica amaneci sobre m cuando me di cuenta de que, de haber sido el conocimiento comn, hace quince aos, el paso de BNF para los compiladores dirigida por la sintaxis, por ejemplo, podra haber tomado unos minutos en lugar de unos pocos aos. Por lo tanto, presentamos nuestro reciente conocimiento de los patrones de abstraccin tan vitales como el cuarto argumento. Ahora, para el quinto argumento. Tiene que ver con la influencia de la herramienta que estamos tratando de usar a nuestros hbitos de pensamiento propios. Observo una tradicin cultural, que con toda probabilidad, tiene sus races en el Renacimiento, ignorar esta influencia, a considerar la mente humana como el maestro supremo y autnomo de sus artefactos. Pero si me pongo a analizar los hbitos de pensamiento de m mismo y de mis prjimos, vengo, me guste o no, a una conclusin completamente diferente, a saber. que las herramientas que estn tratando de utilizar y el lenguaje o notacin que utilizamos para expresar o registrar nuestros pensamientos, son los principales factores que determinan lo que podemos pensar o expresar en absoluto! El anlisis de la influencia que tienen los

lenguajes de programacin en los hbitos de pensamiento de sus usuarios, y el reconocimiento de que, por ahora, la capacidad intelectual es, con mucho, nuestro recurso ms escaso, que juntos nos dan una nueva coleccin de criterios para comparar los mritos relativos de los diferentes programas idiomas. The competent programmer is fully aware of the strictly limited size of his own skull; therefore he approaches the programming task in full humility, and among other things he avoids clever tricks like the plague. In the case of a well-known conversational programming language I have been told from various sides that as soon as a programming community is equipped with a terminal for it, a specific phenomenon occurs that even has a well-established name: it is called "the one-liners". It takes one of two different forms: one programmer places a one-line program on the desk of another and either he proudly tells what it does and adds the question "Can you code this in less symbols?" as if this were of any conceptual relevance! or he just asks "Guess what it does!". From this observation we must conclude that this language as a tool is an open invitation for clever tricks; and while exactly this may be the explanation for some of its appeal, viz. to those who like to show how clever they are, I am sorry, but I must regard this as one of the most damning things that can be said about a programming language. Another lesson we should have learned from the recent past is that the development of "richer" or "more powerful" programming languages was a mistake in the sense that these baroque monstrosities, these conglomerations of idiosyncrasies, are really unmanageable, both mechanically and mentally. I see a great future for very systematic and very modest programming languages. When I say "modest", I mean that, for instance, not only ALGOL 60's "for clause", but even FORTRAN's "DO loop" may find themselves thrown out as being too baroque. I have run aa little programming experiment with really experienced volunteers, but something quite unintended and quite unexpected turned up. None of my volunteers found the obvious and most elegant solution. Upon closer analysis this turned out to have a common source: their notion of repetition was so tightly connected to the idea of an associated controlled variable to be stepped up, that they were mentally blocked from seeing the obvious. Their solutions were less efficient, needlessly hard to understand, and it took them a very long time to find them. It was a revealing, but also shocking experience for me. Finally, in one respect one hopes that tomorrow's programming languages will differ greatly from what we are used to now: to a much greater extent than hitherto they should invite us to reflect in the structure of what we write down all abstractions needed to cope conceptually with the complexity of what we are designing. So much for the greater adequacy of our future tools, which was the basis of the fifth argument. As an aside I would like to insert a warning to those who identify the difficulty of the programming task with the struggle against the inadequacies of our current tools, because they might conclude that, once our tools will be much more adequate, programming will no longer be a problem. Programming will remain very difficult, because once we have freed ourselves from the circumstantial cumbersomeness, we will find ourselves free to tackle the problems that are now well beyond our programming capacity. You can quarrel with my sixth argument, for it is not so easy to collect experimental evidence for its support, a fact that will not prevent me from believing in its validity. Up till now I have not mentioned the word "hierarchy", but I think that it is fair to say that this is a key concept for all systems embodying a nicely factored solution. I could even go one step further and make an article of faith out of it, viz. that the only problems we can really solve

in a satisfactory manner are those that finally admit a nicely factored solution. At first sight this view of human limitations may strike you as a rather depressing view of our predicament, but I don't feel it that way, on the contrary! The best way to learn to live with our limitations is to know them. By the time that we are sufficiently modest to try factored solutions only, because the other efforts escape our intellectual grip, we shall do our utmost best to avoid all those interfaces impairing our ability to factor the system in a helpful way. And I cannot but expect that this will repeatedly lead to the discovery that an initially untractable problem can be factored after all. Anyone who has seen how the majority of the troubles of the compiling phase called "code generation" can be tracked down to funny properties of the order code, will know a simple example of the kind of things I have in mind. The wider applicability of nicely factored solutions is my sixth and last argument for the technical feasibiilty of the revolution that might take place in the current decade. En principio se lo dejo a usted para decidir por ti mismo cunto peso vas a dar a mis consideraciones, sabiendo muy bien que me puede obligar a nadie a compartir mis creencias. As each serious revolution, it will provoke violent opposition and one can ask oneself where to expect the conservative forces trying to counteract such a development. I don't expect them primarily in big business, not even in the computer business; I expect them rather in the educational institutions that provide today's training and in those conservative groups of computer users that think their old programs so important that they don't think it worth-while to rewrite and improve them. In this connection it is sad to observe that on many a university campus the choice of the central computing facility has too often been determined by the demands of a few established but expensive applications with a disregard of the question how many thousands of "small users" that are willing to write their own programs were going to suffer from this choice. Too often, for instance, high-energy physics seems to have blackmailed the scientific community with the price of its remaining experimental equipment. The easiest answer, of course, is a flat denial of the technical feasibility, but I am afraid that you need pretty strong arguments for that. No reassurance, alas, can be obtained from the remark that the intellectual ceiling of today's average programmer will prevent the revolution from taking place: with others programming so much more effectively, he is liable to be edged out of the picture anyway. There may also be political impediments. Even if we know how to educate tomorrow's professional programmer, it is not certain that the society we are living in will allow us to do so. The first effect of teaching a methodology rather than disseminating knowledge is that of enhancing the capacities of the already capable, thus magnifying the difference in intelligence. In a society in which the educational system is used as an instrument for the establishment of a homogenized culture, in which the cream is prevented from rising to the top, the education of competent programmers could be politically impalatable. Permtanme concluir. Automatic computers have now been with us for a quarter of a century. They have had a great impact on our society in their capacity of tools, but in that capacity their influence will be but a ripple on the surface of our culture, compared with the much more profound influence they will have in their capacity of intellectual challenge without precedent in the cultural history of mankind. Hierarchical systems seem to have the property that something considered as an undivided entity on one level, is considered as a composite object on the next lower level of greater detail; as a result the natural grain of

space or time that is applicable at each level decreases by an order of magnitude when we shift our attention from one level to the next lower one. We understand walls in terms of bricks, bricks in terms of crystals, crystals in terms of molecules etc. As a result the number of levels that can be distinguished meaningfully in a hierarchical system is kind of proportional to the logarithm of the ratio between the largest and the smallest grain, and therefore, unless this ratio is very large, we cannot expect many levels. In computer programming our basic building block has an associated time grain of less than a microsecond, but our program may take hours of computation time. I do not know of any other technology covering a ratio of 10 10 or more: the computer, by virtue of its fantastic speed, seems to be the first to provide us with an environment where highly hierarchical artefacts are both possible and necessary. This challenge, viz. the confrontation with the programming task, is so unique that this novel experience can teach us a lot about ourselves. It should deepen our understanding of the processes of design and creation, it should give us better control over the task of organizing our thoughts. If it did not do so, to my taste we should not deserve the computer at all! It has already taught us a few lessons, and the one I have chosen to stress in this talk is the following. We shall do a much better programming job, provided that we approach the task with a full appreciation of its tremendous difficulty, provided that we stick to modest and elegant programming languages, provided that we respect the intrinsic limitations of the human mind and approach the task as Very Humble Programmers.