Se han escrito excelentes artículos sobre el tema, en general resaltando el disparate jurídico/legal que resultaría de aprobarse tal iniciativa. Otros, en cambio, han destacado las consecuencias sociales y culturales de este tipo de avances contra la difusión de la información.

En definitiva, se trata de un tema por demás complejo, en el que confluyen cuestiones que tienen que ver con las leyes, la cultura, la tecnología y la sociedad. No es mi intención hacer un análisis exhaustivo ni mucho menos, sino simplemente dejar aquí un par de referencias para encontrarle la punta al ovillo.

A continuación, una conferencia del reconocido jurista estadounidense Lawrence Lessig, sobre cómo este tipo de leyes tienen exactamente el efecto contrario al que las inspira, matando y no promoviendo la creatividad y la cultura.

Lessig ha escrito un excelente libro sobre este tema, llamado Cultura Libre (no tema descargarlo, está disponible bajo una licencia libre). Su lectura es más que recomendable, ya que además de un brillante y claro análisis legal nos ilustra con varios ejemplos notables de la evolución de las leyes, las costumbres y la cultura a través de los años.

El siguiente vídeo corresponde a un discurso pronunciado por el reconocido director español Álex de la Iglesia, por entonces Presidente de la Academia de Cine española, en ocasión de la entrega de los premios Goya 2011. En aquel momento se había planteado un gran debate con relación a un proyecto de ley de regulación de webs y protección de la propiedad intelectual (conocido como “Ley Sinde“).

Este discurso tiene el enorme valor de ser pronunciado por uno de los supuestos perjudicados por la mal llamada “piratería”.

El mundo cambió. La tecnología posibilita formas de creación y acceso a la cultura dificilmente imaginables hace poco tiempo. Quienes ven derrumbarse sus pingües negocios alzan la voz pidiendo regulaciones y resarcimiento económico. Y, cuándo no, ponen como excusa para limitar lo que todos podemos hacer, los derechos de los artistas, a quienes en general nunca beneficiaron demasiado (excepto por unos pocos a los que hicieron millonarios y hoy son parte de la corporación).

No podemos limitar las posibilidades de las herramientas que hoy tenemos a nuestra disposición por tratar de mantener un modelo de negocio obsoleto. La cultura es, cada vez más, de todos.

Spolsky alerta sobre la creciente tendencia de muchas universidades a sobre-simplificar la currícula de las carreras de Ciencias de la Computación (con Java como “lenguaje insignia”), con el único objetivo de producir mayor cantidad de egresados y en menos tiempo. La consecuencia es directa: cada vez más abundan programadores que poco entienden de conceptos de programación (corrección, recursión, complejidad, paralelismo, entre tantos otros) y para los cuales los mecanismos “internos” de los sistemas informáticos (gestión de memoria, interacción con el sistema operativo, comunicación entre procesos, etc.) son completamente esotéricos.

El principal impulsor de este embrutecimiento es cierto sector de la llamada “Industria del Software” que requiere de mano de obra barata y de pobre formación, y empuja a las instituciones educativas a proveerles “recursos” tan rápido y en tanta cantidad como sea posible (ni qué decir de las instituciones educativas que ceden a esta presión).

Nadie está en contra de hacer la tarea del programador más simple, ni mucho menos de la evolución de los lenguajes y las metodologías de desarrollo de software. Lo que se reprocha aquí es la negación de la realidad como forma de evasión. Esto es: la necesidad de dotar a los programadores de ciertos conceptos, aún cuando esto provoque la deserción de quienes no puedan llegar a dominarlos (y mal que le pese al referido sector de la “Industria”).

Los Riesgos de las Universidades-Java

por Joel Spolsky
Jueves 29 de diciembre de 2005

Chicos perezosos.

¿Qué pasó con el trabajo duro?

Un seguro indicio de mi decadencia hacia la senilidad son mis continuas quejas y lamentos sobre “los chicos de hoy”, y cómo ya no quieren o no pueden hacer cosas difíciles.

Cuando yo era un muchacho, aprendí a programar con tarjetas perforadas. En esos tiempos si cometías un error, no tenías ninguna de esas modernas funciones como la tecla “backspace” para corregirlo. Tenias que tirar la tarjeta y empezar todo de nuevo.

Cuando empecé a entrevistar programadores en 1991, les dejaba usar generalmente cualquier lenguaje que quisieran para resolver los problemas de programación que les planteaba. El 99% de las veces, ellos elegían C.

Ahora ellos tienden a elegir Java.

No me malinterpreten: no hay nada malo con Java como lenguaje de implementación.

Un momento, quiero rectificar eso último. No digo, en este artículo en particular, que haya algo de malo con Java como lenguaje de implementación. Hay un montón de cosas mal con Java, pero tendrán que esperar hasta otro artículo.

En cambio, lo que quiero decir es que Java no es, generalmente, un lenguaje de programación lo suficientemente difícil para que pueda ser usado para distinguir entre excelentes programadores y programadores mediocres. Puede ser un buen lenguaje para trabajar, pero ese no es el tema de hoy. Puedo ir incluso mas allá y decir que el hecho de que Java no sea lo suficientemente difícil es una característica, no un bug, pero que tiene ese problema.

Si puedo ser atrevido, diría que en mi humilde experiencia han sido dos las cosas tradicionalmente enseñadas en las universidades como parte de la carrera de Ciencias de la Computación (CS) las que mucha gente nunca llega realmente a comprender: punteros y recursión.

En aquellos tiempos lo normal era empezar la universidad con un curso de estructuras de datos, con listas enlazadas, tablas hash y, por qué no, con un uso intensivo de punteros. Esos cursos eran frecuentemente usados como filtros: eran tan difíciles que cualquiera que no pudiera soportar el desafío mental de un grado en CS se daría por vencido, lo que era bueno, porque si piensas que los punteros son difíciles, espera hasta intentar probar cosas en teoría de punto fijo.

Todos esos chicos que lo habían hecho muy bien en la secundaria escribiendo juegos de “pong” en BASIC para su Apple II, iban a la universidad, tomaban el curso CompSci 101, sobre estructuras de datos, y cuando llegaban al asunto de los punteros, sus cerebros estallaban completamente; y lo próximo de lo que tenías noticias es que estaban especializándose en Ciencias Políticas, porque la escuela de leyes parecía ser una mejor idea. He visto todo tipo de de índices de deserción en CS y usualmente están entre el 40% y el 70%. Las universidades tienden a ver esto como un derroche; yo creo que es sólo la poda necesaria de gente que no va a ser feliz o exitosa en una carrera de programación.

