Novedades en la categoría Personajes

Hay mucha gente a la que le encanta establecer analogías (o isomorfismos como los llama Pepe Flores), para explicar nuevos conceptos, o ideas. Pero en realidad esa manera de pensar siempre falla cuando nos enfrentamos con conceptos que son "novedades radicales".

Al respecto quiero compartir este texto de Dijsktra donde explica mucho mejor esto:

La manera usual en la cual hoy planificamos para el mañana es en el vocabulario de ayer. Lo hacemos porque tratamos de avanzar con los conceptos que nos son familiares, los cuales han adquirido un significado en nuestra experiencia pasada. Por supuesto, las palabras y los conceptos no encajan precisamente porque nuestro futuro difiere de nuestro pasado, pero las estiramos un poco. Los lingüistas están bastante familiarizados con el fenómeno en el cual los significados de las palabras evolucionan a través del tiempo, pero también saben que este es un proceso lento y gradual.

Es el método más común cuando se trata de lidiar con la novedad: utilizando metáforas y analogías tratamos de vincular lo nuevo con lo viejo, lo novedoso con lo familiar. Bajo un cambio suficientemente lento y gradual, esto funciona razonablemente bien; en el caso de una discontinuidad aguda, sin embargo, el método colapsa: aunque podemos glorificarlo con el nombre "sentido común", nuestra experiencia pasada ya no es más relevante, las analogías se tornan muy superficiales, y las metáforas se hacen engañosas en vez de reveladoras. Esta es la situación que caracteriza a la novedad "radical".

Lidiar con una novedad radical requiere un método ortogonal. Uno debe considerar su propio pasado, las experiencias recogidas, y los hábitos formados en él como un desafortunado accidente de la historia, y debe acercarse a la novedad radical con la mente en blanco, rechazando conscientemente el intento de vincularla con lo que ya es familiar, debido a que lo familiar es desesperanzadamente inadecuado. Uno debe, con una especie de personalidad dividida, tomar una novedad radical como algo desasociado por propio derecho. Comprender una novedad radical implica crear y aprender un lenguaje extraño, el cual no puede ser traducido a nuestra lengua materna. (Cualquiera que haya aprendido mecánica cuántica sabe a lo que me refiero.) No hace falta decirlo, ajustarse a las novedades radicales no es una actividad muy popular, ya que requiere mucho trabajo. Por la misma razón, las novedad radicales no son por sí mismas bienvenidas.

A esta altura, bien se pueden preguntar por qué he prestado tanta atención y he gastado tanta elocuencia en una noción tan simple y obvia como una novedad radical. Mi razón es muy simple: las novedades radicales son tan perturbantes que tienden a ser suprimidas o ignoradas, al punto que la mera posibilidad de su existencia es generalmente negada antes que admitida.

Voy a ser breve en cuanto a la evidencia histórica. Carl Friedrich Gauss, el Príncipe de los Matemáticos pero algo cobarde, sin duda estaba al tanto del destino de Galileo -y probablemente podría haber predicho las acusaciones a Einstein- cuando decidió suprimir su descubrimiento de la geometría no Euclidiana, dejando que Bolyai y Lobatchewsky recibieran las críticas. Es probablemente más revelador ir un poco más atrás, a la Edad Media. Una de sus características era que "razonar mediante analogías" era descontrolado; otra característica era el total estancamiento intelectual, y ahora vemos porque ambas características van juntas. Una razón para mencionar esto es resaltar que, desarrollando un oído entrenado para las analogías no garantizadas, uno puede detectar una gran cantidad de pensamiento medieval hoy en día.

...

El concepto de novedades radicales es de importancia contemporánea ya que, mientras estamos mal preparados para lidiar con ellas, la ciencia y la tecnología no se han mostrado expertas en influirlas sobre nosotros. Ejemplos científicos antiguos son la teoría de la relatividad y la mecánica cuántica; ejemplos tecnológicos modernos son la bomba atómica y la píldora. Durante décadas, los primeros dos ejemplos dieron lugar a un torrente de corrientes religiosas, científicas o de otra manera cuasi-científicas. Día a día podemos observar el profundo error de enfoque con el cuál los últimos dos ejemplos han sido abordados, ya sea por nuestros políticos y líderes religiosos o por el público en general. Demasiado para el daño hecho a nuestra paz mental por las novedades radicales.

