Artículos que son como… metáforas

METAeuFORiAS

Lun, 29-Dic-2008

Dijkstra, las metáforas y sus límites

Como ya se explica en la página descriptiva de este blog, las metáforas y analogías son una potente herramienta para entender algunas ideas y descubrir otras nuevas. Sin embargo, siempre es necesario tener en cuenta que toda metáfora tiene sus limitaciones, así que hay que saber cuándo no llevarla más lejos, o cuándo, simplemente, es necesario abandonarla.

Edsger W. Dijkstra, una de las figuras contemporáneas de referencia en la informática y, más concretamente, en la programación, escribió hace ya 20 años el artículo “Sobre la crueldad de verdaderamente enseñar ciencias de la computación” en el que expone uno de esos casos en los que, en su opinión, es necesario abandonar una metáfora que afecta a las computadoras actuales y su programación.

Dijkstra, los límites de las metáforas y las ciencias de la computación

Dijkstra no rechaza el uso de analogías; él mismo afirma que:

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.

Sin embargo, deja claro que es necesario abandonar esas analogías cuando se trata de abarcar un tema radicalmente nuevo:

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”.

[…]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.

Y, para él, uno de esos campos radicalmente nuevo, que necesita un lenguaje diferente y que no puede tratarse mediante analogías con materias anteriores, es el de las computadoras digitales:

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.

[…] 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. […] 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.

[…] Nuevamente, debo enfatizar esta novedad radical ya que el verdadero creyente en el cambio gradual y las mejoras incrementales no puede verla. Para él, una computadora automática es algo como una familiar caja registradora, sólo que algo más grande, rápida y más flexible. Pero la analogía es ridículamente superficial: es órdenes de magnitud peor que comparar, como un medio de transporte, el avión supersónico con un bebé que gatea, ya que el cociente de velocidad es sólo de mil.

[…] Es posible, inclusive tentador, ver a un programa como un mecanismo abstracto, como alguna clase de dispositivo. Pero hacerlo, sin embargo, es altamente peligroso: la analogía es muy superficial debido a que un programa es, como mecanismo, totalmente diferente de todos los familiares dispositivos analógicos con los cuáles crecimos. Como toda la información digitalizada, tiene la inevitable e incómoda propiedad de que la menor de las posibles perturbaciones -por ejemplo cambios a un sólo bit- puede tener las más drásticas consecuencias.

Dijkstra se apoya en ese razonamiento para criticar el tratamiento actual de la programación de software como “ingeniería”, ya que, para él, se trata de una disciplina que debería abordarse desde una perspectiva nueva, diferente, más formal:

Por lo tanto, la ciencia de la computación está -y siempre estará- relacionada con la interacción entre la manipulación de símbolos mecanizada y humana, usualmente llamadas “computación” y “programación”, respectivamente. […] Un beneficio posterior es que nos da una clara indicación acerca de dónde ubicar la ciencia de la computación en el mapa de las disciplinas intelectuales: en la dirección de la matemática formal y la lógica aplicada, pero finalmente mucho más allá de donde se encuentra actualmente, dado que la ciencia de la computación se interesa en el uso efectivo de los métodos formales en una escala mucho, mucho mayor de la que hemos sido testigos hasta ahora.

[…] En el largo plazo espero que la ciencia de la computación trascienda a sus disciplinas padres, matemática y lógica, efectivamente realizando una parte significativa del Sueño de Leibniz de proveer un cálculo simbólico como una alternativa al razonamiento humano. (Por favor, note la diferencia entre “imitar” y “proveer una alternativa a”: a las alternativas se les permite ser mejores.)

Como punto final a su argumentación, Dijkstra critica el sistema (el de entonces y podría decirse que también el actual) de enseñanza de ciencias de la computación, “infantilizado” y lleno de analogías inapropiadas que propone eliminar:

Podemos, por ejemplo, comenzar limpiando nuestro lenguaje no denominando a un bug un bug, sino denominándolo un error. Es mucho mas honesto porque pone manifiestamente la culpa donde corresponde, es decir, en el programador que cometió el error. La metáfora animada del bug que se introdujo maliciosamente mientras el programador no estaba mirando es intelectualmente deshonesta ya que disfraza el hecho de que el error es propia creación del programador. Lo agradable de este simple cambio de vocabulario es que tiene un profundo efecto: mientras, antes, un programa con sólo un error solía ser “casi correcto”, después de ello un programa con un error es simplemente “erróneo” (porque tiene un error)