El otro curso difícil para muchos jóvenes estudiantes de CS era el curso donde aprendías programación funcional, incluyendo programación recursiva. MIT puso una barrera muy alta en esos cursos, creando un curso obligatorio (6.001) y un libro de texto (Estructura e Interpretación de Programas de Computadora de Abelson y Sussman, el cual era usado en docenas o quizás cientos de carreras de CS prestigiosas como el estándar de facto para la introducción a las Ciencias de la Computación. (Puedes, y deberías echarle una ojeada a la antigua versión de las clases en línea).

La dificultad de esos cursos es asombrosa. En la primera clase has aprendido casi todo Scheme, y ya has sido introducido a la función de punto fijo que toma otra función como parámetro. Cuando me esforzaba en pasar un curso similar, CSE121 en Penn, observaba cómo muchos sino la mayoría de los estudiantes simplemente no lo lograba. La materia era muy difícil. Inclusive escribí un largo email de lloriqueando a mi profesor diciendo que “simplemente no era justo”. Alguien en Penn debe haberme escuchado (o a alguno de los otros llorones), porque ese curso se dicta ahora con Java.

Desearía que no hubiesen escuchado.

Aquí radica el quid del debate. Años de lloriqueo de estudiantes perezosos como yo, combinados con quejas de la industria acerca de cuan pocos graduados en CS salen de las universidades americanas, han pagado su precio, y en la ultima década un gran numero de otrora perfectamente buenas universidades se han vuelto 100% Java. Esta de moda, a los reclutadores que usan “grep” parece gustarles, y, lo mejor de todo, no hay nada lo suficientemente difícil en Java como para filtrar aquellos programadores sin la parte del cerebro que entiende punteros y recursión. Así es que la deserción es menor, y los departamentos de ciencias de la computación tienen mas alumnos y mayores presupuestos y todo está bien.

Los afortunados chicos de esas Universidades-Java nunca van a toparse con raros fallos de segmentación tratando de implementar tablas hash basadas en punteros. Nunca se van a volver locos tratando de empaquetar cosas en bits. Nunca tendrán que ocupar sus cabezas en cómo en un lenguaje puramente funcional, el valor de una variable nunca cambia, y aun así, ¡cambia todo el tiempo! ¡Una paradoja!

Ellos no necesitan esa parte del cerebro para obtener un 4 en la materia.

¿Soy sólo uno de esos viejos cascarrabias anticuados, vanagloriándose acerca de cuán duro era sobrevivir a todas esas dificultades?

Rayos, en 1900, el Latín y el Griego eran asignaturas requeridas en la universidad, no porque sirvieran de algún propósito, sino porque de alguna manera eran considerados un requisito obvio de la gente educada. De cierta manera mi argumento no es diferente del argumento expuesto por la gente pro-Latín: “[El Latín] entrena tu mente. Entrena tu memoria. Desembrollar una sentencia en Latín es un excelente ejercicio del pensamiento, un verdadero acertijo intelectual y una buena introducción al pensamiento lógico”, escribe Scout Barrer. Pero ya no puedo encontrar una sola universidad que requiera Latín. ¿Son los punteros y la recursión el Latín y el Griego de las ciencias de la computación?

Ahora, admito que programar con punteros no es necesario en el 90% del código escrito en la actualidad, y de hecho es totalmente peligroso en el código de producción. OK. Está bien. Y que la programación funcional no es muy empleada en la práctica. De acuerdo.

Pero todavía sigue siendo importante para algunos de las tareas más excitantes en programación. Sin punteros, por ejemplo, nunca serías capaz de trabajar en el Kernel de Linux. No puedes entender una sola línea del código de Linux, o de hecho, de cualquier sistema operativo, sin realmente entender punteros.

Sin entender programación funcional, no podrás inventar MapReduce, el algoritmo que hace Google tan masivamente escalable. Los términos Map y Reduce vienen de Lisp y la programación funcional. MapReduce es, en retrospectiva, obvio para cualquiera que recuerde de su clase equivalente a 6.001 que los programas puramente funcionales no tienen efectos colaterales y por ende son trivialmente paralelizables. El simple hecho que Google inventara MapReduce, y no Microsoft, dice algo del por qué Microsoft está aun jugando a lograr que funcionen algunas características básicas de búsqueda, mientras Google se ha movido ya al siguiente problema: construir Skynet^H^H^H^H^H^H, la mayor supercomputadora masivamente paralela del mundo. Simplemente no creo que Microsoft entienda completamente cuan retrasados están en ese campo.

Pero mas allá de la importancia a simple vista de los punteros y la recursión, su valor real radica en que construir grandes sistemas requiere del tipo de flexibilidad mental que adquieres aprendiéndolos, y de la actitud mental que necesitas para no huir de los cursos en donde son enseñados. Punteros y recursión requieren cierta habilidad para razonar, para pensar en abstracciones, y más importante, para ver un problema en diversos niveles de abstracción simultáneamente. Por lo tanto, la habilidad para entender punteros y recursión esta directamente correlacionada con la habilidad de ser un gran programador.

No hay nada en grado académico 100% Java que realmente descarte a los estudiantes que carecen de la agilidad mental para tratar con esos conceptos. Como empleador, he visto que las Universidades 100% Java han empezado a producir en serie una buena cantidad de graduados quienes simplemente no son lo suficientemente listos para trabajar como programadores en nada mas sofisticado que “Sólo Otra Aplicación Contable en Java”, aunque se las han arreglado para colarse a través de la (ahora simplificada) carrera. Esos estudiantes nunca sobrevivirían al 6.001 del MIT o al CS 323 en Yale y, francamente, esa es una razón por la cual, como empleador, un título en CS del MIT o Yale tiene más peso que uno de Duke, que recientemente se hizo 100%-Java, o de Penn, donde remplazaron Scheme y ML por Java tratando de enseñar la materia que casi nos mata a mis compañeros y a mi, CSE121. No es que no quiera contratar chicos listos de Duke o Penn, lo hago, es sólo que es mucho más difícil para mí darme cuenta de cuáles son. Yo estaba acostumbrado a decir que los chicos listos eran aquellos que podían desmenuzar un algoritmo recursivo en segundos, o implementar funciones de manipulación de listas enlazadas usando punteros tan rápido como podían escribir en la pizarra. Pero con graduado sde Universidades-Java, no puedo saber si padecen esos problemas a causa de haber sido mal educados o si los padecen porque realmente carecen de esa parte del cerebro que van a necesitar para ser buenos programadores en el trabajo. Paul Graham los llama “Blub Programmers“.

Ya es bastante malo que las Universidades-Java fallen en filtrar los chicos que nunca van a ser buenos programadores, algo que las universidades podrían justificablemente decir que no es su problema. Después de todo es la industria, o al menos los reclutadores-que-usan-grep, quien está pidiendo a gritos que se enseñe Java.

Pero las Universidades-Java fallan también en entrenar las mente de los chicos para ser hábiles, ágiles y lo suficientemente flexibles para lograr buen diseño de software (y no me refiero al “diseño” OO, donde gastas incontables horas acomodando tu jerarquía de objetos, o preocupándote de “problemas” superfluos como “tiene-un” vs. “es-un”). Necesitas entrenamiento para pensar en las cosas a varios niveles de abstracción simultáneamente, y ese tipo de pensamiento es exactamente lo que necesitas para diseñar excelentes arquitecturas de software.

Puedes estar preguntándote si la enseñanza de programación orientada a objetos (OOP) es un buen sustituto de los punteros y la recursión para el filtrado. La respuesta rápida: no. Sin debatir acerca de los meritos de la OOP, simplemente no es lo suficientemente difícil para filtrar a los programadores mediocres. OOP en las universidades consiste básicamente en memorizar un puñado de términos de vocabulario como “encapsulacion” y “herencia” y tomar exámenes del tipo “multiple-choice” acerca de las diferencias entre polimorfismo y sobrecarga. No más difícil que memorizar fechas destacadas y nombres en una clase de historia, la OOP tiene desafíos mentales inadecuados para espantar a los estudiantes de primer año. Cuando te enfrentas con un problema de OOP, tu programa aun funciona, sólo que es algo difícil de mantener. Supuestamente. Pero cuando te enfrentas a un problema con punteros, tu programa produce línea Fallo de segmentación y no tienes ni la menor idea de lo que está pasando, hasta que te paras, tomas una fuerte bocanada de aire y tratas de forzar tu mente a trabajar en dos diferentes niveles de abstracción simultáneamente.

Los reclutadores-que-usan-grep, de hecho, son ridiculizados aquí, y por un buen motivo. Nunca he conocido alguien que pueda usar Scheme, Haskell y punteros en C, que no pueda entender Java en dos días, y crear mejor código en Java que gente con cinco años de experiencia en Java. Pero trata de explicar eso al zombie de Recursos Humanos.

¿Pero que hay de la misión del compromiso con las CS de las facultades de CS? ¡Ellas no son escuelas vocacionales! No debería ser su trabajo entrenar gente para trabajar en la industria. Eso queda para los terciarios y los programas de capacitación del gobierno para trabajadores desplazados, dirán. Ellas se suponen que están para dar a los estudiantes las herramientas fundamentales para vivir sus vidas, no para prepararlos para sus primeras semanas de trabajo. ¿No es cierto?

Aun así, las CS son demostraciones (recursión), algoritmos (recursión), lenguajes (cálculo lambda), sistemas operativos (punteros), compiladores (cálculo lambda), y entonces la conclusión es que la Universidad-Java que no enseña C y no enseña Scheme, tampoco está enseñando realmente ciencias de la computación. Tan inútil como el concepto de currificación de funciones puede serle al mundo real, es un obvio prerrequisito para un graduado en CS. No puedo entender por qué los profesores en las comisiones curriculares de las facultades de CS han permitido que sus programas sean embrutecidos a tal punto que no sólo no pueden producir programadores operativos, sino que ya ni siquiera pueden producir graduados en CS que puedan obtener PhDs y puedan competir por sus puestos de trabajo. Oh, esperen. No importa. Quizás entienda.

Si volvemos en el tiempo y analizamos las discusiones que tomaron lugar en el mundo académico durante el “Gran Levantamiento Java”, encontraremos que la mayor preocupación fue que Java no era lo suficientemente simple para ser usado como un lenguaje de enseñanza.

Mi Dios, pensé, ¡están tratando de embrutecer la curricula aun mas! ¿Por que mejor no le llevamos la comida a la boca a los estudiantes? Dejemos que los ayudantes de cátedra den los exámenes por ellos también, entonces nadie se cambiara a Estudios Americanos. ¿Cómo se supone que alguien aprenderá algo si la curricula ha sido cuidadosamente diseñada para hacer todo más fácil de lo que ya es? Parece haber una comisión de trabajo (PDF) intentando idear un subconjunto simple de Java que pueda ser enseñado a estudiantes, produciendo documentación simplificada que esconde cuidadosamente toda esa basura EJB/J2EE de sus tiernas mentes, de manera tal que no tengan que preocupar sus cabecitas con otras clases que no necesiten para resolver sus aun más fáciles problemas de CS.

La interpretación mas compasiva de por qué las facultades CS son tan entusiastas en embrutecer sus clases es porque ello les dará más tiempo para enseñar verdaderos conceptos de CS, así no necesitaran dos clases enteras para esclarecer a los alumnos las diferencias entre, digamos, un int y un Integer en Java. Bueno pero si ese fuera el caso, 6.001 tiene la respuesta perfecta: Scheme, un lenguaje de enseñanza tan simple que el lenguaje entero puede enseñarse a estudiantes brillantes en unos 10 minutos; entonces puedes gastar el resto del semestre enseñando puntos fijos.

Fiu…

Voy a regresar a los unos y ceros.

(¿Te tocaron unos? ¡Bastardo suertudo! A nosotros nos tocaron todos ceros.)

Esta traducción está basada en la versión disponible en el Wiki de Joel Spolsky, corregida y adaptada por mí.

Así es que nos encontramos por todas partes con “presidentes” y “presidentas“, “concejales” y “concejalas“. A nadie parece molestarle, por ejemplo, que la palabra “persona” tenga género femenino. Al menos por ahora…

¿Cuál es la clave del problema? Aclarando que mi única experiencia con el idioma castellano es haberlo hablado más de 30 años (y alguna vez haber tenido que repetir de memoria la conjugación de algún verbo irregular), voy a intentar explicar el origen del equívoco.

El género de una palabra no hace referencia al sexo del objeto que denota (si este lo tuviere), sino que es solamente una categoría gramatical. En el contexto de una frase, el género del elemento primario actúa como una restricción sobre los elementos subordinados a él. (Esto es lo que nos impide escribir “la cielo estaba nublada y oscuro”.)

Debemos notar además, que hay palabras que no tienen género. Un ejemplo simple es “residente“: la persona (hombre o mujer) que reside en un lugar. Su género es neutro: bien podemos hablar de “el residente“, como de “la residente“. Justamente, la aberración lingüística que se está generalizando por estos tiempos, nos llevaría a hablar de “la residenta” (y para ser algo más coherentes, aunque sigamos destruyendo el idioma, deberíamos hablar de “el residento“). Pensar en esto debería hacer que cualquiera se mordiera la lengua al tratar de decir “la presidenta“. (Si no ve lo grueso del error, intente encontrar alguna diferencia gramatical entre “residir” y “presidir“.)

De la misma manera, cuando hablamos de una persona, ésta (note el género femenino) bien puede ser un hombre. Los hombres también son personas (no son “personos“), y esto nada dice de su condición sexual biológica (mucho menos de sus preferencias sexuales, o de su rol en la sociedad).

El periodista y novelista Arturo Pérez-Reverte, integrante de la Real Academia Española, ha escrito una muy buena crítica sobre esta deformación ridícula del idioma castellano, titulada “Los miembros y las miembras“. Por contraparte, desde movimientos feministras se impulsa la profundización de la ofensa lingüística. Por ejemplo, Mercedes Bengoechea y Eulalia Lledó (que increiblemente tienen títulos universitarios en letras) proponen esto ya que, según afirman, “hablar no es nunca neutro y las normas de uso defienden la subordinación de las mujeres“. Ahora resulta ser que tenemos un idioma machista y hay que romperlo en pedazos para igualar las condiciones de hombres y mujeres…

Ni los docentes de los distintos niveles educativos parecen darse cuenta (¿qué nos queda para las personas comunes y corrientes que poco sabemos de gramática?). Este tema es analizado a fondo (incluyendo la comparación con situaciones similares en otros idiomas) por el Doctor en Lingüística Javier Arias Navarro en su artículo: “Género y arrobas“. Quizás lo más desconcertante es que hasta la Real Academia Española se ha sumado a este ridículo, habiendo aceptado el término “modisto” para denotar a un hombre que fabrica ropa, cuando la terminación “ista” no denota género (quien sigue los designios de la moda es un “modista“, de la misma manera que quien escala los Alpes es un “alpinista” y no un “alpinisto“).

Y claro, luego es común escuchar que cada vez se habla peor, que los jóvenes ya no saben escribir (como si algún efecto ambiental hiciera que las nuevas generaciones se vuelvan cada vez más idiotas). ¿Qué otra cosa podría esperarse, si se sigue destruyendo la gramática del idioma?

Cada vez que escucho decir alguna de estas barbaridades a alguien supuestamente ilustrado (como un periodista, un docente universitario o en el texto de una norma legal) recuerdo las últimas palabras del Emperador romano Julio Cesar, quien al descubrir entre sus atacantes a su hijo adoptivo, estando ya al borde de la muerte sólo pudo decir:

¿Tú también, Bruto?

A continuación, la transcripción de la grabación (he quitado varias interjecciones y muletillas):

Alumno: ¿Qué es EJB?

Docente: ¿EJB? Enterprise Java Beans, Enterprise Java Beans es el… la Enterprise Java Beans son… dijéramos, los Beans, los Beans Java de las Empresas (risas). Pero… ¿qué es un Bean? Bean es un poroto (risas). No sirven para nada. Nos vuelven locos con estas porquerías (risas).

En realidad una Java Bean es una clase, que tiene métodos automatizados que lo definen. Hay métodos que… hay métodos… hay una clase que, que hace una clase, entonces hace de todo, van y le meten un método, un, un, un Java Bean Method. Entonces ¿un Java Bean Method qué es? Es un método, ustedes le ponen el nombre, les arma una serie de ventanas y les va a terminar agregando un método que ustedes podrían crear un método. Pero, dijéramos que toda la infraestructura les va a crear un método. Ese método, en realidad, es, podría ser un método para recuperar, o podría ser un método para escribir, o podría ser un método para grabar. O podría ser cualquiera de los otros métodos que los construirían ustedes. En general los que están construidos son los Enterprise Java Beans Service, que son métodos que uno directamente apretando botón derecho pin, pun, pun, pun, se van generando.

Beans es, es, es, es, dijéramos… y ustedes ven que hay… que hay Beans en todos lados, ¿no? Porque hay Beans en la parte de presentación, hay Beans en la parte de negocio y… y puede haber Beans en la parte de bases de datos también. Porque en realidad lo que son Beans son conceptos de clases, clases para ellos son Beans.

Alumno: ¿Clases específicas, Profesor?

Docente: Si, pero… es como que son objetos. Son específicas porque son clases que, te vuelvo a decir, que leen, o que graban, o que recuperan, o que… y entonces, en realidad, están propuestas con una serie de accesos rápidos. Fíjense que ustedes están todo dentro de un server, y ese server, o sea, eso se pone… se arman paquetes… tecnológicos… tecnológicos portes de… en donde están… interrelacionados con las otras capas, y las interrelaciones siempre las hacen a través de esos componentes J2EE. Los componentes, o sea, los software de las clases implementadas son componentes, o sea, por eso, a ver: componente, componente, componente, siempre componentes de las tres capas. Entonces ¿los componentes qué son? Software. Pero el software ese ¿dónde fue pensado? Fue pensado en las clases. Pero ahora son componentes, o sea que son software. Yo voy armando software y cuando, digo, se genera hay una serie de métodos que se generan automaticamente, no necesariamente en el J2EE, sino también en Java, pero por ejemplo que son los métodos setter and getter. Los métodos setter and getter es como que son métodos que ya están definidos, que uno directamente lo único que hace es cambiarle la variable que usa.

También pueden hacer el proyecto con Enterprise Java Beans, con elementos de J2EE. Algunas partes del sistema pueden hacer. Si estás e una relación cliente/servidor. O sea, miren toda la tengología que podríamos llegar a tener y aplicar en un ejercicio. En líneas generales si quieren aplicar todo, está a disposición de ustedes, el software lo permite, pero van a tener que sentar el culo y trabajar mucho, lo cual dudo que estén predispuestos a hacerlo. Aunque eso les reditúe mucho.

Como puede apreciarse, el Lic. Rubén Fernandez Iriart no tiene la más remota sospecha sobre tema que está tratando (y ni hablar de su uso del idioma castellano). Peor que eso, en vez de disculparse y comprometerse a responder en una clase posterior (como haría cualquier persona con un poco de vergüenza), encara hilvanando un sinfin de frases sin sentido, encadenando las palabras “clase“, “objeto“, “componente“, “mensaje“, “capa“, “servicio“, “paquete“, “software“, etc. Para terminar, quizás tratando de justificar su propia ignorancia y no quedar tan en evidencia, finaliza la explicación desmereciendo y rebajando a sus alumnos, dando a entender que si no logran comprender, es por su falta de disposición (y no por la ignorancia de quien habla).

No clasifico este artículo en la categoría “humor” porque yo también me encontré con este tipo de docentes (casualmente en la UTN Fac. Córdoba) y a punto estuve de dejar la informática por ello. Quizás el daño más grande fue que, al ver la ignorancia de este tipo de “profesores“, sobrevalué mis conocimientos. Me llevó años darme cuenta de que, aunque sabía mucho más que varios de ellos, en realidad sabía poco y nada. Claro que este tipo de “docente” no es patrimonio exclusivo, ni mucho menos, de la UTN (me los he encontrado en varias universidades, con el atenuante de que al menos en algunas de ellas no son mayoría).

Pero la cosa no termina ahí. El Lic. Fernandez Iriart, que parece haberse ganado la antipatía de muchos de sus alumnos (y escuchando su clase se entiende el por qué), es el Presidente del Consejo Profesional de Ciencias Informáticas de la ciudad de Buenos Aires (¡con el “honor” de tener la primera matrícula, número 0001!).

Desde ese Consejo Profesional, que supuestamente “avala la idoneidad de los profesionales de las ciencias informáticas“, este señor se dedica a dictar cursos sobre análisis y diseño orientados a objetos, UML, arquitecturas basadas en “componentes“, etc.

Si este es el tipo de personas que se encarga de representar ante la comunidad a los profesionales de la computación, creo que sumo un punto más en contra de la matriculación obligatoria.

Ver a personas así, arruinando la educación (y quizás la cabeza) de sus alumnos, cobrando un sueldo del estado y, a la vez, representando a los profesionales informáticos, da mucha pena, bronca y, sobre todo, mucha vergüenza…

En muchos casos, no ayudan ni el pésimo nivel de muchas materias universitarias (algunos analistas son formados sin siquiera una introducción a las redes), ni el afán de ocultar la realidad de muchos libros de texto. No me ocuparé del primer caso (al menos por ahora), pero sí quiero hacer hincapié en el segundo.

Muchos textos nos presentan algunas definiciones, en términos demasiado amplios y poco técnicos, para luego guiarnos por distintas configuraciones (típicamente usando ejemplos sobre la plataforma Windows, plagados de capturas de pantallas y cuadros de diálogo). Parecen querer esquivar, a toda costa, los detalles “duros” detrás de todo esto: el conjunto de protocolos TCP/IP. Apenas se detienen en lo indispensable: direccionamiento IP y algo (lo menos posible) sobre enrutamiento de paquetes (o ruteo).

Así es que luego aparecen informáticos que creen que un “puerto” abierto es algo peligroso y poco recomendable, que son incapaces de detectar la causa del menor problema en la red (“se cayó la red“, es todo lo que pueden decir) y gente que habla de “puertas de enlace” y “conectividad limitada o nula” sin tener la menor sospecha de qué significan estas cosas.

Es notable el caso de la bibliografía producida por empresas como Microsoft y Cisco que, con la promesa de introducir al lector al campo de las redes informáticas, lo único que hacen es tratar de “capturarlo” en el mundo de sus productos. Esto se logra, por ejemplo, redefiniendo todas las palabras que les sea posible a su terminología propia, impidiendo al desafortunado lector el poder relacionar los conocimientos adquiridos con otros textos. De esta forma se forman “especialistas” que desconocen los fundamentos y las cuestiones más generales.

Más allá del por qué de este enfoque poco útil (aunque tan usual), lo importante es destacar que el protocolo TCP/IP es extremadamente simple.

TCP/IP fue diseñado a principios de la década de los ’70 con el objetivo de interconectar redes de gran tamaño. Si nos detenemos a pensar en las capacidades de las computadoras de la época, sumando el hecho de que no podía desperdiciarse equipamiento en las funciones de la red, resulta claro que el protocolo a diseñar debía ser simple y no requerir de gran poder de cómputo para su implementación.

La simpleza de TCP/IP ha sido la clave del éxito de Internet y es la razón por la cual ésta está dejando obsoleta a otras redes complejas como el sistema de telefonía. (Un excelente artículo, “The rise of the stupid network“, analiza esto de forma muy clara.)

Desde un punto de vista “no técnico” la simpleza de Internet está claramente explicada en el artículo “World of Ends” (traducido al castellano como “Mundo de Extremos“).

Para aquellos con una base de conocimientos técnicos, he aquí una serie de sugerencias:

• En Wikipedia hay una página dedicada a los protocolos de Internet con abundante información sobre cada uno de ellos y con enlaces muy recomendables.
• El mejor libro que he leído sobre TCP/IP es “TCP/IP Illustrated Volume 1” de W. Richard Stevens.
• Existen herramientas muy útiles, como WireShark (antes llamado Ethereal), que permiten capturar tráfico de la red y analizarlo. Así es posible “ver” cómo funcionan los protocolos. Un experimento muy simple, por ejemplo, es capturar el tráfico mientras uno abre una página web en su navegador.
• Ejercitar el pensamiento crítico. Buscar, indagar y experimentar acerca del funcionamiento de las redes.
• Para profundizar tanto como se desee, no es necesario comprar ningún libro. Toda la documentación de los protocolos de Internet y su evolución está disponible a través de los “Request For Comments“, o RFC (gran cantidad de ellos traducidos al castellano).

Es penoso ver a programadores que no saben en dónde ni cómo se ejecutan sus aplicaciones. Por más que posean una herramienta de desarrollo que, con hacer un clic, les genere un sistema cliente/servidor muy complejo; sin comprender lo que hay “detrás” jamás serán capaces de descubrir el origen de ciertos errores (“en mi PC corria bien, pero cuando lo subo al servidor no anda“).

También es triste ver a informáticos recomendando la compra de dispositivos de red (switches, routers, etc.) para solucionar problemas que podrían resolverse con un direccionamiento IP apropiado.

Lo más lamentable de esto es que la solución es muy simple, y está al alcance de cualquiera. Realmente… ¿quién no quiere comprender cómo funciona Internet?

Después de haber recibido algunos buenos comentarios sobre este asunto, y para seguir con la polémica, aquí va otro artículo en el mismo sentido.

Este documento también está disponible en formato PDF y en PostScript.

Escrito enojado

Edsger W. Dijkstra (EWD696)

“Pero los gráficos no son la cuestión central de la geometría, y no está permitido razonar a partir de ellos. Es cierto que mucha gente, incluyendo a los matemáticos, se apoyan en ellos como una muleta y se encuentran incapacitados de hablar cuando se les quita dicha muleta.”

Morris Kline en el capítulo “Un Discurso sobre el Método” de “Matemáticas en la Cultura Occidental”, Oxford University Press, Inc., 1953

La observación de Morris Kline es correcta. Omite la explicación de lo que ha observado, aunque dicha explicación es simple: la mayoría de la gente, incluyendo a los matemáticos, son pensadores aficionados en el sentido en que no se les ha enseñado cómo pensar eficazmente. No se les ha dicho que tiren la muleta y, por lo tanto, nunca han aprendido a correr.

El hábito de usar ayudas gráficas, como cualquier hábito, es muy dificil de erradicar. Sin embargo, si aceptamos alguna responsabilidad por la eficacia de nuestros hábitos de razonamiento, deberíamos tratar de abandonarlo tan rápido como sea posible; dado que es un mal hábito, desconcertante y engañoso hasta el punto de ser paralizante. Una de las contras de los gráficos es que son casi siempre sobre-específicos. Uno no puede graficar “un triángulo arbitrario”: ni bien uno lo ha hecho, éste tiene un ángulo obtuso o no, mientras que para “el triángulo arbitrario” la propiedad de tener un ángulo obtuso está explicitamente indefinida. En el caso de los grafos es aún peor, porque el mismo grafo específico tiene tantas representaciones gráficas, que el sólo establecer que dos gráficos distintos representan el mismo grafo requiere de un tosco proceso de verificación. En el caso de los árboles y listas una circunstancia simpáticamente desconcertante es que la mayoría de las convenciones gráficas no incluyen una representación visible para el árbol o la lista vacía. Son engañosos porque la misma cosa tiene varias representaciones visualmente muy diferentes; su uso es desconcertante porque es insólito cuando un autor establece que dos gráficos distintos tienen que ser considerados semánticamente equivalentes, y son paralizantes porque sólo pueden representar miembros individuales de un conjunto. Y cuando trabajamos con un conjunto, uno de los peores errores que podemos cometer al razonar es tratar de lidiar con el conjunto como un todo, trabajando con los miembros individuales de un subconjunto del cual sólo podemos rogar que sea representativo: uno solamente puede trabajar con un conjunto -y por lo tanto con todos sus miembros- mediante su definición. Una vez que haya comprendido esto, no lo sorprenderá escuchar que uno de los mayores componentes del aprendizaje del razonamiento efectivo es el “desaprendizaje” del uso de gráficos. (Y el “desaprendizaje” es muy dificultoso, dado que su pasado seguirá siendo su pasado: lo único que puede hacer es superponer un nuevo pasado sobre el anterior, y rogar que el más reciente sea dominante.)

Y todo esto fue desencadenado por el “Diseño de Programas Abstractos en un Entorno Interactivo”, la tesis doctoral de Lars Kahn, de Estocolmo, quién gentilmente me envió una copia; la cual revisé la otra noche. Entre otros comentarios que no citaré, (el ahora Doctor) Lars Kahn establece que “[es] mi propia experiencia y la de otros, que es más natural en el proceso de diseño el uso de una notación gráfica en vez de texto. Por varios motivos, no he tenido la oportunidad de implementar una herramienta interactiva con notación gráfica, pero creo que un sistema visual gráfico fácilmente operable para el diseño de programas sería la mejor asistencia mental”. Aquí “más natural” debe leerse como “más natural para el ignorante”: su “sistema visual gráfico fácilmente operable” significaría el perjuicio más grave al diseño de programas que puedo imaginar. La disertación -de esto me di cuenta más tarde, habiendo salteado las letras pequeñas- fue para el grado de Doctor en ciencias sociales, lo cual trata ciertamente sobre el ignorante. A veces temo que además sean para el ignorante, y por el ignorante.

20 de diciembre de 1978

Plataanstraat 5
5671 AL Nuenen
Holanda
prof.dr.Edsger W.Dijkstra
Investigador Asociado de Burroughs

Este documento también está disponible en formato PDF y en PostScript.

Por qué Juancito no puede entender

Hace unos años escuché una disertación sobre la estructura de las pruebas. Sin vacilar, el disertante se volvió muy gráfico y las pruebas se convirtieron en grafos dirigidos con flechas de los antecedentes a los consecuentes. [Mathematics Inc. hubiera comercializado el producto por aquellos días como Entendimiento Asistido por Computadoras Mediante Animación de Argumentos.] Luego de quince minutos el orador dirigió nuestra atención hacia el hecho de que algunas pruebas eran planas, en tanto que otras no lo eran. Luego, mostró cómo transformaciones simples de las pruebas en otras lógicamente equivalentes podían cambiar su “planaridad“; pero en vez de concluir que, por lo tanto, la planaridad de las pruebas no era probablemente un concepto relevante, se embarcó en un estudio de los argumentos intrínsecamente no-planos, etc.

Fue la disertación más absurda que he oído en años. (Por eso aún la recuerdo.) El pobre tipo era una grave víctima de su educación: confundía el grafo dirigido, como un subconjunto de los pares ordenados, con la representación gráfica de flechas entre puntos. [Si hubiera sido instruido sobre las matrices de incidencia, podría haber disertado sobre los eigenvalores de las pruebas.]

Esto es lo que nos sucede una y otra vez. Cuando se nos introduce un nuevo concepto se nos dan varios ejemplos de un contexto esperanzadoramente familiar, o se nos dan uno o dos modelos en los cuales el nuevo formalismo, sus objetos y sus operaciones pueden ser “entendidos”. Y realmente se nos alienta a realizar esas interpretaciones para convencernos a nosotros mismos de que el nuevo formalismo “tiene sentido”. Fallan, sin embargo, en advertirnos de que tales interpretaciones tienden a ser engañosas porque los modelos son sobreespecíficos; en que tales hábitos de entendimiento son totalmente desconcertantes cuando las visualizaciones que los acompañan desorientan a la imaginación y que la carga mental de moverse hacia y desde la fórmula y su interpretación, debe mejor evitarse. De hecho, uno solo puede esperar que, al aumentar la familiaridad con el formalismo, el modelo tranquilamente se esfume de nuestra conciencia.

Esto ya había comenzado cuando se nos enseñaron los números naturales. No aprendimos que 2 + 3 = 5, primero aprendimos -¡gráficamente!- que dos manzanas y tres manzanas son cinco manzanas, y luego para peras, para plumas, para gatos, árboles y elefantes. El modelo de la manzana es
penosamente inadecuado, dado que, para dar lugar al producto, la manzana tiene que ser elevada al cuadrado, y por consiguiente -y afortunadamente- se desvanece; pero no antes de haber creado un obstáculo para los enteros negativos. Se puede argumentar que seguimos pagando el precio, esto es, si consideramos la invisibilidad del cero en el modelo de la manzana como la responsable de todas las complicaciones matemáticas causadas por considerar el 1 como el menor número natural. (En comparación con los griegos hemos sido afortunados: con sus segmentos de línea pudieron multiplicar muy poco, desafortunadamente lo suficiente como para no tirar su modelo. Y eventualmente la matemática griega murió por su pobreza conceptual y complejidad gráfica: una lección para todos nosotros.)

Dudo seriamente que el desvío a través del modelo de la manzana sea esencial para enseñar los enteros a niños pequeños, pero aún en tal caso, no veo la razón por la cual un proceso de aprendizaje que pueda ser apropiado para niños pequeños deba serlo también para la mente adulta. Y esta parece ser la asunción sobre la cual operan la mayoría de los escritores y muchos de los lectores adultos. Mi -triste- conclusión es que los patrones más difundidos de entendimiento no han sido seleccionados concienzudamente por su efectividad y pueden ser mejor descriptos como hábitos adictivos, muchos
de los cuales merecen una advertencia de cirugía general.

Mi observación más común es ver gente que se siente más confortable con el específico innecesario. Cuando son confrontados a un conjunto parcialmente ordenado, piensan mentalmente “por ejemplo, los enteros”. Mientras yo fui entrenado para evitar los ejemplos al leer un texto -dado que pueden ser superfluos y, en cualquier caso, distraen-, veo gente que se siente más incómoda fuando se enfrentan a un texto sin ejemplos. Gente que tiene dificultad en entender una construcción que contiene un parámetro natural k me ha asegurado que dicha parametrización presenta un obstáculo adicional que podrían remover sustituyendo inicialmente k por un valor pequeño, digamos 3. No
tengo motivos para dudar de su palabra; el extraño fenómeno probablemente estaba conectado al hecho de que k no ocurría en un contexto muy aritmético, sino como la longitud de cadenas o la cantidad de arcos que confluyen en un vértice (contextos en los cuales están habituados a manejarse en términos de gráficos). De la misma forma una permutación “arbitraria” creó problemas similares: hubieran preferido una específica, posiblemente seguida de un comentario al final que indicara que la elección de la permutación no importaba realmente. Es muy extraño, hasta desconcertante, ver a gente perturbada cuando se dejan abiertas preguntas cuyas respuestas son irrelevantes.

Una observación final me sugiere que, de hecho, es culpa del sistema educativo. Recuerdo muy bien la introducción de la idea de que es tarea del profesor el motivar a sus estudiantes. (La recuerdo muy bien porque pensé que la idea era muy absurda.) Ahora encuentro jóvenes científicos educados bajo el régimen motivador, que tienen una desventaja notable: su habilidad para absorber información no motivada está limitada a unas 10 líneas. El objeto y su propósito son cosas diferentes, pero ellos no aprendieron a distinguirlo y ahora son incapaces de separar estos asuntos. Es un ejemplo atemorizador de cómo la educación puede infundir necesidades psicológicas que se vuelven una importante desventaja.

Austin, 5 de noviembre de 1986

prof.dr.Edsger W.Dijkstra
Departamento de Ciencias de la Computación
Universidad de Texas
Austin, TX 78712-1188
Estados Unidos de América

Los tiempos han cambiando, aunque no tanto: hoy en día hay muchos “IBMs”, y el negocio de la educación se ha extendido (y ridiculizado) todavía mucho más.

¡Qué humor ácido tenía Don Edsger! ;)

