| Ricardo Baeza Yates | Julio, 1999 |
| Dpto. de Ciencias de la Computación | |
| Universidad de Chile | El hombre es el único animal que tropieza |
| Blanco Encalada 2120 | dos veces con la misma piedra, folklore popular. | Santiago, Chile | Al parecer lo único que se aprende de estudiar historia |
| rbaeza@dcc.uchile.cl | es que nadie aprende de la historia, folklore erudito. |
| Todo está altamente interrelacionado, | |
| Ted Nelson, el inventor de Xanadu. |
| Resumen |
|
En este artículo presento mi visión personal de nuestra área de trabajo, un análisis crítico y constructivo del estado actual de la misma y sus implicancias en la educación. Aunque esta visión tiene un contexto local, la mayoría de los problemas expuestos son válidos en un contexto global. |
Comenzando con el nombre de nuestro entorno ya tenemos un problema. ¿Es Ciencia de la Computación y/o Ingeniería en Computación o Informática? ¿Es el apellido correcto computador, computación, computacional o informática? ¿Dónde calzan los sistemas de información o son otra área? Yo aún no tengo respuestas claras. Tal vez el problema es intrínseco. Como dice el chiste: la Ciencia del Computador (Computer Science) tiene dos problemas: Computador y Ciencia. ¿Han escuchado alguna vez una ciencia de las lavadoras o de otra máquina? ¿Necesitan las matemáticas o la física decir que son una ciencia? En definitiva es un problema de mayoría de edad, de madurez, y por ende, de inseguridad. En todo caso es claro que lo que hacemos tiene raíces tanto de la ingeniería como de la ciencia básica. Antes de continuar es necesaria una acotación. Muchas de las cosas que expongo son obvias o son de sentido común. Sin embargo, pese a ser obvias, muchas de ellas nadie las dice y por eso están aquí. ¿Serán muy obvias o es que es después de saberlas son obvias?.
El objetivo final de cualquier software es comunicar cierto conocimiento a la mente de la persona que lo usa y viceversa. El cuello de botella más importante está en las interfaces, en la comunicación final con el usuario, no sólo en su ancho de banda, sino en la representación misma de la información (ver Figura 1). Como dijo Djikstra recientemente, aún no hemos podido responder al desafío de reducir la complejidad de grandes sistemas de software.
Cómo resolver este cuello de botella es la motivación principal de este artículo, que puede parecer una mixtura de argumentos, a veces sin relación aparente. Sin embargo, muchas veces olvidamos analizar nuestro universo en forma completa, desde el punto de vista de un observador externo. Para cualquier cosa, tanto el contenido como la forma es importante en su justa medida y con el balance adecuado. Primero presentamos un análisis de la relación de la tecnología y la cultura, de la computación en sí misma y del contexto de nuestra profesión. A continuación presento algunas consecuencias de este análisis en la educación y propongo algunas ideas fundamentales con respecto a que enseñar y como enseñarlo. En pocas palabras, mi mensaje es que no olvidemos las relaciones a todo nivel y de todo tipo que existen, que revisemos siempre las hipótesis que hacemos y que hay que rediseñar de verdad y no sólo hacer reingeniería.
Nuestro contexto es altamente tecnológico y por lo tanto es importante entender las relaciones entre nuestra sociedad y la tecnología. La relación entre la tecnología y la cultura es de amor y odio, de éxitos y fracasos, de visionarios y monopolios.
¿Cuánto tiempo necesita la tecnología para permear la sociedad? En muchos casos, pocos años desde el punto de vista de un historiador. Por ejemplo, la imprenta tardó cien años en alcanzar toda Europa. Sin embargo, para una persona de esa época, era bastante más que el tiempo promedio de vida. El teléfono o la aviación comercial tardaron más de 30 años para impactar a un porcentaje significativo de la población. El fax fue inventado en el siglo pasado pero sólo en las últimas décadas ha impactado a la sociedad y aún no está presente en la mayoría de las casas. Citando a Norman: Hoy en día escuchamos repetidamente que la velocidad de cambio ha aumentado, que los cambios pasan en "tiempo de Internet", en meses o semanas, no en décadas o años. Falso [NOR98]. La Internet tiene más de 30 años y aún no está en todas las casas ni siquiera en los países desarrollados.
La historia está llena de ejemplos de tecnologías innovadoras o de gran calidad que no tuvieron éxito. Algunos de ellos: Edison invento el fonógrafo en 1877 y aún así su compañía no tuvo éxito; la primera compañía de automóviles en Estados Unidos nadie la conoce (Duryea); el sistema operativo del MacIntosh era muy superior a DOS, pero perdió la batalla comercial; la tecnología Beta de Sony era superior a VHS; etc.
Una de las razones es no entender los verdaderos deseos de los clientes. No siempre la lógica vence a los caprichos del mercado. En el caso de Edison, fue la elección de autores para los discos. La gente quería escuchar los cantantes más conocidos. No importaba si habían otros igual de buenos o mejores, es el nombre lo que importa. En el caso de productos, citando a Norman nuevamente: lo que importa es que sea suficientemente bueno para el propósito al que sirve. Más aún, si se lidera el mercado, hasta es permisible usar infraestructura no estándar. Después de todo, si uno tiene la mayoría de los consumidores, lo que uno hace se convierte en el estándar. La competencia no tiene mucha elección aparte de seguirte. Si uno no es el líder, tener infraestructura no estándar es mala idea. Al final, lleva a la extinción [NOR98]. Para software, existen muchos ejemplos de este tipo.
A veces productos malos son vendidos sólo como estrategia de mercado, para dar un primer paso y dar a conocer un nombre. La velocidad es lo esencial, no si el producto funciona o no. Por esta razón, la falta de tiempo es la barrera más importante que impide alcanzar calidad. Muchas veces la calidad tecnológica, un buen diseño, la facilidad de uso (o lo contrario), son igualmente irrelevantes. Citando a Norman: ¿Qué clase de mundo es éste donde no importa que existan productos horribles?. El nuestro y no hay otro.
¡Compre! El único computador RISC 100% compatible de 64 bits, sistema operativo Posix compatible y con conectividad total, incluso ATM. La solución para este mundo de sistemas abiertos. Además, gratis el software que Ud. necesita: herramientas de desarrollo orientadas al objeto con interfaz gráfica e inteligente, base de datos transaccional y servidor SQL con soporte de 99 formatos conocidos y por conocer y 64 utilitarios más. ¡Con cuidado! Al igual que en otros productos de este mercado de consumo, lo que la propaganda dice es diferente de la realidad (para confirmar la regla siempre hay excepciones).
La mayoría de las tecnologías más populares e influyentes hoy en computación nunca fueron pensadas para ser usadas como se usan hoy en día ni para dominar el mercado de la manera en que lo hacen. El éxito de MS-DOS/Windows, Unix/Linux, varios lenguajes de programación y World Wide Web demuestran este hecho. No quiero decir con esto que son buenos o malos, sólo que no fueron diseñados para lo que son hoy. Los que conocen la historia de DOS y CP/M sabrán de qué hablo o de cómo prototipos cómo X-Windows o Mosaic han cambiado la historia. Estos y otros casos son ejemplos claros de productos y sistemas accidentales que han terminado dominando nuestro mundo y al mismo tiempo han debilitado nuestra confianza en poder moldear el futuro tecnológico. De acuerdo a Karl Reed, ésta debería ser una tarea de los profesionales de la computación, los cuales no sólo deberían informar acerca de nuevos avances o problemas, sino también dirigir el desarrollo y uso de las tecnologías de la información [REE98]. Según Reed, esto ha ocurrido por una aversión a planificar. Yo creo que más bien lo que pasa es que cuando planificamos no tenemos éxito por el contexto que describimos a continuación, o no tenemos tiempo para hacerlo.
¿Usted aceptaría un auto en el que tuviera que detener el motor y encenderlo de nuevo para poder usarlo (esto se cuenta como chiste pero en realidad no es gracioso) o un televisor que le diera una descarga eléctrica de vez en cuando? Ciertamente no, pero eso lo aceptamos en software. En Marzo de 1999, Microsoft reconoció, en una reunión privada con sus distribuidores, que 5 mil errores de Windows'95 se habían corregido en Windows'98 (¡pero no dijeron cuantos errores habían agregado!). Es decir que millones de copias de software se vendieron dañadas causando un costo irreparable a los consumidores. En síntesis, necesitamos compañías de software serias y con altos niveles de calidad si queremos enmendar el rumbo. Esto significa cambiar también las políticas de mercado y no conformarse con productos parcialmente terminados.
Lamentablemente, mejores soluciones necesitan tiempo y muchas compañias son reacias a invertir en desarrollo y/o investigación si la tecnología cambia en un año. Esa es la paradoja actual, por cierto entendible, pero dañina. Hoy, en vez de pensar, usamos soluciones ya conocidas que no eran útiles hace 20 años. Es cierto que no es bueno reinventar la rueda, pero tampoco es bueno no tener tiempo para inventar algo nuevo. Llegará el momento donde no tendrá sentido invertir en nuevos avances tecnológicos si no podemos usarlos adecuadamente. Cuando ese momento llegué habrá que volver al pizarrón y pensar. Pensar, algo que la rapidez de esté mundo nos hace practicar poco y olvidar.
El uso de la tecnología está determinado en gran medida por accidentes históricos y variables culturales al igual que por la misma tecnología. Los aspectos sociales, culturales y organizacionales de la tecnología son mucho más complicados que los aspectos técnicos. Después que una tecnología se ha establecido, se atrinchera y es muy difícil hacer cambios. Tratemos de recordar esto para el futuro, pues en nuestra área hay muchos ejemplos que exploraremos más adelante, siendo el más obvio, el sistema operativo Windows.
Para terminar, recordemos que los avances tecnológicos no sirven de nada si no se dan los avances sociales correspondientes. De hecho, estudios recientes muestran que en realidad la productividad no ha aumentado pese al nivel de informatización logrado en el mundo [BH98,DK98].
La tecnología avanza tan rápido que no da tiempo a pensar y diseñar soluciones eficientes con ella. A continuación quiero mostrar como muchas de las soluciones que usamos (y en consecuencia, sus diseños) están basadas en suposiciones que ya no son válidas; y como soluciones existentes en el pasado vuelven por sus fueros. Sin embargo, a la larga la carrera tecnológica se vence a si misma. Pero comencemos con un poco de historia.
Tantas veces se han redescubierto las cosas. Pareciera que Windows descubrió las interfaces gráficas, sin conocer la historia de Xerox Parc y luego Apple. Otros creen que la tecnología RISC fue inventada por IBM por su línea de equipos RS-6000, sin saber que fue desarrollada a mediados de los 70. Hagamos un análisis del desarrollo de la computación en estos últimos años. Muchas de las tecnologías han avanzado exponencialmente. Este es el caso de la famosa Ley de Moore que dice que la capacidad de los microprocesadores se dobla cada 18 meses. Esta predicción, realizada en 1965, aún se cumple [HAM99]. Así sucede con la capacidad de un chip de memoria por dólar que ha aumentado 134 millones de veces en los últimos 40 años. Recientemente, un crecimiento similar se puede apreciar en Internet. El número de computadores conectados se dobla cada 15 meses. Esto no puede seguir así pues hoy en día ya más del 20% de los computadores que existen en el mundo están conectados y sino habrían tantos computadores como personas en el año 2010. Por otra parte, el crecimiento de Web es áun más impresionante. Desde 1993, el número de servidores se dobla cada 3 meses, sobrepasando hoy los treinta millones. En forma similar, el tramo principal de Internet en Estados Unidos ha aumentado su capacidad en más de 1000 veces en la década del 80 y posiblemente un valor similar en los 90s. Pese a esto, el tráfico en la red crece aún más rápido.
Si comparamos un computador personal actual con uno típico de hace 20 años, observamos, que la capacidad de almacenamiento ha aumentado en más de 1000 veces y la de procesamiento en al menos 150 veces. Estas diferencias drásticas en desarrollo causan problemas. Por ejemplo, los avances de velocidad en redes (se pronostican varios Gb por segundo) son difíciles de aprovechar ya que los procesadores no son igual de rápidos. Otras tecnologías no han evolucionado de la misma forma, como en la tasa de transferencia de discos que ha aumentado mucho menos, siendo hoy la entrada/salida uno de los cuellos de botella actuales.
Por otra parte los usuarios no hemos ni siquiera duplicado nuestra capacidad y sin embargo a veces me asombra lo fácil que es acostumbrarnos a algo más grande (como dice una de las acepciones de la Ley de Murphy, no importa de que tamaño sea el disco, siempre está casi lleno). Lo mismo podemos decir del software que tampoco ha tenido un avance espectacular, por no decir que los métodos no han cambiado mucho en los últimos 10 años. Aunque es cierto que ahora muchos de los recursos computacionales son baratos, la solución no es usar el diseño que ya teníamos, sin optimizarlo y pedirle al usuario que se compre un computador dos veces más grande y más rápido.
Las características principales del mundo de la computación actual están dadas en su mayoría por el efecto de Internet. Entre ellas podemos mencionar interactividad, procesamiento e información distribuida, digitalización y uso de múltiples medios, uso de recursos en forma compartida y sistemas colaborativos, normalización y sistemas abiertos. Es difícil hacer predicciones, muchos erraron en el pasado. Los ejemplos más famosos son del fundador de IBM, Thomas Watson, en 1943: Creo que hay mercado para 5 computadores y del fundador de Digital, Kenneth Olsen, en 1977: No hay razón para que una persona quiera tener un computador en casa. Algunas especulaciones en el corto plazo incluye la masificación de la fibra óptica, el desarrollo de las redes inalámbricas, la convergencia de los PCs y las estaciones de trabajo Unix, el mayor uso de herramientas colaborativas y por supuesto, la masificación total de los computadores e Internet.
La mayoría de los supuestos en los fundamentos de los sistemas operativos tradicionales ya no son válidos. En el pasado los recursos de hardware (CPU, memoria, disco) eran muy caros y se trataba de reducir su uso. Luego muchas de las soluciones fueron más complicadas de lo necesario, para reducir el costo o el impacto en los recursos compartidos.
Estos supuestos cambiaron en la década de los 80 y junto con el abaratamiento de los costos, también la velocidad de procesadores y memorias aumentó en más de 100 veces. ¿Por qué entonces los sistemas operativos no son al menos 100 veces más rápidos? Para adaptar las soluciones existentes, primero se usaron mejoras en las interfaces (por ejemplo la memoria cache). Sin embargo, un límite máximo dado por la complejidad de la solución misma no podía ser sobrepasado. La solución es simplificar la solución. Este es el paradigma de "rapidez gracias a simplicidad". Uno de los corolarios de este paradigma ha sido el auge de procesadores RISC en vez de CISC.
Por otra parte se olvida la historia. Windows 1.0 nunca fue vendido, Windows 2.0 fue un fracaso, y sólo Windows 3.0 fué un éxito, siendo sólo un buen parche a DOS. Windows NT necesita un mínimo de 16Mb y se sugiere 32Mb. Que pasó con los 64K que necesitaba DOS. ¿Tan barata es la memoria que podemos olvidarnos de ser eficiente? ¿Tan rápidos son los procesadores que podemos olvidarnos de buenas estructuras de datos y algoritmos? Los defensores de Windows NT dirán que es mucho mas que DOS, que incluye un sistema de ventanas, conectividad a redes, multiproceso, etc. Bien, pero por ejemplo Linux con X-Windows funciona con 4Mb y mejor si son 8Mb. ¿Por qué entonces Windows NT necesita tantos recursos? Claramente hay un problema de diseño. El auge de la computación móvil puede ayudar a que se mejoren los diseños en este ámbito, pues no podemos darnos el lujo de tener muchos recursos o usar mucha energía (batería).
Un fenómeno similar ha ocurrido en redes. Antes eran caras y lentas. Ahora son baratas y rápidas. La mayoría de las tecnologías actuales han tenido que adaptarse a los cambios, aunque todavía se puede hacer mucho más. Por ejemplo, ATM fue diseñado en los 60s y ahora vuelve a la palestra, porque es simple y rápido, alcanzando 155 Mb/s. Sin embargo, aún estamos lejos de las velocidades que se pueden alcanzar en fibra óptica, que son de varios Gb/s.
Otro ejemplo es X-Windows, el sistema de ventanas más popular en Unix, que es transparente al protocolo de red usado. Es decir, es un sistema de ventanas distribuido. El protocolo de comunicación usado por X-Windows supone que la red es rápida y que las acciones gráficas en la pantalla son lentas. Sin embargo, hoy en día eso no es cierto, porque aunque las redes son rápidas, están congestionadas y son compartidas por muchos usuarios. Por otra parte, la velocidad de las pantallas gráficas también ha aumentado.
Programar es quizás el corazón de la Ciencia de la Computación. Es el mundo de los algoritmos y estructuras de datos y de los paradigmas de la programación. A través de su evolución, programar ha sido más un arte que una ciencia o una ingeniería. Por algo la famosa trilogía de Knuth sobre algoritmos y estructuras de datos se titula The Art of Computer Programming.
Para muchos programar no es una tarea respetable, para eso están los programadores. Sin embargo debemos distinguir entre las personas que son capaces de diseñar la solución a un problema y convertirla en un programa, de las personas que sólo pueden traducir una solución a un programa. Un programador real como diría Yourdon es el que puede realizar el proceso completo, desde el análisis hasta la implementación.
Programar permite mantener el entrenamiento en la resolución de problemas, ya sean grandes o pequeños. Programar debe ser gratificante. De ninguna manera es denigrante que un ingeniero o lo que sea que pensemos que somos, programe. Al revés, muchas veces nosotros haremos los mejores programas porque somos los que entendemos completamente una solución propia. Otro punto importante es que buen código no es aquel que no se entiende o es más truculento, sino que es el más claro, eficiente y documentado. Muchos ven también el fanatismo de programar como un sinónimo de ser un hacker. Como cualquier adicción en el mundo, los extremos no son buenos. Tampoco hay que confundir hackers con programadores malvados. Hay hackers buenos y hay hackers malos, y los primeros son imprescindibles.
En 1999, un importante ejecutivo de una gran compañía de computación de Estados Unidos me dijo: podíamos darnos el lujo de hacerlo bien porque teníamos los recursos y queríamos entrar a un mercado nuevo. Por supuesto, a nivel técnico siempre nos gustaría hacerlo bien, pero el mercado dice otra cosa. No hay tiempo, no hay recursos, es ahora o nunca. El resultado son productos mal diseñados y mal probados. Actualmente, la única compañía que podría darse el lujo de hacer las cosas bien en el mercado actual es Microsoft. Pero no pareciera querer hacerlo.
Quizás el mejor ejemplo para comenzar, es el famoso problemita del año 2000 o el problema del milenio (aunque en realidad este siglo comenzó en el año 2001). Desde cualquier punto de vista, éste es un problema ridículo con un impacto gigantesco. ¿Deberíamos sentir verguenza? Creo que no.
¿Fue un error considerar sólo 2 dígitos en vez de 4? Todos saben que la razón principal fue usar menos memoria, recurso que hace 20 años era mucho más caro que ahora. Yo creo que no fue ni error ni buen diseño. La verdadera razón es que ninguno de los diseñadores pensó que existiría software que permanecería en funcionamiento por más de 20 años. Ni siquiera hoy en día pensamos eso, contagiados con los cambios anuales del hardware. Es cierto que en algunos casos los programas han evolucionado sin cambiar el diseño original, pero no es lo típico. ¿Por qué seguimos usando ese software? Por las malas costumbres en el desarrollo de software que mencionamos más adelante.
La computación cambia, pero eso no significa que mejora. Muchas empresas prefieran no cambiar software que sabemos que funciona o que sabemos dónde no funciona, el cual sobrevive a cambios sucesivos de hardware y por ende, muchas veces se pierde el código fuente original. Otras han intenato cambiarlo, pero los proyectos han fracasado por no usar las metodologías y/o herramientas adecuadas. Por otra parte, hoy vemos el otro extremo. El uso de recursos es excesivo y el diseño es secundario. Por ejemplo, Windows´98 tiene más del doble de líneas de código que la última versión de Solaris y ocupa mucha más memoria durante su ejecución. El lector puede hacer su propio análisis de cuál sistema operativo está mejor diseñado, sin contar que mientras más líneas de código hay, potencialmente existe un mayor número de errores. No porque la memoria sea hoy en día más barata, debemos abusar de ello.
¿Por qué ocurre esto? Hagamos un paralelo con la ingeniería civil. ¿Se imaginan construir un puente que se cae cinco veces en su périodo de construcción por errores de diseño? Impensable. Peor aún, se imaginan inaugurarlo para descubrir que hay un error fatal cuando hay 100 personas en el. Imposible. Sin embargo la técnica de prueba y error es usada por todo el mundo en programación. Otro paralelo es el número de diseñadores. Una casa es diseñada por uno a tres arquitectos. ¿Qué pasaría si fueran decenas? Luego es construida sin realizar cambios mayores al diseño. ¿Cuántas veces el diseño es cambiado por los implementadores? Muchas, porque en parte muchas veces son las mismas personas y el tener dos roles sin separarlos claramente siempre es un problema. Mucho se hablaba de reusabilidad, pero recién ahora con bibliotecas de clases y patrones de diseño (design patterns) esta palabra tiene sentido. En el pasado era difícil aprovechar lo hecho por otras personas por innumerables razones: código no disponible, distintos lenguajes o ambientes, falta de documentación, etc. La modularidad y la independencia de componentes es vital si queremos integrar productos y tecnologías distintas. También se habla de calidad. Junto con reuso y el utilizar herramientas de control adecuadas, es posible que en el futuro podamos hablar de ingeniería de software [IEEE98]. Yo, aunque algunos griten al cielo, diría que en la mayoría de los casos es artesanía de software. TeX es el mejor ejemplo, pues inicialmente fue el producto de un excelente artesano, Don Knuth, y hace 10 años que no se encuentra un error en su código (¡y por cada error se paga un monto que crece exponencialmente!). Mientras no cambiemos nuestro modo de pensar y no confiemos en que siempre podemos probar y si hay errores no pasa nada, programar seguirá siendo un arte donde pocos serán maestros y la mayoría serán aprendices. Este cambio debe ser profundo, pues hasta las compañias más grandes de software aún no pueden decir que un producto no tiene ningún error. Los ejemplos de Windows que mostramos a continuación son ilustrativos.
Windows'95 contiene cerca de 15 millones de líneas de código. Usando estimaciones de Caper Jones [JON96], un código de este tamaño tiene un número potencial de errores de casi 3 millones, lo que sirve para estimar cuantas pruebas hacer. Para reducir este número a cinco mil, esto significa al menos unas 18 iteraciones en las pruebas [LEW98a]. Aunque posiblemente las compañías de software debieran realizar más pruebas, esto aumenta el costo y retrasa la salida del producto al mercado. Lamentablemente la historia muestra que sacar nuevas versiones de forma rápida muchas veces implica un producto exitoso. Esto ocurre por que el consumidor no discrimina conforme a la calidad. Esto es menos cierto para productos críticos, como un servidor Web. Aquí es más importante la calidad y de ahí el dominio del servidor de Apache sobre un sistema operativo tipo Unix, aunque sea un software de dominio público. Muchas compañías dicen no usar software público porque no tiene soporte. Sin embargo, la mayoría de los productos de PCs, en particular Windows, tampoco tienen soporte. Windows NT tiene alrededor de 25 millones de líneas de código, lo que significa que se deben hacer más pruebas para tener los niveles de confiabilidad necesarios. Por otra parte, Windows NT está, supuestamente, certificado en el nivel de seguridad C2 para su uso en Internet. Sin embargo, un estudio hecho por Shake Communications Pty. Ltd. reveló 104 problemas, algunos de ellos muy serios, que lo hacen vulnerables a hackers [LEW98].
En el caso de software, suposiciones similares a las de los sistemas operativos fueron hechas: recursos caros y escasos. Actualmente los recursos son baratos y abundantes. Sin embargo, también es malo abusar de los recursos y escribir software que necesita mucha memoria o mucho espacio disponible en el disco. Esto es válido sólo cuando es realmente necesario, y la mayoría de las veces no lo es. Este es otro efecto colateral de no tener tiempo suficiente para diseñar software y producir para sacar nuevas versiones lo más pronto posible, porque así lo exige el mercado. Este abuso de la tecnología tiene un efecto dañino. Por ejemplo, si queremos hacer algo más rápido, la solución más usada es comprar un computador más rápido. Sin embargo, más barato y posiblemente más rápido es usar una mejor solución (mejor software, mejor ajuste de parámetros, mejor configuración de la red, etc.).
Quizás una de las áreas de la computación que más prometió y que menos avances ha logrado, es la inteligencia artificial. Ya sea en juegos como el ajedrez o procesamiento de lenguaje natural, los resultados muestran que buenas heurísticas o cajas negras cómo las redes neuronales tienen efectividad parcial. Sin embargo, aún se está muy lejos del Test de Turing. Me permito usar el ajedrez para exponer mis ideas. En Mayo de 1997, Gary Kasparov, el campeón mundial de ajedrez, fue derrotato por Deep Blue de IBM (Big Blue), el campeón de los programas de ajedrez. ¿Ha triunfado la máquina? Analizar este pseudo triunfo de la inteligencia artificial ayuda a poner en el tapete el abuso de términos como sistemas expertos o inteligentes. ¿No es inteligente un buen algoritmo? ¿Es la fuerza bruta inteligente?.
A comienzos de los 50, se predijo que en 20 años habrían programas que derrotarían al campeón mundial de ajedrez. Se ha necesitado más del doble de tiempo para que eso ocurra. ¿Son los programas de computación entonces inteligentes? No, Deep Blue no piensa como una persona (tampoco piensa, pero digamos que hace algo similar para poderlo comparar). Kasparov sabe qué líneas analizar y estudia en profundidad un número pequeño de movidas. Por otra parte, Deep Blue analiza millones de movimientoss y evalúa muchas posiciones, pero lo puede hacer más rápido. La diferencia fundamental es la intuición, la creatividad y la estrategia a largo plazo. Si Deep Blue tuviera la capacidad de evaluar posiciones como lo hace Kasparov, sería invencible. Sin embargo, Deep Blue evalúa una posición en base a heurísticas. Es decir, reglas que funcionan la mayor parte del tiempo, pero otras veces no.
Mientras más complejo sea el juego y mientras el objetivo sea a más largo plazo, más difícil será evaluar una posición dada. Por ejemplo, hace mucho tiempo que el mejor programa de damas es mejor que cualquier humano. ¿Por qué? Porque el número de posiciones en damas es mucho menor y sus reglas son más sencillas, pudiéndose posible evaluar todas las jugadas posibles. Por otra parte, en el juego oriental del Go, donde es necesario ir controlando el tablero poco a poco, sin saber hasta el final si muchas piezas están vivas o no, es más difícil es evaluar, porque la estrategia se plantea a largo plazo. En este caso, la intuición y la experiencia son mucho más importantes que la memoria (como en el Bridge) o la capacidad rápida de cálculo (como en las damas).
La primera lectura errada del triunfo de Deep Blue, es que puede parecer que el computador ha derrotado al hombre. En realidad, lo que ha pasado es que un grupo de expertos en computación y en ajedrez ha programado un computador de gran capacidad y ha conseguido derrotar al campeón mundial. Es decir, un grupo de personas que ha trabajado durante mucho tiempo, en particular analizando cómo derrotar al campeón, ha logrado más que la inteligencia y memoria de un sólo hombre. No me parece tan especial que un programa pueda derrotar a una persona, pues la confrontación no es justa. Deep Blue posee una gran cantidad de procesadores, se sabe más de un millón de partidas de memoria y puede evaluar 200 millones de posiciones por segundo. Un experimento interesante sería comprobar si con menos tiempo por partido, la capacidad de cálculo es menos relevante. ¿Podría Deep Blue derrotar a un grupo de grandes maestros? Lo dudo.
Por otra parte, hay factores ajenos a la inteligencia que afectan la concentración de un jugador de ajedrez. Según algunos ajedrecistas, Kasparov le tuvo mucho respeto a Deep Blue. Otros dicen que tomó muy en serio su papel de defensor de la humanidad, y que su derrota sería un hito en la historia. Por otra parte, Kasparov es un ser humano, con emociones, que necesita comer, beber y dormir, que siente la presión de saber que no puede influir psicológicamente en el adversario. Un adversario que no comete errores ni se cansa. Si recordamos el pasado, una de las razones de todas las defensas exitosas de su título, fue la mayor fortaleza psicológica de Kasparov.
El hombre se derrota a sí mismo todos los días. Kasparov fue derrotado en público. Sólo eso. Cuando un computador pueda leer un libro, entenderlo y explicarlo, ese será un día importante. Por otra parte, Deep Blue es un ejemplo de ingeniería de software, de un buen programa en un mundo con pocos de ellos. Un programa que ha sido mejorado en muchos años, que usa conocimiento de muchas fuentes y que ha tenido tiempo para evolucionar. Si usáramos la tecnología como lo hace Deep Blue, seguramente estaríamos en un mundo mejor.
Por las limitaciones del MacIntosh original que no podía ejecutar dos aplicaciones simultáneamente para que su costo no fuera muy elevado (muy distinto a sus poderosos predecesores: Altos y Lisa), la metáfora de escritorio del MacIntosh no estuvo centrada en los documentos. Por lo tanto el usuario estaba forzado a seleccionar una aplicación y luego escoger un documento, en vez de seleccionar primero un documento y luego la aplicación a usar en ese documento. Esto que parece ser lo mismo, supondría una diferencia fundamental en el desarrollo de interfaces. Sólo desde hace algunos años es posible seleccionar un documento y ejecutar una aplicación predefinida o escogerla de un menú. Citando a Bruce Tognazzini, uno de los diseñadores del MacIntosh: Hemos aceptado que la única manera de crear o editar un documento es abrirlo desde el interior de una aplicación o herramienta. Esto es equivalente a introducir una casa entera dentro de un martillo antes de poder colgar un cuadro en una pared o como poner los dientes dentro del cepillo antes de poder lavarlos (del ensayo Nehru Jacket Computers en [TOG96]).
Analicemos las interfaces actuales. La información que almacenamos está basada en una jerarquía de archivos y directorios en la que navegamos de padre a hijo y viceversa. Es decir, en una sola dimensión. Más aún, debemos recordar en qué lugar está y qué nombre le pusimos a cada archivo que creamos (sin incluir las limitaciones de largo, símbolos, o de no poder poner nombres iguales). Por otra parte, aunque la pantalla es un espacio bidimensional, la interfaz usa muy poco este hecho y tampoco aprende de cómo la usamos y en que orden hacemos las cosas. Por ejemplo, podemos mover un archivo a través de toda la pantalla para tirarlo a la basura y justo al final nuestro pulso nos falla. Resultado: dos iconos quedan uno encima del otro. ¡La interfaz podría haber inferido que lo que intentaba hacer era deshacerme del archivo!. En mi opinión, parte del éxito de Netscape y el modelo impuesto por HTML es, además de una interfaz muy simple, el tener una estructura de enlaces de sólo un nivel. Nuevos paradigmas de representación visual de conocimiento están ya apareciendo [GRE99].
La tecnología computacional que se usa debería ser transparente para el usuario. De hecho, ¿cuantos usuarios novatos sólo usan un directorio para poner todos los archivos que usan? El usuario no tiene para que saber que existen directorios o archivos. Además, no todo puede ser clasificado en directorios y archivos. Un archivo debería poder pertenecer a dos o más clasificaciones distintas y éstas podrían cambiar también en el tiempo. Cómo entendemos las cosas depende de nuestro contexto espacial y temporal. Nuestro alrededor no es estático, pero el computador sin necesidad nos fuerza a guardar nuestros documentos de una manera fija en el espacio y en el tiempo.
Pensémoslo bien. El computador debiera - y puede - nombrar y agrupar archivos y recuperarlos usando su contenido o los valores de algún atributo. Por ejemplo, poder decir: mostrar todas las cartas que estaba editando ayer; y obtener las primeras líneas de cada carta, escogiendo de ellas la que necesito. Otra suposición sin base es que necesitamos una interfaz común para todo el mundo. Las personas son distintas, piensan y trabajan de forma distinta. ¿Por qué no tenemos interfaces que se adaptan a cada usuario, que puedan ser personalizadas y que aprendan de la forma y el orden en que hacemos las cosas? Para facilitar la implementación de nuevas interfaces, debemos botar el pasado, y reemplazar los sistemas de archivos por datos organizados de manera más flexible y poderosa [BYJR99]. Este es nuestro próximo tema.
Uno de los mayores problemas de las bases de datos actuales es la diversidad de modelos, aunque el relacional es predominante. Sin embargo, nuevas aplicaciones necesitan datos que no son tan estructurados y rígidos: multimedios, objetos jerárquicos, etc. Aunque existen modelos adecuados para estos tipos de datos, no existen herramientas que permitan integrar bien dos o más modelos. De hecho, los intentos de incorporar estas extensiones en el modelo relacional no han sido demasiado exitosos.
Si abandonamos las hipótesis del pasado, modelos más poderosos y flexibles pueden ser planteados. Un ejemplo son objetos centrados en atributos dinámicos [BYJR99]. En este modelo los objetos tienen un número dinámico de atributos, cuyos valores tienen tipo y son también dinámicos. Este modelo puede ser considerado una extensión del modelo orientado a objetos donde no existen clases. Sin embargo, también se define un lenguaje de consulta poderoso que puede manejar conjuntos de objetos que cumplen condiciones arbitrarias en los atributos, incluyendo su no existencia o si tienen valor indefinido. Argumentos a favor de este modelo incluyen su simplicidad, flexibilidad y uniformidad; la eliminación de suposiciones respecto a estructuras de datos y su relación con objetos que contienen información; su facilidad de uso; el permitir múltiples vistas de la misma información a través de consultas; y el hecho de generalizar los sistemas jerárquicos de archivos.
Este modelo debiera simplificar la labor de usuarios, programadores y aplicaciones para trabajar con información. Este modelo es también útil en la Web, donde objetos pueden ser compartidos a través de agregar atributos específicos a cada uso de un objeto. Estos objetos pueden ser manipulados y transferidos en forma abierta usando XML.
Adicionalmente a los problemas directamente generados por el contexto tecnológico, hay problemas relacionados con el mercado y el contexto profesional. Por ejemplo el exceso de especialización profesional, la falta de buenos jefes de proyectos de software o la poca interacción entre la teoría y la práctica del desarrollo de software [GLA99]. A continuación profundizamos algunos de ellos.
Las críticas mas recurrentes de la industria son que mucho de lo que se enseña no sirve para nada, que falta aprender más conocimientos prácticos y habilidad para aplicar los conocimientos en el mundo comercial, de modo que la inserción en el mundo real sea más fácil. Que se necesitan ingenieros de software, no científicos [IEEE97]. Lo primero que querría decir es que todo eso es cierto, pues depende del punto de vista. Los objetivos comerciales son de corto plazo y los objetivos de la universidad son de largo plazo. Otras críticas especifícas incluyen la falta de patentes industriales generadas en las universidades y la falta de innovación empresarial.
Lo que una empresa quiere es una persona joven y con experiencia. La falta de conocimiento práctico es difícil de mejorar en un sistema donde la tecnología cambia tan rápido. Por eso los conceptos son los importantes, pues dan adaptibilidad y capacidad de aprendizaje. Es cierto que muchas veces las empresas pierden inversiones realizadas en capacitación, pero es parte de la competencia de mercado. La especialización (por ejemplo, herramientas específicas) y la educación continuada son responsabilidad del empleador, no de la universidad. Sin embargo, uno de los problemas principales es que al invertir en capacitación el empleador puede perder al empleado al conseguir un trabajo mejor remunerado al estar mejor capacitado. Muchas veces ocurre porque el empleador no valoriza en su justa medida la inversión hecha.
Finalmente, tenemos el aspecto comercial. Creo que este es un problema que va más alla de los ingenieros en computación, es un problema de la interacción de la tecnología con la sociedad. No podemos tener sabelotodos que además son buenos vendedores y tienen capacidad empresarial. Muchas veces estas aptitudes son innatas y no son enseñables (muchas veces siento que estoy tratando de enseñar sentido común y los resultados no son alentadores). Ya hay deficiencias en los programas técnicos dada la cantidad actual de materias distintas que existen en computación y que no pueden ser cubiertas en su totalidad.
La investigación conjunta entre la universidad y la empresa siempre se ha visto empantanada por diversos factores. Entre ellos el lento aparato administrativo universitario y la visión de la empresa, muchas veces justificada, de la inhabilidad de la universidad de cumplir con metas a corto plazo. Hay que desarrollar una infraestructura para investigación aplicada y aumentar la transferencia tecnológica, que es exactamente lo que necesitan países en vías de desarrollo para exportar software y mantener su crecimiento en esta área.
Otra forma de incentivar la investigación aplicada, sería crear proyectos de investigación donde sea obligatorio el tener una contraparte industrial, pero no sólo aplicados, sino también en investigación básica, pero de montos menores y también grupos de trabajo más pequeños. Esto permitiría abordar problemas específicos y facilitar el apoyo de las empresas, al ser los riesgos menores.
Por otra parte debemos acercar la universidad a la empresa de un modo útil para ambas partes. Ideas ya mencionadas miles de veces incluyen transferencia tecnológica, estadías cruzadas, etc. Se critica que no hay patentes en la universidad. La misma crítica es válida para las empresas de software chilenas. Primero, toma un tiempo largo. Segundo, no es barato (al menos diez mil US$). Tercero, mientras dura el proceso el resultado no es publicable (que se contrapone al sistema actual de evaluación académica que se basa en publicaciones, aunque esto en Europa está cambiando). Cuarto, las ideas no debieran ser patentables (por ejemplo, un algoritmo).
El llamado movimiento del Open Source (es decir, código fuente gratis) está cada día más fuerte y por ende llama más la atención de los medios. El ejemplo clásico es Linux: ¿Habría su creador imaginado que ahora sería usado por millones de personas? Por otra parte, Microsoft mantiene una disputa con el gobierno federal estadounidense y su software genera dinero y chistes [LEW98a,LEW98b]. Lamentablemente muchos de esos chistes nos debieran dar pena en vez de risa. Esconden importantes verdades y generan hidalgos caballeros andantes.
¿Cómo puede ser que no solamente exista software gratis, sino que además su código fuente sea público? Esto no tiene sentido en un mercado capitalista, donde sería difícil pedirle a miles de programadores que trabajen sin cobrar. Mi opinión personal es que Open Source existe sólo porqué existe Microsoft. Si tenemos que elegir entre un software barato y uno de Microsoft, por muchas razones, seguramente elegiremos el segundo. Si la alternativa es gratuita, estamos dispuestos a correr el riesgo y a probar ese software. Por otra parte, aunque parezca una contradicción, un software gratis puede ser mejor que un software comercial. Si alguna persona encuentra un error y lo informa, en pocos minutos, a través de los grupos de noticias de Internet, podrán recibir una corrección para el problema. Si no, muchos programadores mirarán el código y alguno de ellos encontrará el problema. Este ineficiente mecanismo es a la vez muy efectivo. Otra ventaja es que este proceso es escalable: a medida que el código aumenta de tamaño, más personas pueden involucrarse en el desarrollo. El año pasado un documento interno de Microsoft que habla acerca de los peligros para esta compañía de Open Source se filtró en Internet (ver éste y otros temas relacionados en [SAN98,IEEE99,LEW99a,LEW99b]).
Microsoft es un monopolio de facto. Cada dos o tres años, millones de usuarios deben actualizar su copia de Windows, sin obtener compatibilidad completa con las versiones antiguas y con precios que aumentan con el tiempo: hay que aprovechar el mercado cautivo. Es como tener que cambiarse de casa frecuentemente y no siempre para mejor. Recientemente Bill Gates ha publicado sus 12 reglas para el uso eficaz de Internet en las empresas [GAT99], que muestran que está totalmente convertido al mundo del correo electrónico (en 4 años). También ha aprendido las ventajas del software gratis, en particular cuando también permite aniquilar a la competencia: Explorer. Desde el punto de vista económico, el desarrollo de software en Microsoft no es el más efectivo (de hecho, la mayoría de los problemas los encuentran los usuarios, que no siempre pueden obtener ayuda directa para resolverlos), pero sin duda es el más eficiente. Microsoft es tal vez la única compañía que puede parar esta bola de nieve. Hasta podría darse el lujo de desarrollar en 5 años un verdadero sistema operativo y aplicaciones con interfaces mucho mejores, como las que describimos más adelante. Pero esto no va a pasar, porque significa ganar menos. Dependiendo del resultado del juicio anti-monopolio y el avance del código público, este milenio será la era de la información o la era de Microsoft.
Me gustaría comenzar citando a Peter Freeman [FRE97]:
Si comprometemos el núcleo de la computación, corremos el riesgo de perder habilidades básicas de largo plazo. Si fallamos en tomar en cuenta las preocupaciones de los profesionales del área, corremos el riesgo de quedar obsoletos. La clave es alcanzar el balance correcto, pero hay más de una manera de lograrlo.
Hay que preocuparse tanto de la forma como del contenido. Si se generan buenos profesionales, éstos serán agentes de cambio [GGT97]. Ese debiera ser uno de los objetivos principales de la universidad y creo que ha sido también para mi una motivación personal importante para hacer lo que hago.
La mayoría de lo que aprendemos en nuestra vida sirve poco en ella, principalmente conocimiento técnico. Lo importante es la formación asociada a ese aprendizaje, el desarrollo de capacidades lógicas y analíticas, el poder abstraer y conceptualizar y resolver problemas. El objetivo no es conocimiento per se, es formativo. Es aprender a aprender constantemente. Creo que este proceso se puede hacer mejor, integrando conocimiento y nuevas herramientas en cursos novedosos, donde el alumno entiende mejor la meta final. Los objetivos principales deben ser flexibilidad, adaptibilidad, enfatizar conceptos y facilitar el aprendizaje continuo.
Todas las ciencias han evolucionado dentro de un contexto real, no por si solas, siendo el origen del cálculo el ejemplo más clásico. Por otra parte, en el pasado hubieron personas que conocían gran parte del conocimiento científico humano. Hoy en día esto es muy difícil, forzando al trabajo en grupo y multidisciplinario. Estos dos hechos debieran ayudar a plantear nuevas formas de enseñar. Dos líneas distintas de acción son las de diseñar profesionales distintos, en base a los tres elementos involucrados: personas, procesos y tecnología [IEEE97], por ejemplo, un arquitecto de la información [BYN99]; o cambiar drásticamente como enseñamos integrando todos los contenidos clásicos propuestos [ACM] en un sólo curso basado en la resolución de problemas [BY00].
Aunque estas propuestas son preliminares, creo que son un primer paso para diseñar mejores curricula, más completos y coherentes, y enseñarlos de una manera distinta, motivando al estudiante y explicandole claramente porque está aprendiendo cada tema y las interrelaciones con su entorno. En resumen, integrando todo, volviendo de cierta manera al renacimiento, al pensamiento enciclopédico e ilustrado. También queda claro que hay que incentivar el pensamiento crítico y enfatizar en los aspectos de diseño.
Este artículo es a la vez un ensayo sobre los múltiples problemas de nuestra área y un pequeño grito de cordura. Tanto en la vida personal como en la vida profesional, aceptamos tantas cosas como ciertas, como hipótesis fundamentales, las cuales nunca cuestionamos. Del mismo modo, las ideas expresadas aquí deben ser tomadas sólo como un punto de vista más a ser considerado. Sin embargo, espero que estas líneas apelen a vuestro sentido común, ese sentido tan importante y a la vez tan escaso, y de paso crear un poco de conciencia en los múltiples problemas de nuestra área y de nuestro quehacer cotidiano. Es una crítica constructiva y sin ninguna intención divisiva [GLA99].
Agradezco los comentarios y motivaciones de Omar Alonso, Juan Alvarez, Karin Becker, Tania Bedrax-Waiss, Carlos Castillo, Helena Fernández, Terry Jones, Miguel Nussbaum, Greg Rawlins y Jorge Vidart. El contenido en extenso de este artículo está disponible en http://www.baeza.cl/manifest/manifest.html y data de 1999.
Referencias
[ACM] ACM-IEEE Curricula Recommendations for Computer Science and for Information Systems, http://www.acm.org/education.
[BY00] Ricardo Baeza-Yates, Un Curso Integrado para Primer Año, Congreso Iberoamericano de Educación Superior en Computación, Ciudad de México, Septiembre 2000.
[BYJR99] Ricardo Baeza-Yates, Terry Jones, Greg Rawlins, New Approaches to Manage Information: Attribute-Centric Data Systems, SPIRE'2000, IEEE CS Press, 2000.
[BYN99] Ricardo Baeza-Yates, Miguel Nussbaum, The Information Architect: A Missing Link, DCC, Univ. de Chile, Technical Report, 1999 (www.baeza.cl/manifest/infarch.html). Versión en español presentada en el Congreso Iberoamericano de Educación Superior en Computación, Ciudad de México, Septiembre 2000.
[BH98] Erik Brynjolfsson y Lorin M. Hitt, Beyond The Productivity Paradox, Communications of The ACM, volume 41:8, Agosto 1998, pp. 49-55.
[DEN97] Peter J. Denning, A New Social Contract for Research, Comm. of ACM 40(2), Febrero 1997, pp. 132-134.
[DK98] Sanjeev Dewan y Kenneth L. Kraemer, International Dimensions of the Productivity Paradox, Communications of the ACM 41(8), Agosto 1998, pp. 56-62.
[FRE97] Peter Freeman, Elements of Effective Computer Science, IEEE Computer, Noviembre, 1997.
[GGT97] David Garlan, David P. Gluch y James E. Tomayko, Agents of Change: Educating Software Engineering Leaders, IEEE Computer 30(11), Noviembre 1997, pp. 59-65.
[GAT99] Bill Gates, Business @ The Speed of Thought, Warner Books, 1999.
[GLA99] Robert L. Glass, Is Criticism of Computing Academy Inevitably Divisive?, Comm. of the ACM 42(6), Junio 1999, pp. 11-13.
[GRE99] Ilan Greenberg, Facing Up to New Interfaces, IEEE Computer, Abril 1999, pp. 14-16.
[HAM99] Scott Hamilton, Taking Moore's Law Into the Next Century, IEEE Computer, Enero 1999, pp. 43-48.
[IEEE97] IEEE Special Issue, Status of Software Engineering Education and Training, IEEE Software, Nov/Dic 1997.
[IEEE98] IEEE Special Issue on the Future of Computing and Software Engineering, IEEE Computer, Enero 1998.
[IEEE99] IEEE Special Issue on Linux, IEEE Software, Enero 1999.
[JON96] Capers Jones, Software Estimating Rules of Thumb, IEEE Computer, Mayo 1996, pp. 117-118.
[LEW98a] Ted Lewis, "Joe Sixpack, Larry Lemming and Ralph Nader", IEEE Computer, Julio 1998, pp. 107-109.
[LEW98b] Ted Lewis, What to Do About Microsoft, IEEE Computer, Septiembre 1998, pp. 109-112.
[LEW99a] Ted Lewis, The Open Source Acid Test, IEEE Computer, Febrero 1999, pp. 125-128.
[LEW99b] Ted Lewis, Asbestos Pajamas: An Open Source Dialogue, IEEE Computer, Abril 1999, pp. 108-112.
[NOR98] Donald A. Norman, The Invisible Computer, MIT Press, 1998.
[REE98] Karl Reed, Why the CS should help chart the Future of IT. IEEE Computer, Julio 1998, pp. 77-78.
[SAN98] James Sanders, Linux, Open Source, and Software's Future, IEEE Software, Sept./Oct. 1998, pp. 88-91.
[TOG96] Bruce Tognazzini, Tog on Software Design, Addison Wesley, 1996.