Fuente: http://www.smaldone.com.ar/documentos/ewd/sobre_la_crueldad.html

¿Y por que es tan importante esto?

Porque la naturaleza del software es una novedad radical, dejemos al mismo Dijsktra explicarlo:

Traje esto a colación debido a mi convencimiento de que las computadoras automáticas representan una novedad radical y de que sólo identificándolas como tal podemos identificar todo lo irrelevante, los conceptos errados y la mitología que las rodea. ...

La primera novedad radical es una consecuencia directa del poder bruto de las computadoras actuales. Todos sabemos como lidiar con algo tan grande y complejo; divide y vencerás, por ejemplo vemos el todo como una composición de partes y tratamos con las partes por separado. Y si una parte es muy grande, repetimos el procedimiento. La ciudad está compuesto por barrios, que están a su vez estructurados por calles, que contienen edificios, que están hechos de paredes y pisos, que están construidas de ladrillos, etc. eventualmente llegando a las partículas elementales. Y tenemos a todos nuestros especialistas sobre el tema, desde el ingeniero civil, pasando por el arquitecto hasta el físico de estado sólido y consiguientes. Ya que, en cierto sentido, el todo es "mas grande" que sus partes, la profundidad de una descomposición jerárquica es algún tipo de logaritmo del cociente entre los "tamaños" del todo y las partes más pequeñas. Desde un bit a cien mega bytes, desde un microsegundo a media hora de cómputos nos confronta con un cociente completamente abrumador de 10^9! 

El programador está en la posición inigualada en la cual la suya es la única disciplina y profesión donde un cociente tan gigante, lo cual completamente sobrepasa nuestra imaginación, debe ser consolidado por una sola tecnología. Debe poder pensar en términos de jerarquías conceptuales que son mucho más profundas que todas aquellas que debió enfrentar una sola mente alguna vez. Comparado con ese número de niveles semánticos, la teoría matemática promedio es casi plana. Evocando la necesidad de profundas jerarquías conceptuales, la computadora automática nos confronta con un radical desafío intelectual que no tiene precedente histórico.

Como estamos ante una novedad radical, no podemos seguir pensando en el desarrollo de software de la manera analógica (en el sentido de hacer analogías) como se ha hecho hasta ahora.

Las metáforas del constructor, o del arquitecto, o del ingeniero no funcionan con el desarrollo de software. Hay que pensar de una forma distinta, hay que aceptar la novedad radical y aceptar que la nuestra es una profesión radicalmente distinta a todas las que han habido antes.

Pienso que uno de los mejores argumentos en contra de la noción de crisis de software fue dada indirectamente por Edsger W. Dijkstra, en su charla de 1988 "ON THE CRUELTY OF REALLY TEACHING COMPUTIN SCIENCE"

Cierta cantidad de estos fenómenos han sido agrupados bajo el nombre de "Ingeniería de Software". Así como la economía es conocida como "La Ciencia Miserable", la ingeniería de software debería ser conocida como "La Disciplina Condenada", condenada porque ni siquiera puede acercarse a su meta, dado que la misma es en sí misma contradictoria. La ingeniería de software, por supuesto, se presenta a sí misma como otra causa valiosa, pero es un colirio: si lee cuidadosamente su literatura y analiza lo que realmente hacen quienes se avocan a ella, descubrirá que la ingeniería de software ha adoptado como su estatuto "Cómo programar si usted no puede".

...

La práctica está impregnada de la confortable ilusión de que los programas son simplemente dispositivos como cualquier otro, la única diferencia que se admite es que su fabricación pueden requerir un nuevo tipo de expertos, a saber: programadores. Desde allí hay sólo un pequeño paso hasta medir la "productividad del programador" en términos de la "cantidad de líneas producidas por mes". Esta es una unidad de medida muy costosa, porque anima a escribir código insípido, pero hoy estoy menos interesado en qué tan tonta es una unidad, aún desde un punto de vista puramente empresarial. Mi punto hoy es que, si deseamos contar líneas de código, no deberíamos verlas como "líneas producidas", sino como "líneas gastadas": el sentido común actual es tan tonto como contabilizar esa cuenta del lado erróneo del balance.