Puede leer también la versión original digitalizada en PDF, la transcripción en HTML y PDF (todas en inglés), o esta traducción en PDF.

Estimado Sr. X de la Empresa Y.

Usted es el n-ésimo (n >> 0) representante de una organización comercial, diciendo proveer educación y entrenamiento para el profesional en computación,
que solicita mi cooperación. Y por n-ésima vez mi respuesta es “No”.

Una muestra de su catálogo de servicios indica que probablemente más de la mitad de sus cursos apuntan a enseñar como vivir con -o inclusive: ¡cómo migrar a!- productos de IBM. Pueden representar “entrenamiento”, pero no puedo llamarlos “educación”. El problema de cómo hacer cosas útiles
con productos de IBM me parece, de hecho, severo -esta, al menos, es la única conclusión a la que puedo arribar dada la gran cantidad de cursos que su
rentable empresa dedica a sus numerosos aspectos-, pero el problema parece más evadido que resuelto. (¿Qué le parecerían cursos sobre como migrar de productos de IBM?) Los errores industriales no son sacrosantos sólo porque se cometan en gran escala. Desde un punto de vista educativo, su organización
está está rayando -o ha traspasado- el límite de la fraudulencia, y su invitación a cooperar con vuestro emprendimiento puede, por lo tanto, ser interpretada como un insulto.

