2007-04-04 00:56:50

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

Sobre la crueldad de verdaderamente ense�ar ciencias de la computaci�n

La segunda parte de esta charla denota algunas de las consecuencias cient�ficas y educacionales provenientes de la idea de que las computadoras representan una novedad radical. Para darle contenidos claros a esta asunci�n, tenemos que ser mucho m�s precisos acerca de lo que queremos decir en este contexto con el uso del adjetivo “radical”. Lo haremos en la primera parte de esta charla, en la cual vamos a proveer evidencia que respalde nuestra suposici�n.

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.

La otra cosa que no puedo resaltar lo suficiente es que la fracci�n de la poblaci�n para la cu�l el cambio gradual parece ser cualquier cosa menos el �nico paradigma de la historia es muy grande, probablemente mucho m�s grande de lo que esperar�an. Ciertamente cuando comenc� a observarlo, su n�mero result� ser mucho mayor de lo que esperaba.

Por ejemplo, la gran mayor�a de la comunidad matem�tica nunca ha confrontado la suposici�n t�cita de que hacer matem�ticas va a continuar siendo b�sicamente el mismo tipo de actividad mental que siempre ha sido: los nuevos temas vendr�n, florecer�n, e ir�n como lo han hecho en el pasado, pero siendo lo que es el cerebro humano, nuestras formas de ense�ar, aprender, y el entendimiento las matem�ticas, la resoluci�n de problemas y el descubrimiento matem�tico van a continuar siendo b�sicamente lo mismo. Herbert Robbins expone claramente por qu� �l descarta un salto cu�ntico en la habilidad matem�tica:

«Nadie va a correr 100 metros en cinco segundos, sin importar cu�nto se invierta en entrenamiento y m�quinas. Lo mismo puede decirse acerca del uso del cerebro. La mente humana no es diferente ahora de lo que era hace cinco mil a�os. Y cuando se trata de matem�ticas, debe darse cuenta de que se trata de la mente humana a un extremo l�mite de su capacidad».

Mi comentario en el margen fue "�entonces reduzca el uso del cerebro y calcule!". Usando la propia analog�a de Robbins, uno puede resaltar que, para ir r�pido desde A hasta B, podr�an existir ahora alternativas a la de correr que son �rdenes de magnitud m�s efectivas. Robbins rechaza de llano honrar cualquier alternativa al valioso uso del cerebro llamado «hacer matem�ticas», exorcizando as� el peligro de la novedad radical mediante el simple m�todo de ajustar sus definiciones a sus necesidades: simplemente por definici�n, las matem�ticas continuar�n siendo lo que sol�an ser. Demasiado para los matem�ticos.

D�jenme darles un ejemplo m�s de la desconfianza generalizada sobre la existencia de las novedades radicales y, por consiguiente, de la necesidad de aprender c�mo lidiar con ellas. Es el accionar educacional que prevalece, para el cu�l el cambio, casi imperceptible, parece ser el paradigma exclusivo. �Cu�ntos textos educacionales no son recomendados porque apelan a la intuici�n del estudiante! Constantemente tratan de presentar todo aquello que podr�a ser una emocionante novedad como algo tan familiar como sea posible. Conscientemente tratan de vincular el material nuevo con lo que se supone es el mundo familiar del estudiante. Ya empieza con la ense�anza de la aritm�tica. En vez de ense�ar 2 + 3 = 5, el horrendo operador aritm�tico «m�s» es cuidadosamente disfrazado llam�ndolo “y”, y a los peque�os ni�os se les dan muchos ejemplos familiares primero, con objetos claramente visibles como manzanas y peras, que lo son, en contraste al uso de objetos numerables como porcentajes y electrones, que no lo son. La misma tonta tradici�n es reflejada a nivel universitario en diferentes cursos introductorios de c�lculo para los futuros f�sicos, arquitectos, economistas, cada uno adornado con ejemplos de sus respectivos campos. El dogma educacional parece ser que todo est� bien siempre y cuando el estudiante no se d� cuenta de que est� aprendiendo algo verdaderamente nuevo; generalmente, el presentimiento del estudiante es de hecho correcto. Considero como un serio obst�culo la falencia de una pr�ctica educativa en preparar a la pr�xima generaci�n para el fen�meno de novedades radicales. [Cuando el Rey Fernando visit� la conservadora universidad de Cervera, el Rector orgullosamente asegur� al monarca con las palabras: «Lejos est� de nosotros, Se�or, la peligrosa novedad de pensar”. Los problemas de Espa�a en el siglo que sigui� justifican mi caracterizaci�n del problema como “serio”]. Demasiado para la adopci�n por parte de la educaci�n del paradigma de cambio gradual.

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.

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. Una inspecci�n m�s a fondo revelar� que esto es todav�a peor, a saber, que las computadoras autom�ticas engloban no s�lo una novedad radical sino dos de ellas.

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.

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.