Además de la noción de productividad, también el control de calidad sigue estando distorsionado por la confortable ilusión de que funciona con otros aparatos como lo hace con los programas. Han pasado ya dos décadas desde que se señaló que el testing de programas puede convincentemente demostrar la presencia de errores, pero nunca puede demostrar su ausencia. Después de citar devotamente este comentario bien publicitado, el ingeniero de software vuelve al orden del día y continúa refinando sus estrategias de testing, tal como el alquimista de antaño, quien continuaba refinando sus purificaciones crisocósmicas.

Un profundo malentendido es luego revelado por el término "mantenimiento de software", como resultado del cual muchas personas siguen creyendo que los programas -e inclusive los mismísimos lenguajes de programación- están sujetos a desgaste y ruptura. Su auto también necesita mantenimiento, ¿no es así? Es famosa la historia de la empresa petrolera que creía que sus programas PASCAL no durarían tanto como sus programas FORTRAN "porque PASCAL no estaba mantenido".

En el mismo sentido debo llamar la atención sobre la sorprendente facilidad con que se ha aceptado la sugerencia de que los males de la producción de software de deben, en gran medida, a la falta de "herramientas de programación" apropiadas. (Pronto aparecería la frase "banco de trabajo del programador".) Nuevamente, la chatura de la analogía subyacente se debe a la Edad Media. Las confrontaciones con las insípidas "herramientas" del tipo de "animación de algoritmos" no ha suavizado mi juicio; por el contrario, ha confirmado mi sospecha inicial de que estamos tratando principalmente con otra dimensión del negocio del aceite de serpientes.

Texto completo en castellano disponible en el sitio de Javier Smaldone.

Lo que no se entiende aún es que el desarrollo de software no es como la construcción de objetos, y esta naturaleza fundamentalmente distinta es la que lleva a errores al tratar de definir el éxito o fracaso de un proyecto de desarrollo de software.

La programación de computadores como un arte

Por Donald Knuth, 1974

(Lee las partes I, II, III y IV)

Menos Facilidades: Más Diversión

Una cosa bastante curiosa que he notado sobre la satisfacción estética es que nuestro placer es significativamente mayor cuando logramos algo con herramientas limitadas. Por ejemplo, el programa del que personalmente estoy muy contento y orgulloso es un compilador de que una vez escribí para una minicomputadora primitiva, que sólo tenía 4096 palabras de memoria, 16 bits por palabra. Una persona se siente como un virtuoso real al lograr algo con tan severas restricciones.

Un fenómeno similar ocurre en muchos otros contextos. Por ejemplo, las personas parecen más a menudo enamorarse de su Volkswagen, pero rara vez con su Continental Lincoln (que probablemente funcionen mucho mejor). Cuando aprendí programación, era un pasatiempo popular hacer todo lo posible con programas que cupieran sólo en una tarjeta perforada. Supongo que es el mismo fenómeno que hace que los entusiastas de APL gocen con sus "one-liners". Cuando enseñamos a la programación hoy en día, es curioso el hecho de que rara vez se captura el corazón de un estudiante de ciencias de la computación hasta que ha tomado un curso que le permite "meter las manos" y ganar experiencia con un miniordenador. El uso de nuestras máquinas a gran escala con sus sistemas operativos y lenguajes de fantasía en realidad no parece generar ningún amor por la programación, por lo menos no al principio.

No está claro cómo aplicar este principio para aumentar el disfrute de los programadores en su trabajo. Seguramente los programadores gruñrán si su administrador de repente les anuncia que la nueva máquina tendrá sólo la mitad de memoria que la antigua. Y yo no creo que nadie, ni siquiera los más dedicados "artistas de programación", vayan a dar la bienvenida a esta perspectiva, ya que a nadie le gusta perder las instalaciones de manera innecesaria. Otro ejemplo puede ayudar a aclarar la situación: Los cineastas se opusieron firmemente a la introducción del cine sonoro en la década de 1920 porque estaban orgullosos de la forma en que podían transmitir palabras sin sonido. Del mismo modo, un artista de programación bien podría resentirse de la introducción de equipos más poderosos, los dispositivos de almacenamiento masivo de hoy en día suelen echar a perder gran parte de la belleza de nuestros viejos métodos de ordenamiento en cintas. Pero los cineastas de hoy no quieren volver a las películas mudas, no porque sean perezosos, sino porque saben que es muy posible hacer películas bellas utilizando tecnología mejorada. La forma de su arte ha cambiado, pero todavía hay mucho espacio para el arte. 