Quizás a modo de tentación, usted lista los nombres de las “celebridades” de este circo educativo, a cuyas filas podría unirme de cooperar con su empresa. (¡Podría tener inclusive mi foto reproducida en su próxima carpeta! ¡Que divertido!) Conozco a muchos de ellos. Cuando se me envían sus trabajos, los dejo tirados por ahí en mi oficina en la Universidad, para el asombro de mis visitantes: usualmente quedan estupefactos al ver que cosas tan superficiales no solamente son impresas, sino inclusive hasta vendidas. Me gustaría que entendiera que existe una escala de valores, de acuerdo a la cual su invitación a unirme a esa pandilla es no menos que un insulto.

Sin denegar ninguna responsabilidad por esta carta, debo hacer la aclaración de que es todo culpa de mi esposa. Cuando le pregunté si a ella le gustaría estar casada con un millonario, inmediatamente su respuesta fue “¡Por favor, no!”. Cuando me preguntó a qué venía la pregunta, le expliqué acerca del “circo educativo” -¿recuerda el veredicto de Barnum?. Gentilmente me dijo: “Por favor, trata de no ser demasiado rudo cuando respondas a ese tipo”. He hecho lo mejor que he podido; su único error es que ella no se casó con un gigoló.

Nunca suyo,

prof. dr. Edsger W. Dijkstra