La segunda novedad radical es que la computadora autom�tica es nuestro primer dispositivo digital de gran escala. Tuvimos un par de notables componentes discretos: Acabo de mencionar la caja registradora y podemos agregar la m�quina de escribir con sus teclas individuales: con un s�lo golpe podemos escribir puedes escribir una Q o una W pero, aunque las teclas est�n una al lado de la otra, no una mezcla de las dos. Pero tales mecanismos son la excepci�n, y la amplia mayor�a de nuestros mecanismos son vistos como dispositivos anal�gicos cuyo comportamiento sobre un amplio rango es una funci�n continua de todos los par�metros involucrados: si presionamos la punta del l�piz un poco m�s fuerte, obtenemos una l�nea levemente m�s gruesa, si el violinista ubica su dedo levemente fuera de su posici�n correcta, reproduce una nota levemente desafinada. A esto deber�a agregar que, al punto que nos vemos como mecanismos, nos vemos primordialmente como dispositivos anal�gicos: si nos esforzamos un poco m�s esperamos rendir un poco m�s. A menudo el comportamiento no es solamente una funci�n continua sino tambi�n mon�tona: para ver si un martillo es adecuado sobre un cierto rango de clavos, lo probamos con el m�s peque�o y el m�s grande de los clavos del rango, y si el resultado de ambos experimentos es positivo, estamos perfectamente predispuestos a creer que el martillo ser� apropiado para todos los clavos intermedios.

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. [Por completitud agrego que la situaci�n no cambia en su esencia por la introducci�n de la redundancia o la correcci�n de errores]. En el mundo discreto de la computaci�n, no hay m�trica significativa en la cual «peque�os» cambios y «peque�os» efectos vayan de la mano, y nunca los habr�.

Esta segunda novedad radical comparte el destino usual a todas las novedades radicales: es negada, porque su verdad ser�a demasiado inc�moda. No tengo idea lo que esta negaci�n y descreencia espec�fica le cuesta a los Estados Unidos, pero un mill�n de d�lares al d�a parece una modesta estimaci�n.

Habiendo descripto �en los t�rminos m�s amplios posibles, lo admito� la naturaleza de las novedades computacionales, debo ahora proveer la evidencia de que tales novedades son, de hecho, radicales. Lo har� explicando una serie de fen�menos que de otra manera ser�an extra�os por la frustrante �pero, como ahora sabemos, condenada� ocultaci�n o negaci�n de su aterradora extra�eza.

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 popularidad de su nombre es suficiente para hacerla sospechosa. En lo que denominamos “sociedades primitivas”, la superstici�n de que conocer el verdadero nombre de alguien otorga un poder m�gico sobre �l no es inusual. Dif�cilmente somos menos primitivos: �por qu� persistimos en contestar el tel�fono con el poco �til “hola” en vez de nuestro nombre? Tampoco estamos por encima de la primitiva superstici�n de que podemos tener cierto control sobre alg�n demonio malicioso desconocido llam�ndolo por un nombre seguro, familiar e inocente, tal como «ingenier�a”. Pero esto es totalmente simb�lico, as� como demostr� uno de los fabricantes de computadoras de los EE.UU. hace unos a�os cuando contrat�, una noche, cientos de nuevos “ingenieros de software” mediante el simple mecanismo de elevar a todos sus programadores a ese exaltante rango. Demasiado para ese t�rmino.

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.