¿Cómo desarrollaron estas habilidades? Los mejores realizadores de películas a través de los años por lo general parecen haber aprendido su arte en relativamente primitivas circunstancias, a menudo en países con una industria cinematográfica limitada. Y en años recientes las cosas más importantes que hemos estado aprendiendo sobre programación parecen tener su origen en personas que no tienen acceso a computadores muy grandes. La moraleja de esta historia, me parece, es que debemos hacer uso de la idea de recursos limitados en nuestra propia educación. Todos podemos beneficiarnos de hacer de vez en cuando "programas de juguete", cuando las restricciones artificiales se establecen, de manera que nos vemos obligados a impulsar nuestra capacidad hasta el límite. No debemos vivir en el regazo del lujo todo el tiempo, ya que que tiende a ponernos letárgicos. El arte de la lucha contra los mini problemas con toda nuestra energía va a agudizar nuestro talento para los problemas reales, y los la experiencia nos ayudará a obtener más placer de nuestros logros en equipos menos restringidos.

En una vena similar, no debemos eludir "el arte por el arte", no debemos sentirnos culpables por los programas que son sólo para divertirse. Una vez logre un gran placer alescribir un programa de ALGOL de un sóla sentencia que invocaba un procedimiento de product interno de una manera tan inusual que calculaba el m-ésimo número primo, en lugar de un producto interno. Hace algunos años los estudiantes de Stanford estaban entusiasmados por encontrar el programa más corto en FORTRAN que se imprimiera a sí mismo, en el sentido de que la salida del programa es idéntico al texto de su propia fuente. El mismo problema fue considerado para muchos otros lenguajes. No creo que fuera una pérdida de tiempo para que puedan trabajar en esto, ni que Jeremy Bentham, a quien ya he citado antes, negará la "utilidad" de tales pasatiempos. "Por el contrario," él escribió, "no hay utilidad de que sea más incontestable. ¿En qué se da el carácter de una utilidad, si no es una fuente de placer?

Proveyendo Herramientas Hermosas

Otra característica del arte moderno es su énfasis en la creatividad. Parece que muchos artistas hoy en día no parece importarle tanto la creación de cosas bellas; sólo la novedad de una idea es lo importante. No estoy recomendando que la programación de computadoras deba ser como el arte moderno en este sentido, pero me lleva a una observación que me parece importante. A veces nos asignan una tarea de programación que es casi irremediablemente aburrida, lo que no nos exige en absoluto nada de creatividad, y en esos momentos las personas suelen venir a mí y me dicen: "¿Así que la programación es hermosa? Está muy bien para que usted daclame que uno debería tener el placer de la creación de programas elegantes y encantadores, pero ¿cómo se supone que voy a hacer de este desastre una obra de arte? "

Bueno, es cierto, no todas las tareas de programación van a ser divertidas. Tengan en cuenta a la "ama de casa atrapada", que tiene que limpiar la misma mesa cada día: no hay espacio para la creatividad o el arte en cada situación. Pero incluso en esos casos, hay una manera de hacer una gran mejora: todavía es un placer hacer trabajos de rutina, si tenemos cosas bellas para trabajar. Por ejemplo, una persona puede realmente disfrutar el limpiar la mesa del comedor, día tras día, si es una mesa hermosamente diseñada, a partir de madera de fina calidad.

Por lo tanto, quiero dirigir mis palabras de clausura a los programadores de sistemas y los diseñadores de máquinas que producen los sistemas conque el resto de nosotros debe trabajar. Por favor, déjenos herramientas que sean un placer de usar, especialmente para nuestras tareas de rutina, en lugar de ofrecer algo con lo que tengamos que luchar. Por favor, déjenos herramientas que nos animen a escribir mejor los programas, mediante la mejora de nuestro placer cuando lo hacemos.

Es muy dificil para mí convencer a jóvenes universitarios de que la programación es hermosa, cuando tengo que decirles que es como "slash slash JOB es igual a esto y esto." Aún los lenguajes de control pueden ser diseñados de modo que sea un placer usarlos, en vez de ser estrictamente funcionales.