Bueno, realmente le escribí:

Estimado Sr. X,

gracias por su carta de … . El material adjunto me indicó que no soy un orador apropiado para el público propuesto, y por lo tanto he concluido que debo
declinar sus invitaciones.

Sinceramente,

prof. dr. Edsger W. Dijkstra
Investigador Asociado de Burroughs
Plataanstraat 5
5671 AL NUENEN
Holanda

El “profe” Aguirre es, además de un gran conocedor del sistema universitario y de su historia, un incansable luchador por la educación pública y de alto nivel en la Argentina.

Vale la pena revisar la historia, como se ha dicho muchas veces, para no volver a repetirla.

A cuarenta años de un gran retroceso de la Universidad Argentina: la
Noche de los Bastones Largos

Por Jorge Aguirre

Introducción

En 1966 el
sistema universitario argentino vivía un acelerado proceso de desarrollo,
investigadores argentinos se formaban en el exterior y luego regresaban
a sus grupos de investigación, dos universidades habían desarrollado
prototipos de computadoras, la cantidad de publicaciones argentinas
en medios internacionales crecía rápidamente, se habían inaugurado
los primeros edificios la Ciudad Universitaria de la UBA y la universidad
realizaba importantes transferencias a variados sectores productivos
y de gestión. Sin embargo la noche del 29 de Julio de 1966, luego llamada
Noche de los Bastones Largos, la dictadura de Onganía intervino
a todas las universidades nacionales y, sin comunicación previa de
la intervención a las autoridades, su policía desalojó a bastonazos
la cede de la Facultad de Ciencias Exactas de la Universidad de Buenos
de Aires. Fueron golpeados autoridades, profesores (incluso un visitante
estadounidense) y alumnos. La indignación provocó una renuncia masiva
de destacados docentes e investigadores y ese floreciente período de
la Universidad Argentina quedó trunco. Aquí se resumen los antecedentes,
las causas y las consecuencias de este aciago suceso, que aún se proyectan
sobre la situación académica actual.