Finalmente, para corregir la posible impresi�n de que la inhabilidad de enfrentar la novedad radical est� confinada al mundo industrial, d�jenme ofrecerles una explicaci�n de la �al menos americana� popularidad de la Inteligencia Artificial. Uno esperar�a que la gente se sintiera aterrorizada por los «cerebros gigantes de m�quinas que piensan». De hecho, la atemorizante computadora se vuelve menos atemorizante si es utilizada solamente para simular una no-computadora que nos es familiar. Estoy seguro de que esta explicaci�n seguir� siendo controvertida por bastante tiempo, dado que la Inteligencia Artificial como imitadora de la mente humana prefiere verse a s� misma como a la vanguardia, mientras mi explicaci�n la relega a la retaguardia. (El esfuerzo de utilizar m�quinas para imitar la mente humana siempre me ha parecido bastante tonto: las usar�a para imitar algo mejor.)

Hasta aqu� la evidencia de que las novedades computacionales son, de hecho, radicales.

Y ahora viene la segunda �y m�s dif�cil� parte de mi charla: las consecuencias educativas y cient�ficas de lo anterior. Las consecuencias educativas son, por supuesto, las m�s engorrosas, por lo tanto pospongamos su discusi�n y qued�monos mientras tanto con las ciencias de la computaci�n en s� mismas. �Qu� es la computaci�n? �Y de qu� se trata la ciencia de la computaci�n?

Bien, una vez que todo est� dicho y hecho, la �nica cosa que las computadoras pueden hacer por nosotros es manipular s�mbolos y producir resultados de tales manipulaciones. De nuestras observaciones previas, deber�amos recordar que este es un mundo discreto y, m�s a�n, tanto los n�meros como los s�mbolos involucrados as� como la cantidad de manipulaciones realizadas son varios �rdenes de magnitud mayores que los que podemos concebir: desconciertan totalmente nuestra imaginaci�n y por lo tanto no debemos tratar de imagin�rnoslos.

Pero antes de que una computadora est� lista para realizar alguna clase de manipulaci�n con sentido �o c�lculo, si se prefiere� debemos escribir un programa. �Qu� es un programa? Varias respuestas son posibles. Podemos ver a un programa como lo que transforma una computadora de prop�sito general en un manipulador de s�mbolos de prop�sito espec�fico, y lo hace sin necesidad de cambiar un solo cable (Esto fue una enorme mejora respecto de las m�quinas con paneles de cables dependientes del problema.) Prefiero describirlo de la otra manera: un programa es un manipulador de s�mbolos abstracto, que puede convertirse en uno concreto suministr�ndole una computadora. Despu�s de todo, el prop�sito de los programas ya no es m�s instruir a nuestras m�quinas; en estos d�as, el prop�sito de las m�quinas es ejecutar nuestros programas.

Por lo tanto, tenemos que dise�ar manipuladores de s�mbolos abstractos. Todos sabemos c�mo se ven: se ven como programas o �para usar una terminolog�a m�s general� usualmente f�rmulas de alg�n sistema formal un tanto elaboradas. Realmente ayuda ver a un programa como una f�rmula. Primero, pone la tarea del programador en la perspectiva correcta: tiene que derivar esa f�rmula. Segundo, explica por qu� el mundo de las matem�ticas ha ignorado el desaf�o de la programaci�n: los programas eran f�rmulas mucho m�s largas que las usuales, al punto que ni siquiera las reconocieron como tales. Ahora, de vuelta al trabajo del programador: tiene que derivar esa f�rmula, tiene que derivar ese programa. Sabemos de una �nica forma confiable de hacerlo, mediante la manipulaci�n de s�mbolos. Y ahora el c�rculo est� cerrado: construimos nuestros manipuladores de s�mbolos mec�nicos mediante la manipulaci�n de s�mbolos humana.

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 inmediato de esta visi�n es que revela a la «programaci�n autom�tica» como una contradicci�n en t�rminos. 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. Dado que ning�n emprendimiento es respetable por estos d�as sin una STL (Sigla de Tres Letras) propongo que adoptemos para la ciencia de la computaci�n IMF (Iniciativa de los M�todos Formales), y, para estar del lado seguro, mejor sigamos los brillantes ejemplos de nuestros l�deres y hagamos de ella una Marca Registrada.

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