Los diseñadores de hardware de computador pueden hacer que sus máquinas sean mucho más agradables de utilizar, por ejemplo, proporcionando aritmética de coma flotante que cumpla las leyes matemáticas simples. Las instalaciones disponibles en la actualidad en la mayoría de las máquinas hacen el trabajo de análisis de errores de manera rigurosa e irremediablemente difícil, pero las operaciones de diseño adecuado sería alentar a los analistas numéricos que proporcionaran una mejor subrutinas que hayan certificado la exactitud.

Vamos a considerar también lo que los diseñadores de software pueden hacer. Una de las mejores maneras de mantener arriba el espíritu de un usuario del sistema es proporcionar  las rutinas con las que se pueda interactuar. No debemos hacer que los sistemas sean demasiado automáticos, por lo que la acción va siempre detrás de las escenas, debemos dar el programador-usuario la oportunidad de dirigir su creatividad hacia canales útiles. Una cosa que todos los programadores tienen en común es que les gusta trabajar con las máquinas, así que vamos a mantengámoslo en el ciclo. Algunas de las tareas se hacen mejor con la máquina, mientras que otros se hacen mejor con la supervisión humana, y en un sistema bien diseñado se encuentra el equilibrio adecuado. (He estado tratando de evitar la automatización mal dirigida durante muchos años.)

Programar instrumentos de medición es un buen caso de ejemplo. Durante años, los programadores han sido inconscientes de cómo los costos reales de computación se distribuyen en sus programas. La experiencia indica que casi todo el mundo tiene una idea equivocada acerca de los verdaderos cuellos de botella en sus programas, no es de extrañar que los intentos de mejorar la eficiencia vayan mal tan a menudo, cuando a un programador no se le da un desglose de los gastos de acuerdo a las líneas de código que ha escrito. Su trabajo es algo así como la de una pareja de recién casados que intentan planificar un presupuesto equilibrado sin saber cuales serán los costos de los elementos individuales, como alimentos, vivienda y ropa. Todo lo que hemos estado dando a los programadores es un compilador de optimización, que misteriosamente hace algo a los programas que se traduce, pero que nunca explica lo que hace. Afortunadamente ahora estamos finalmente viendo la aparición de sistemas que le dan el crédito de usuario para una cierta inteligencia, sino que proporciona automáticamente la instrumentación de programas y la información apropiada sobre los costos reales. Estos sistemas experimentales han sido un gran éxito, ya que producen mejoras mensurables, y sobre todo porque es divertido de usar, así que confío en que es sólo cuestión de tiempo antes de que el uso de estos sistemas sea un procedimiento operativo estándar. Mi artículo en Computer Survey  discute esto aún más, y presenta algunas ideas para otras formas en que una rutina interactiva apropiada puede mejorar la satisfacción de los programadores usuarios.

Los diseñadores del lenguaje también tienen la obligación de proporcionar los lenguajes que fomenten un buen estilo, ya que todos sabemos que el estilo es fuertemente influenciado por el lenguaje en el que se expresa. La oleada actual de interés en la programación estructurada ha puesto de manifiesto que ninguno de nuestros lenguajes existentes es realmente idóneo para abordar el programa y la estructura de datos, ni tampoco está claro como debe ser un lenguaje ideal. Por lo tanto, espero que muchos hagan experimentos cuidadosos en el diseño el lenguaje durante los próximos años.

Resumen

En resumen, hemos visto que la programación de computadoras es un arte, porque se aplica el conocimiento acumulado en el mundo, porque requiere habilidad e ingenio, y especialmente, debido a que produce objetos hermosos. Un programador que inconscientemente, se ve a sí mismo como un artista disfrutará de lo que hace y lo hará mejor. Por lo tanto, podemos alegrarnos de que la gente que da charla en las conferencias de computación hable sobre  estado del arte.

La programación de computadores como un arte

Por Donald Knuth, 1974

(Lee las partes I, y II)

Ciencia y Arte

Nuestra discusión indica que la programación de computadores es para ahora ambas: una ciencia y un arte, y que los dos aspectos se complementan bien una con otra. Aparentemente muchos autores que examinan tal pregunta llegan a la misma conclusión, que su área de estudio es ambas una ciencia y un arte, cualquiera sea esta área. Encontré un libro sobre fotografía elemental, escrito en 1893, que decía "el desarrollo de la imagen fotográfica es ambas un arte y una ciencia." De hecho, cuando tomé primero un diccionario para estudiar las palabras "arte" y "ciencia" le eché un vistazo al prefacio del editor, el que empezaba diciendo, "la construcción de un diccionario es una ciencia y un arte a la vez". El editor del diccionario de Funk & Wagnall's dictionary observaba que la penosa acumulación y clasificación de los datos sobre las palabras tiene un carácter científico, mientras que un fraseo bien escogido para la definición demanda la habilidad de escribir con la economía y la precisión: "La ciencia sin este arte es probablemente inefectiva, el arte sin la ciencia es ciertamante inexacto."