Antecedentes

Al comenzar
el siglo XX el sistema universitario argentino estaba conformado por
la Universidad de Córdoba, una de las más viejas de la colonia y la
Universidad de Buenos Aires. Por esa época, se incorpora la Universidad
de La Plata, que tuvo un importante desarrollo en Ciencias Exactas a
partir de la incorporación de varios destacados científicos alemanes.
Las universidades habían pasado de depender de la Iglesia a depender
del gobierno, que decidía las designaciones de profesores y las cuestiones
académicas fundamentales. Su organización respondía a la ideología
imperante que las veía destinadas a formar la reducida elite dominante
de un país agro exportador.

En 1918, durante
el gobierno de Hipólito Yrigoyen, en la ciudad de Córdoba nació un
importante movimiento estudiantil, que en contraposición a esa ideología,
veía a la Universidad como promotora de progreso y cambio social y
propiciaba importantes modificaciones en la estructura universitaria.
Este movimiento adquirió el nombre de “Reforma Universitaria�?.
Los cambios deseados se basaban en los siguientes principios básicos:
a) la autonomía de las universidades del poder político; b) El gobierno
de las mismas por órganos integrados por representantes de tres claustros:
el de docentes, el de graduados y el de estudiantes; c) La provisión
periódica de los cargos docentes mediante concursos públicos; d) La
libertad de cátedra, que daba total libertad de pensamiento y difusión
a los que ganaran la titularidad de una cátedra, permitiendo la coexistencia
de cátedras paralelas con distintas orientaciones ideológicas o académicas;
e) La asignación por parte del estado de presupuestos que permitieran
el adecuado funcionamiento universitario. Luego de una larga huelga
y gran movilización que se extendió a otras universidades. los estudiantes
lograron la promulgación la “ley de Reforma Universitaria�? que
consagra los principios enunciados.