De m�s est� decirlo, esta visi�n acerca de qu� trata la ciencia de la computaci�n no es universalmente aplaudida. Por el contrario, ha encontrado oposici�n �y a veces hasta violenta� desde todo tipo de direcciones. Menciono como ejemplos:

(0) la comunidad matem�tica, que quisiera continuar creyendo que el Sue�o de Leibniz es una ilusi�n irreal

(1) la comunidad empresarial, quienes, habi�ndoseles vendido la idea de que las computadoras har�an la vida m�s simple, no est�n mentalmente preparados para aceptar que s�lo resolvieron los problemas m�s simples al precio de crear uno mucho m�s dif�cil

(2) la subcultura del programador compulsivo, cuya �tica prescribe que una idea tonta y un mes de codificaci�n fren�tica deber�an bastar para hacerlo millonario de por vida

(3) los ingenieros en computaci�n, quienes quisieran continuar actuando como si fuera solamente cuesti�n de mayor flujo de bits o m�s flops por segundo

(4) la milicia, quienes est�n hoy totalmente absorbidos por el negocio de usar computadoras para transformar partidas de miles de millones de d�lares en la ilusi�n de seguridad autom�tica

(5) todo tipo de ciencias para las cuales la computaci�n ahora act�a de alguna especie de refugio interdisciplinario

(6) el negocio educativo que siente que, si tiene que ense�ar matem�tica formal a los estudiantes de Ciencias de la Computaci�n, tambi�n deber�a cerrar sus escuelas.

Y con este sexto ejemplo he alcanzado, imperceptiblemente pero tambi�n inevitablemente, la parte m�s engorrosa de esta charla: consecuencias educativas.

El problema con la pol�tica educativa es que es dif�cilmente influenciada por consideraciones cient�ficas derivadas de los t�picos dictados, y casi completamente determinada por circunstancias ajenas a la ciencia tales como las expectativas conjugadas de los estudiantes, sus padres y sus futuros empleadores, y el enfoque prevaleciente del rol de la universidad: el acento est� en formar sus graduados para los trabajos de nivel inicial de hoy o en proveer a su alumnado con el bagaje intelectual y las actitudes que perduraran por otros 50 a�os? �Le damos rencorosamente a las ciencias abstractas solo un rinc�n lejano en el campus, o las reconocemos como el motor indispensable de la industria de alta tecnolog�a? A�n si hacemos esto �ltimo, �reconocemos una industria de alta tecnolog�a como tal si su tecnolog�a pertenece principalmente a las matem�ticas formales? �Proveen las universidades a la sociedad el liderazgo intelectual que necesita o s�lo el entrenamiento que demanda?

La ret�rica acad�mica tradicional est� perfectamente dispuesta a dar a estas cuestiones las respuestas tranquilizadoras, pero no creo en ellas. A modo de ilustrar mis dudas, en un art�culo reciente en "�Qui�n gobierna Canad�?", David H. Flaherty groseramente establece que «Adem�s, la �lite de los negocios descarta a los acad�micos e intelectuales como ampliamente irrelevantes e impotentes.»

As�, si miro en mi borrosa bola de cristal hacia el futuro de la educaci�n en ciencias de la computaci�n, veo sobrecogedoramente la deprimente imagen del “Negocio acostumbrado”. A las universidades les seguir� faltando el coraje de ense�ar ciencia dura, continuar� orientando mal a los estudiantes, y cada nuevo escal�n de infantilizaci�n del curr�culum ser� exaltado como progreso educativo.