Cuando preparaba esta charla miré las tarjetas del catálogo en la biblioteca de Standford para ver como otras personas han usado las palabras "arte" y "ciencia" en los títulos de sus libros. Esto resultó bastante interesante.

Por ejemplo, encontré dos libros titulados "El arte de Tocar el Piano" y otros llamados La Ciencia de la Técnica del Pianoforte, La Ciencia de la Práctica del Pianoforte. Hay también un libro llamado El Arte de tocar Piano: Una Aproximación Científica.

Entonces encontré un simpático librillo titulado El Gentil Arte de las Matemáticas, el que me puso algo tristre ya que honestamente no puedo describir la programación de computadores como un "arte gentil". He sabido por muchos años de un libro llamado El Arte de la Computación, publicado en San Francisco en 1879, por un hombre llamado C. Frusher Howard. Era un libro sobre aritmética práctica para los negocios que ha vendido sobre 400.00 copias en varias ediciones hacia 1890. Me asombré al leer el prefacio, pues muestra que la filosofía de Howard y la intención del título era bastante diferente de la mía, el escribe: "El conocimiento de la ciencia de los números es de la menor importancia, el arte de ajustar las cuentas es absolutamente indispensable."

Varios libros mencionan a ambas la ciencia y el arte en sus títulos, notablemente La Ciencia del Ser y el Arte de Vivir por el Maharishi Mahesh Yogi. Hay también un libro llamado El Arte del Descubrimiento Científico, el que analiza como algunos de los grandes descubrimientos de la ciencia se han hecho.

Suficiente de la palabra "arte" en su sentido clásico. Realmente cuando escogí el título de mis libros, yo no estaba pensando principalmente en arte en este sentido, estaba pensando más en sus connotaciones actuales. Probablemente el libro más interesante que inició mi búsqueda fue un trabajo reciente de Robert E. Mueller llamado La Ciencia del Arte. De todos los libros que he mencionado, el de Mueller es el que más se acerca a expresar lo que quiero hacer el tema central de mi charla hoy, en términos artísticos reales tales como entendemos ahora el término. El observa: "Una vez se pensó que las perspectivas imaginativas del artista eran la muetre del científico. Y la lógica de la ciencia parecía significar la perdición a todos los posibles vuelos de la imaginación artística." El continúa explorando las ventajas que resultan de la síntesis de la ciencia y el arte.

Una aproximación científica es caracterizada generalmente por las palabras lógica, sistemática, impersonal, calma, racional, mientras que la aproximación artística se caracteriza por la palabras estética, creativa, humanitaria, ansiosa, irracional. Me parece que esta aparente contradicción de aproximaciones tiene gran valor con respecto a la programación de los computadores.

Emma Lehmer escribió en 1956 que había encontrado que  la programación era "una ciencia exacta junto con un arte intrigante." H.S.M. Coxeter recordaba en 1957 que a veces se sentía "más como un artista que como un científico".  Estos eran los tiempos en que .P. Snow empezó a vocear su alarma sobre la creciente polarización de "las dos culturas" entre la gente educada. El apuntó que necesitamos combinar los valores científicos y artistico y queremos hacer progresos reales.

La programación de computadores como un arte

Por Donald Knuth

(lee la primera parte)

Ciencia versus Arte

La palabra "ciencia" parece haber sido usada por muchos años en el mismo sentido que "arte"; por ejemplo, la gente hablaba también de las siete ciencias liberales, que eran las mismas siete artes liberales. Duns Scotus en el siglo trece llamaba a la lógica "la ciencia de las ciencias, y el arte de los artes". Como la civilización y la enseñanza se desarrollaron, las palabras tomaron más y más sentidos independientes, "ciencia" se empezó a usar para el conocimiento, y "arte" para la aplicación del conocimiento. Luego, la ciencia de la astronomía era la base para el arte de la navegación. La situación era casi exactamente como la manera en que nosotros ahora distinguimos entre "ciencia" e "ingeniería".