La Reforma
Universitaria -que en cierta forma anticipó el mayo francés del 68-
dio a las universidades argentinas una estructura sumamente moderna
que permitió su desarrollo e integró a todos los sectores universitarios
en la responsabilidad de su conducción.

Las guerras
que devastaron Europa del 36 al 45, Habían enriquecido las universidades
argentinas con la incorporación de importantes científicos europeos.
La radicación previa de Rey Pastor en la Argentina, primero como profesor
de la Universidad de Rosario y luego de la UBA, había dado origen
a la Escuela Matemática Argentina a la que se integraron inmigrantes
ilustres como Beppo Levi -en la Universidad de Rosario- y jóvenes brillantes
como Luís Santaló, Manuel Balanzat y Mischa Cotlar en Buenos Aires.

Hacia 1957,
el gobierno militar del Gral P. E. Aramburu, que había derrocado en
1955 al gobierno constitucional justicialista
del Gral. Juan Domingo, antes de iniciar el proceso electoral con el
que se elegiría un gobierno civil, con la proscripción del justicialismo,
las universidades, que estaban intervenidas, fueron normalizaron eligiendo
sus autoridades según la ley de la Reforma. Las autoridades universitarias
electas incluían a brillantes intelectuales, que iban a impulsar una
progresista e importante transformación.

Al gobierno
de Aramburu siguió el del Dr. Arturo Frondizi, que ganó las elecciones
de 1958. Los votos del proscripto Justicialismo decidieron el triunfo
de Frondizi. El nuevo gobierno civil apoyó el desarrollo de las universidades
nacionales, que continuaron el camino iniciado en el 57, aunque su gestión
se vio progresivamente limitada por la falta de apoyo propio y por el
constante cuestionar de los militares, mientras crecía clandestinamente
en tamaño y organización el movimiento justicialista.

Dentro de la
transformación universitaria iniciada en el 57 se destacaron importantes
proyectos de desarrollo de las Ciencias Exactas y la Ingeniería. Resulta
emblemático el de la Facultad de Ciencias Exactas y Naturales
de la UBA cuyo Decano era el Dr. Rolando García y cuyo Vicedecano era
el Dr. Manuel Sadosky. La Facultad creció rápidamente: se ejecutó
un importante proyecto de formación de recursos humanos, se consiguió
equipamiento e infraestructura y se incrementó notablemente la planta
de docentes-investigadores (planta que se calificaba con el retorno
de los que partían a realizar estudios de posgrado en el exterior)
y se propició la dedicación exclusiva. En este contexto de ebullición
académica también iba a ingresar la primera computadora en la Academia
rioplatense, la legendaria Clementina.

El Dr. Sadosky
en 1958 inició los trabajos de implantación de la Computación en
la Facultad de Ciencias Exactas y Naturales de la UBA, e impulsó la
adquisición una computadora. Se seleccionó a una Ferranti que
llegó al país en 1960 y fue instalada en el flamante Pabellón I de
la Ciudad Universitaria en construcción. La Computadora recibió el
nombre de Clementina. Sus dimensiones sorprenden hoy: ocupaba toda una
sala, estrictamente acondicionada; pero su memoria principal tenía
sólo 1 K palabras de 48 bits. Como memoria secundaria tenía tambores
magnéticos y la entrada/salida se realizaba mediante cinta de papel
perforada, impresora, consola y un parlante con el que deslumbraba tocando
algunas oberturas. Contaba con un compilador de un lenguaje orientado
al cálculo, Autocode, con el que se iniciaron las primeras camadas
de programadores argentinos. En 1962 Sadosky fundó el Instituto de
Cálculo, que dotado de la nueva herramienta, se ubicó en la primera
línea del acelerado desarrollo de la Facultad, mandando a varios de
sus jóvenes integrantes a realizar estudios al exterior y alcanzando
masa crítica y reconocimiento rápidamente. Clementina permitió iniciar
investigaciones de desarrollo de software de base, de desarrollo de
periféricos e interfaces, de matemática aplicada y permitió realizar
transferencias en distintas áreas.