Hace un buen rato que tengo mi borrosa bola de cristal. Sus predicciones son invariablemente melanc�licas y usualmente correctas, pero estoy bastante acostumbrado a eso y no me impiden darles unas pocas sugerencias, a�n si es meramente un ejercicio vano cuyo �nico efecto es hacerlos sentir culpables.

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. Esta mejora ling��stica es mucho m�s dif�cil de implementar de lo que podr�an pensar, y su departamento puede considerar la introducci�n de multas para las violaciones, digamos veinticinco centavos para estudiantes de grado, cincuenta centavos para estudiantes de postgrado y cinco d�lares para miembros de la facultad: para final del primer semestre del nuevo r�gimen, habr�n recolectado suficiente dinero para dos becas.

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.

Es enga�osa en el sentido que sugiere que podemos lidiar con el desconocido discreto en t�rminos del familiar continuo, es decir, nosotros mismos, quod non. Es paralizante en el sentido que, debido a que las personas existen y act�an en el tiempo, su adopci�n efectivamente impide un despegue de la sem�ntica operacional y fuerza as� a la gente a pensar sobre los programas en t�rminos de comportamientos computacionales, basados en un modelo computacional subyacente. Esto es malo, porque el razonamiento operacional es un tremendo desperdicio de esfuerzo mental.

D�jenme explicarles la naturaleza de ese tremendo desperdicio, y perm�tanme tratar de convencerlos de que el t�rmino “tremendo desperdicio de esfuerzo mental” no es una exageraci�n. Por un breve lapso, me tornar� altamente t�cnico, pero no se acobarden: es el tipo de matem�ticas que uno puede hacer con las manos en los bolsillos. El punto a comunicar es que si tenemos que demostrar algo respecto de todos los elementos de un conjunto grande, es desesperanzadamente ineficiente tratar con todos los elementos del conjunto individualmente: el argumento eficiente no se refiere a elementos individuales en lo absoluto y se lleva a cabo en t�rminos de la definici�n del conjunto.

Consideren la figura plana Q, definida como el cuadrado de 8 por 8 del cual, en dos esquinas opuestas, han sido quitados dos cuadrados de 1 por 1. El �rea de Q es 62, que equivale al �rea combinada de 31 domin�s de 1 por 2. El teorema es que la figura Q no puede ser cubierta por 31 de tales domin�s.

Otra manera de exponer el teorema es que si comienza con papel cuadriculado y se cubre este ubicando cada siguiente domin� en dos nuevos recuadros adyacentes, ninguna distribuci�n de 31 domin�s dar� como resultado la figura Q.

As�, una posible manera de probar el teorema es generando todas las posibles distribuciones de domin�s y verificando para cada distribuci�n que no da como resultado la figura Q.

El argumento simple, sin embargo, es como sigue. Pinte los recuadros del papel cuadriculado como un tablero de ajedrez. Cada domin�, cubriendo dos recuadros adyacentes, cubre 1 recuadro blanco y 1 negro, y, por consiguiente, cada distribuci�n cubre tantos recuadros blancos como recuadros negros. En la figura Q, sin embargo, el n�mero de recuadros blancos y el n�mero de recuadros negros difiere en 2 �esquinas opuestas sobre la misma diagonal� y por consiguiente ninguna disposici�n de domin�s da como resultado la figura Q.

No s�lo es el simple argumento previo muchos �rdenes de magnitud m�s corto que la investigaci�n exhaustiva de las posibles distribuciones de 31 domin�s, es tambi�n esencialmente m�s poderosa, dado que cubre la generalizaci�n de Q reemplazando el cuadrado original de 8 por 8 por cualquier rect�ngulo con lados de longitud par. Siendo infinito el n�mero de tales rect�ngulos, el m�todo previo de exploraci�n exhaustiva es esencialmente inadecuada para probar nuestro teorema generalizado.

Y esto concluye mi ejemplo. Ha sido presentado porque ilustra de un tir�n el poder de las matem�ticas terrenales; no hace falta decirlo, la negaci�n de explotar este poder de las matem�ticas terrenales escala al suicidio intelectual y tecnol�gico. La moraleja de la historia es: tratar con todos los elementos de un conjunto ignor�ndolos y trabajando con la definici�n del conjunto.