Muchos autores escribieron sobre las relaciones entre arte y ciencia en el siglo diecinueve, y creo que la mejor discusión fue dada por John Stuart Mill. El dijo lo siguiente, entre otras cosas, en 1844: "Muchas ciencias son necesarias a menud para el trabajo básico de un único arte. Tal es la complicación de los asuntos humanos, que para permitir que una cosa sea hecha, es un requisito a menudo necesario saber la naturaleza y las propiedades de muchas cosas... El arte en general consiste de las verdades de la ciencia, dispuestas en el orden más convieniente para la práctica, en lugar de el orden que sea más conveniente para el pensamiento. La Ciencia agrupa y ordena sus verdades de modo que nos permite tomar en una vista tanto como sea posible del orden general del universo. El arte... junta partes de el campo de la ciencia las más remotas unas de otras, las verdades relacionadas a  la producción de las condiciones diferentes y heterogeneas necesarias para que tengan efecto
con las exigencias que la vida práctica requiere."

Mientras buscaba estas cosas sobre el significado de "arte", encontré que los autores han estado pidiendo la transición de arte a ciencie por al menos dos siglos. Por ejemplo, el prefacio de un libro de texto sobre mineralogía, escrito en 1784, dice lo siguiente: "Antes del año 1780, la minerología, aunque tolerablemente entendida por muchos como un Arte, apenas puede ser llamada una Ciencia."

De acuerdo a muchos diccionarios "ciencia" significa conocimiento que ha sido lógicamente dispuesto y sistematizado en la forma general de "leyes". La ventaja de la ciencia es que nos alivia de la necesidad de pensar sobre cada caso individual; podemos llevar nuestros pensamientos a conceptos de más alto nivel. Como John Ruskin escribió en 1853: "El trabajo de la ciencia es sustituir hechos por apariencias, y demostraciones por impresiones."

Me parece que si los autores que estudié estuvieran escribiendo hoy, estarían de acuerdo con la siguiente caracterización: La Ciencia es conocimiento que entendemos tan bien que se lo podemos enseñar a un computador, y si no podemos entender algo completamente, es un arte tratar con él. Dado que la noción de un algoritmo o programa de computador nos provee de una prueba extremadamente útil de la profundidad de nuestro conocimiento sobre un asunto dado, el proceso de ir desde un arte a una ciencia significa que aprendemos cómo automatizar algo.

La inteligencia artificial ha hecho progresos significativos, pero aún hay una brecha enorme entre lo que los computadores pueden hacer en el futuro previsible y lo que las personas comunes pueden hacer. Las misteriosas ideas que la gente tiene al hablar, escuchar, crear, e incluso cuando están programando, siguen estando fuera del alcance de la ciencia y casi todo lo que hacemos es todavía un arte.

Desde este punto de vista ciertamente es deseable hacer una ciencia de la programación de computadores, y de hecho hemos recorrido un largo camino en los 15 años transcurridos desde la publicación de las observaciones que he citado al comienzo de esta charla. Hace quince años la programación de computadores estaba tan mal entendida que difícilmente alguien aún pensaba sobre probar que los programas fueran correctos, nosotros sólo jugabamos con nuestro programa hasta que "sabíamos" que funcionaba. En esa época no sabíamos siquiera cómo expresar el concepto de que un programa fuera correcto, de una manera rigurosa. Sólo en los últimos años hemos estado aprendiendo acerca de los procesos de abstracción mediante los cuales los programas se escriben y entienden,
y este nuevo conocimiento acerca de la programación está produciendo grandes ganancias en la práctica, aunque pocos programa son realmente probados cómo correctos con completo rigor, dado que estamos recién empezando a comprender los principios de la estructura de los programas. El punto es que cuando es que cuando escribimos programas hoy en día, sabemos que podríamos, en principio, construir pruebas formales de su corrección si quisieramos, ahora que sabemos cómo se formulan tales pruebas.
Esta base científica se traduce en programas que son mucho más fiables que los que se escribieron en tiempos pasados,  cuando la intuición era la única base de la corrección.