En la Facultad
de Ingeniería de la UBA también se constituyeron grupos de investigación
y desarrollo en Computación y el Ing. Humberto Ciancaglini fundó un
grupo de electrónica digital que llegó a diseñar y construir un prototipo
de computadora, que fue llamada CEFIBA (1962). En la Universidad Nacional
del Sur también se iniciaron trabajos en Computación digital
y el grupo del Ing. Jorge Santos llegó a construir una computadora
denominada CENUS (1962) a la que sólo le faltó (por falta de presupuesto
para construirla) la memoria suficiente para que pudiera funcionar.

El proceso
vertiginoso de avance de la estructura científica de los años de 1958
a 1966 fue acompañado por una gran politización estudiantil, mientras
que el poder político de la cúpula militar crecía y cuestionaba constantemente
las acciones del gobierno nacional, a través de lo que en la época
se conoció como “planteos militares�?. Finalmente, en 1962, el Dr.
Arturo Frondizi fue conminado a renunciar y ante su negativa apresado
y mantenido prisionero en una isla. Se implementó una parodia de gobierno civil,
bajo control de
los militares y finalmente, luego de una cruenta confrontación
de dos bandos militares se llamó en 1963 a elecciones nacionales, de
cuyo proceso nuevamente se excluyó al movimiento justicialista.

En las elecciones
de 1963 resultó electo presidente el Dr. Arturo Illia. Durante la presidencia
de Illia, continuaron los planteos militares, también las presiones
del justicialismo y de otros movimientos populares antiimperialistas.
Particularmente los estudiantes lucharon por un mejor presupuesto universitario
y también tuvieron importante participación en la resistencia al envío
de tropas argentinas para participar en la invasión de Estados Unidos
a Santo Domingo en abril del 65. Finalmente los militares depusieron
a Ilia y asumió la presidencia el comandante del ejército, Juan Carlos
Onganía. Los estudiantes fueron el sector que más se opuso a la nueva
dictadura militar. En este contexto, sin el apoyo de otras fuerzas populares
y en la mira de la dictadura, los días de aquella Universidad estaban
contados.

La Noche de los Bastones Largos

El 29 de julio
de 1966, Onganía firmó el decreto de intervención a las Universidades
Nacionales. Esa Noche de los Bastones largos, así llamada por
los largos bastones que utilizó la policía, sin que las autoridades
universitarias fueran notificadas de la intervención, fuerzas de asalto
policiales irrumpieron a bastonazos en la vieja sede de la Facultad
de Ciencias Exactas de la UBA -hoy Manzana de las Luces- en la que deliberaban
autoridades, profesores y estudiantes. Nadie escapó a los bastonazos
y muchos fueron detenidos, incluso un profesor visitante estadounidense.

Consecuencias

Indignados
y convencidos de la imposibilidad de continuar el proyecto académico
numerosos profesores renunciaron de inmediato. Así, se inicio el éxodo
de nuestros más destacados investigadores en Ciencias Exactas. El proyecto
había sido truncado, un sablazo había cortado el hilo de su historia.
Después de una prolongada clausura la Universidad reabrió sus puertas,
mientras renacían las protestas estudiantiles, su represión y las
detenciones. Era otra Universidad. La policía ocupaba puertas y pasillos.
Estaban prohibidas las reuniones y en la Facultad de Ciencias Exactas
de la UBA en algunas disciplinas, paradigmáticamente en Computación,
casi no quedaban profesores formados. Algún tiempo después, Clementina
también dejaría de funcionar, exhausta ante la falta de mantenimiento,
el centro en que naciera la computación argentina pasaría muchos años
sin ninguna computadora.

La Noche
de los Bastones Largos no fue el único suceso que truncara
o intentara truncar importantes proyectos científico tecnológicos
en muestro país, también lo fueron: Como un anticipo de ella, pocos
años antes, en 1962, el instituto Malbrán, que bajo la dirección
Dr. Ignacio Pirosky se había convertido en un centro de excelencia
en Microbiología, al que se había integrado el Dr. Cesar Milstein
luego de terminar su pos doctorado en Inglaterra, fue intervenido y
dejado cesante su director; como consecuencia Milstein, carente de proyecto
local, regresó a Inglaterra donde iba a obtener luego el premio Nobel.
También lo fue la cesantía del Dr. Bernardo Houssay (fundador
de la Escuela Argentina de Fisiología también galardonado con el Premio
Nobel) antes del gobierno de Perón y luego su jubilación obligada
durante el mencionado gobierno, que previamente lo restituyera en sus
cargos y funciones. Más tarde durante el neoliberalismo de los 90 el
deterioro de la Comisión Nacional de Energía Atómica que fue dividida
(separándose producción de investigación) y en la que se implementó
un plan de retiro voluntario que alentaba a retirarse a sus investigadores.
Otros desgraciados ejemplos, de este período, son la desaparición
del Programa Argentino Brasileño de Informática y de la Escuela Superior
Latinoamericana de Informática.

Al rememorar
el 40 aniversario de la triste “Noche de los Bastones Largos“,
hagamos votos porque en nuestra Argentina, como lo es en Brasil y los
países de mayor desarrollo, el impulso de la Ciencia y la Tecnología al servicio del pueblo,
constituya una Política de Estado, que nos libre de volver a ver, cómo
importantes logros son sacrificados en aras de mezquinos intereses o
ineptitudes.

En su artículo “Sobre la crueldad de verdaderamente enseñar Ciencias de la Computación” nos muestra claramente la naturaleza de la programación, explicando el por qué de los males que la aquejan.

Si usted es informático y alguna vez se preguntó por qué el desarrollo de software difiere tanto de otras áreas del conocimiento y de la técnica (como la arquitectura, las distintas ingenierías, etc.), o por qué ya entrados en el siglo XXI todavía no podemos garantizar ciertas propiedades de los sistemas informáticos, sin duda debería leer este artículo.

Para facilitar su lectura, dado que se trata de un documento extenso, lo he publicado en varios formatos:

• Versión HTML (online)
• Versión PDF
• Versión PostScript

Una versión de este mismo artículo fue publicada en la revista Communications of the ACM, dando lugar a un ardoroso debate, del que participaron varias figuras del mundo de las Ciencias de la Computación. Dijkstra es bastante duro en la exposición de algunos conceptos, lo que aparentemente “ofendió” a varias personas, pero no puede negarse la solidez de sus fundamentos.

Es largo, y una lectura concienzuda lo torna más largo aún, pero realmente creo que vale la pena.

• Software libre en la enseñanza de la informática
• Educando para la era de la información

Aprecio todo comentario, crítica o sugerencia sobre estos artículos, en forma de comentarios de esta entrada.

Hace ya unos años, cuando era ayudante en una cátedra de programación en donde usabamos intensivamente GNU/Linux, armé un pequeño tutorial (paso a paso) “retocando” el capítulo 3 del libro “Linux: Installation and Getting Started” de Matt Welsh. Recientemente, lo encontré por ahí y le dí una buena “lavada de cara”.

He publicado dicho tutorial (en varios formatos) en mi sitio web. ¡Espero que sea de provecho!