Volvamos a la programaci�n. La aseveraci�n de que un programa dado cumple una cierta especificaci�n escala a una aseveraci�n sobre todos los c�lculos computacionales que podr�an ocurrir bajo el control de ese programa dado. Y dado que este conjunto de c�lculos est� definido por el programa dado, nuestra reciente moraleja dice: trate con todas los c�lculos posibles bajo control de un programa dado ignor�ndolas y trabajando con el programa. Debemos aprender a trabajar con el texto de los programas mientras (temporalmente) se ignora que admiten la interpretaci�n de c�digo ejecutable.

Otra manera de decir la misma cosa es la siguiente. 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”.

Y esto concluye mi excursi�n t�cnica en el motivo por el cual el razonamiento operacional sobre la programaci�n es “un tremendo desperdicio de esfuerzo mental” y por qu�, en consecuencia, en la ciencia de la computaci�n deber�a prohibirse la met�fora antropom�rfica.

No todo el mundo comprende esto suficientemente bien. Recientemente fui expuesto a una demostraci�n de lo que pretend�a ser software educativo para un curso introductorio de programaci�n. Con sus “visualizaciones” en la pantalla era un caso tan obvio de infantilizaci�n del curr�culum que su autor deber�a ser acusado de su “menosprecio del cuerpo estudiantil”, pero esto era s�lo un da�o menor comparado con para qu� se usaban las visualizaciones: �se usaban para mostrar todo tipo de caracter�sticas de c�lculos computacionales evolucionando bajo el control del programa del estudiante! El sistema remarcaba precisamente aquello que el estudiante tiene que aprender a ignorar, reforzaba precisamente lo que el estudiante tiene que desaprender. Dado que quitarse los malos h�bitos, m�s que adquirir nuevos, es la parte m�s dura del aprendizaje, debemos esperar de ese sistema un da�o mental permanente para la mayor�a de los estudiantes expuestos.

No hace falta decirlo, ese sistema ocultaba completamente el hecho de que, por s� s�lo, un programa no es m�s que la mitad de una conjetura. La otra mitad de la conjetura es la especificaci�n funcional que se supone que satisface el programa. La tarea del programador es presentar las conjeturas completas como teoremas demostrados.

Antes de irnos, me gustar�a invitarlos a considerar la siguiente forma de hacer justicia a las novedades radicales de la computaci�n en un curso introductorio a la programaci�n.

Por un lado, ense�amos algo que se parece al c�lculo de predicados, pero lo hacemos de manera muy distinta a los fil�sofos. A fin de entrenar al programador novato en la manipulaci�n de f�rmulas sin interpretar, lo ense�amos m�s como �lgebra booleana, familiarizando al estudiante con todas las propiedades algebraicas de los conectivos l�gicos. Para romper a�n m�s los v�nculos con la intuici�n, renombramos los valores {verdadero, falso} del dominio booleano como {negro, blanco}

Por otro lado, ense�amos un lenguaje de programaci�n imperativo simple y claro, con un skip y una asignaci�n m�ltiple como sentencias b�sicas, con una estructura de bloque para variables locales, el punto y coma como operador para composici�n de sentencias, una bonita construcci�n alternativa, una bonita repetici�n y, si se quiere, una llamada a procedimiento. A esto agregamos un m�nimo de tipos de datos, digamos booleanos, enteros, caracteres y cadenas. Lo esencial es que, para lo que sea que introduzcamos, la sem�ntica correspondiente est� definida por las reglas de demostraci�n que la acompa�an.

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). Mientras se dise�an demostraciones y programas conjuntamente, el estudiante adquiere una amplia oportunidad de perfeccionar su destreza manipulativa con el c�lculo de predicados. Finalmente, para hacer llegar el mensaje de que este curso introductorio a la programaci�n es principalmente un curso en matem�ticas formales, nos encargamos de que el lenguaje de programaci�n en cuesti�n no haya sido implementado en el campus de manera que los estudiantes est�n protegidos de la tentaci�n de probar sus programas. Y esto concluye el esbozo de mi propuesta para un curso introductorio a la programaci�n para estudiantes de primer a�o.