El campo de la "programación automática" es una de las mayores áreas de la investigación en inteligencia artificial hoy. A sus defensores les gustaría dar una charla titulada "La Programación de Computadores como un Artefacto" (lo que significa que la programación se ha convertido en una reliquia del pasado), porque su objetivo es crear máquinas que escriben programas mejor de lo que podemos, dándoles sólo la especificación del problema.
Personalmente no creo que tal meta sea alguna vez alcanzada completamente,
pero pienso que esta investigación es extremadamente importante, porque todo lo que aprendamos sobre programación nos ayuda a mejorar nuestro propio arte. En este sentido, deberíamos esforzarnos continuamente para transformar todo arte en una ciencia: en el proceso, avanzamos el arte.

La programación de computadores como un arte

Por Donald Knuth

CACM, Diciembre de 1974

Cuando Communications of the ACM comenzó su publicación en 1959, los miembros del Comité Editorial de la ACM hicieron la siguiente observación al describir el propósito de las publicaciones periódicas de la ACM:

"Si la programación de computadores será una importante parte de la investigación y desarrollo de los computadores, se debe efectuar una transición de la programación de un arte a una ciencia disciplinada".

Implicita en estas observaciones está la noción de que es algo no deseable sobre un área de la actividad humana que esta sea clasificada como un "arte"; tiene que ser una Ciencia antes de que tenga una estatura real. Por otro lado, yo he estado trabajando por más de 12 años en una serie de libros llamados "El Arte de Programar Computadores". La gente frecuentemente me pregunta por qué elegí tal título; y de hecho algunas personas aparentemente no creen que yo lo haya hecho, dado que he visto al menos una referencia bibliográfica a los libros como "El Acto de Programar Computadores."

En esta charla trataré de explicar porque pienso que "Arte" es la palabra apropiada. Discutiré que significa que algo sea un arte, en contraste con ser una ciencia; trataré de examinar si las artes son cosas buenas o cosas mala; y trataré de mostrarles que un punto de vista propio del asunto nos ayudará a mejorar la calidad de lo que ahora estamos haciendo.

Una de las primeras veces que fuí interrogado sobre el título de mis libros fue en 1966, durante la previa al encuentro anual de la ACM en el Sur de California. Esto fue antes de que ninguno de los libros fuera publicado, y recuerdo haber estado comiendo con un amigo en el hotel de convenciones. El sabía cuan pretencioso era yo, ya en ese tiempo, así que me preguntó si iba a llamar a mis libros "Una Introducción a Don Knuth." Le repliqué que, al contrario, estaba nombrando a los libros como a él. Su nombre: Art Evans. (El Arte de la Programación de Computadores, en persona.)

De esta historia concluimos que la palabra "arte" tiene más de un significado. De hecho, una de las cosas más agradables de la palabra es que es usada en muchos sentidos diferentes, cada uno de los cuales es bastante apropiado en conexión con la programación de computadoras.  Mientras preparaba esta charla, fui a la biblioteca para buscar lo que la gente ha escrito sobre la palabra "arte" a lo largo de los años; y después de gastar varios días fascinantes entre los libros, llegué a la conclusión de que "arte" debe ser una de las palabras más interesantes de la lengua inglesa.

El Arte de los Antiguos

Si vamos a las raices latinas, encontramos ars, artis que significan "habilidad". Quizás es significativo que la palabra griega correspondiente era τεχνη, la raíz de "tecnología" y "técnica".

En nuestros días cuando alguien habla de "arte" probablemente piense primero en las "finas artes" tales como la pintura y la escultura, pero antes del siglo veinte la palabra era usada generalmente en un sentido bastante diferente. Incluso este viejo significado de "arte" aún sobrevive en muchos modismos, especialmente cuando se contrastas arte con ciencia, y quisiera tomarme los próximos minutos para hablar de arte en su sentido clásico.

En los tiempos mediaveles, las primeras universidades fueron establecidas para enseñar las, así llamadas, "siete artes liberales" a saber, gramática, retórica, lógica, aritmética, geometría, música y astronomía. Noten que esto es bastante diferente de los currículos de los colegios de artes liberales, y que al menos tres de las siete artes liberales son componentes importantes de la ciencia de la computación. En aquel tiempo, un "arte" denotaba a algo ideado por el intelecto humano, en oposición a las actividades derivadas de la naturaleza o el instinto; las artes "liberales" eran liberadas o libres, en contraste a las artes manuales tales como arrar. Durante la edad media la palabra "arte" por si misma usualmente significaba lógica, la que usualmente denotaba el estudio de los silogismos.

(Continúa en la parte II)