[…] Mi próxima sugerencia lingüística es más rigurosa. Se trata de confrontar el síndrome de “si-este-tipo-quiere-hablarle-a-ese-tipo”: nunca se refieran a partes de programas o piezas de equipo en una terminología antropomórfica, ni permitan hacerlo a sus estudiantes.

[…] La razón para esta última sugerencia es que la metáfora antropomórfica -por cuya introducción podemos culpar a John von Neumann- es una enorme desventaja para cada comunidad informática que la ha adoptado. He encontrado programas que quieren cosas, saben cosas, esperan cosas, creen cosas, etc., y cada vez eso generaba confusiones evitables. La analogía que subyace a esta personificación es tan superficial que no es solamente engañosa sino también paralizante.

En definitiva, Dijkstra propone tratar y enseñar la ciencia de la computación no como una ingeniería (de modo similar al que trata la construcción de herramientas) sino como un sistema formal, tratando los programas como modelos formales, independientemente de que puedan ser ejecutados:

Un lenguaje de programación, con su sintaxis formal y las reglas de demostración que define su semántica, es un sistema formal para el cual la ejecución del programa provee solamente un modelo. Es bien conocido que los sistemas formales deberían ser tratados por derecho propio, y no en términos de un modelo específico. Y, de nuevo, el corolario es que deberíamos razonar sobre los programas sin siquiera mencionar su posible “comportamiento”.

[…] Desde el comienzo, y a través de todo el curso, enfatizamos que la tarea del programador no es sólo escribir un programa, sino que su tarea principal es dar una prueba formal de que el programa que propone cumple la especificación funcional (igualmente formal).

Otras metáforas objeto de abuso

Enlazando con este artículo de Dijkstra, Ricardo Galli comenta otro abuso de una analogía que lleva a resultados desastrosos y contrarios a la lógica y al sentido común: el de comparar las obras intelectuales y su creación, con la posesión de objetos físicos:

[…] Aunque el discurso que no se cansan de repetirnos esta analogía erróna (usando las palabras como “robo”, “propiedad”, “piratas”), tiene tan poco que ver una “obra intelectual” con “objetos físicos” y “propiedad” que las leyes basadas en esas analogías sólo pueden ir de mal en peor: códigos penales más estrictos, criminalización de la mayoría de la sociedad, campañas carísimas ridículas y que nadie es capaz de comprender, impuestos disfrazados de tasas y llamados “cánon”, etc.

También en el diseño de interfaces de usuario las metáforas son un recurso que debe utilizarse con cuidado, como muestra esta recopilación de metáforas confusas o mal elegidas.

¿Entonces las metáforas son inútiles?

¿Quieren decir los casos anteriores que las metáforas y analogías son siempre inútiles o contraproducentes a la hora de mejorar nuestros conocimientos (como pretende este blog)? No, para nada. Las metáforas son útiles en muchos casos, siempre que sean bien elegidas y no se fuercen en exceso (en el caso de las interfaces de usuario, por ejemplo, existen artículos que demuestran que una adecuada selección de la metáfora mejora el rendimiento a la hora de ejecutar tareas con un ordenador). Incluso la discusión sobre la adecuación o no de una metáfora puede aportar descubrimientos interesantes sobre el tema tratado.

Lo que sí ponen de manifiesto estos ejemplos es que las analogías son herramientas que deben seleccionarse con mucho cuidado, conociendo su alcance y sus límites, y que deben ser susceptibles de ser abandonadas o sustituidas por otras cuando no aporten nada positivo, o cuando utilizarlas aporte más limitaciones que ventajas.

Valora esta metáfora:

1 Star2 Stars3 Stars4 Stars5 Stars (2 votes, average: 4,50 out of 5)
Loading...
 

Un comentario to “Dijkstra, las metáforas y sus límites”

  1. Información Bitacoras.com…

    Valora en Bitacoras.com: Como ya se explica en la página descriptiva de este blog, las metáforas y analogías son una potente herramienta para entender algunas ideas y descubrir otras nuevas. Sin embargo, siempre es necesario tener en cuenta que toda…

Opina sobre esta metáfora