Esta es una propuesta seria, y sumamente sensible. Su �nica desventaja es que es demasiado radical para muchos, quienes, siendo incapaces de aceptarla, se ven forzados a inventar alguna justificaci�n r�pida para desestimarla, no importa cuan inv�lida sea. Les dar� unas pocas de esas justificaciones.

No necesitan tomar mi propuesta seriamente porque es tan rid�cula que estoy obviamente desconectado del mundo real. Pero ese barrilete no va a volar, ya que conozco el mundo real demasiado bien: los problemas del mundo real son principalmente aquellos con los que ustedes se quedan despu�s de negarse a aplicar sus efectivas soluciones. As� que, probemos de nuevo.

No necesitan tomar seriamente mi propuesta porque es sumamente surrealista intentar ense�ar tal material a alumnos de primer a�o. �No ser�a esa una salida f�cil? Acaban de postular que esto ser�a por lejos muy dif�cil. Pero ese barrilete tampoco va a volar, dado que el postulado se ha demostrado falso: desde principios de los '80, se ha dado tal curso introductorio a la programaci�n a cientos de estudiantes de primer curso de grado cada a�o. [Porque, en mi experiencia, decir esto no es suficiente, la sentencia previa deber�a repetirse al menos otras dos veces]. As� que, intentemos de nuevo.

Admitiendo renuentemente que podr�a quiz�s ense�arse a estudiantes suficientemente d�ciles, todav�a rechazan mi propuesta porque tal curso se desviar�a tanto de lo que los estudiantes de 18 a�os est�n habituados y esperan, que infling�rselos ser�a un acto de irresponsabilidad educativa: s�lo frustrar�a a los estudiantes. No hace falta decirlo, ese barrilete tampoco va a volar. Es cierto que el estudiante que nunca ha manipulado f�rmulas sin interpretar se da r�pidamente cuenta que se confronta con algo totalmente distinto a cualquier cosa que haya visto antes. Pero afortunadamente, las reglas de manipulaci�n son en este caso tan pocas y simples que muy poco despu�s hace el excitante descubrimiento de que est� comenzando a dominar el uso de una herramienta que, en toda su simplicidad, le da un poder que sobrepasa sus sue�os m�s audaces.

Ense�ar a j�venes desprevenidos el uso efectivo de los m�todos formales es uno de los placeres de la vida porque es extremadamente gratificante. En pocos meses, encuentran su camino en un mundo nuevo con justificado grado de confianza, que es radicalmente novedoso para ellos; en pocos meses, su concepto de cultura intelectual ha adquirido una dimensi�n radicalmente novedosa. Para mi gusto y estilo, esto es de lo que se trata la educaci�n. Las universidades no deber�an temer a ense�ar novedades radicales; por el contrario, es su llamado dar la bienvenida a la oportunidad de hacerlo. Su disposici�n a hacerlo es nuestra principal salvaguarda contra las dictaduras, sean del proletariado, del establishment acad�mico, o de la �lite corporativa.

Austin, 2 de Diciembre de 1988

prof. dr. Edsger W. Dijkstra

Departamento de Ciencias de la Computaci�n

Universidad de Texas

Austin, TX 78712–1188

USA

Traducci�n: Javier Smaldone y Billy Biset.

Transcripci�n original: Javier Smaldone.

�ltima revisi�n: 5 de agosto de 2006 (11:45 am).

�ltima versi�n y actualizaciones: http://www.smaldone.com.ar/documentos/ewd.shtml

Nota de los traductores: La versi�n HTML contiene el texto original en forma de comentarios, para simplificar su correcci�n.

WikiJuanan - SobreLaCrueldadDeVerdaderamenteEnse�arCienciasDeLaComputaci�n

2007-04-04 00:56:50

Sobre la crueldad de verdaderamente ense�ar ciencias de la computaci�n

2007-04-04 00:35:12