Cómo hacerle preguntas a una computadora

Un video de una (¿nueva?) organización llamada Code.org ha estado circulando bastante en los últimos días, con diferentes personalidades del mundo de la tecnología hablando sobre la importancia de aprender a programar y alertando sobre la brecha en los próximos años en la economía estadounidense entre 1 millón de puestos de trabajo vinculados a la programación y solamente 400 mil personas entrenadas para llenarlos.

Hay múltiples razones por las que el código y la programación son importantes, pero aprender sobre código y programación es también muchas cosas y es relevante para todo tipo de disciplinas, no sólo para aquellos en el ámbito de las ciencias y la ingeniería. Programación no es sólo una habilidad estrictamente técnica, sino que va de la mano con otros dos ámbitos: por un lado la idea de pensamiento computacional, o de que hay ciertos problemas para los cuales una aproximación desde la computación es mucho más efectiva y eficiente, o que incluso solamente pueden resolverse computacionalmente, y entender lo que ese tipo de razonamiento significa: una serie estructurada de instrucciones y operaciones ejecutadas en secuencias, iterativamente, y con alta interdependencia entre sí, etc. Por otro lado, programar también significa reconocer las realidades de código que nos rodean en todo tipo de sistemas, entre sistemas técnicos y sistemas sociales, y la manera en la que en su código pueden descubrirse múltiples capas que reclaman análisis. El software que maneja las historias clínicas de pacientes en un hospital, por ejemplo, tiene que haber respondido una serie de preguntas y haber hecho una serie de supuestos que afectan directa y palpablemente la vida de cientos de personas. Esas preguntas, esas decisiones y esos supuestos se traducen en código, que a su vez es susceptible de ser criticado – por ejemplo, la manera como un sistema de este tipo puede excluir o no reconocer a un subconjunto de pacientes. Pero para que ese código pueda ser criticado, los analistas de diferentes áreas temáticas tienen que primero reconocer la dimensión del código como susceptible de análisis, y segundo, saber leer ese mismo código que pretenden analizar y criticar.

A pesar de esta importancia, que es transversal a todo tipo de dominios temáticos, nuestro modelo educativo y disciplinario ha optado más bien por aislar el pensamiento computacional a un sólo dominio restringido (por ejemplo, el ámbito de los ingenieros informáticos) sino además de convertirlo de un modelo de aproximación a los problemas a una herramienta operativa y con dominio restringido. En The Children’s Machine, Seymour Papert habla de la manera como la cultura de la escuela subyugó, arrinconó y finalmente neutralizó la “amenaza” que representaba la computadora:

When there were few computers in the school, the administration was content to leave them in the classrooms of teachers who showed greatest enthusiasm, and these were generally teachers who were excited about the computer as an instrument of change. But as the numbers grew and computers became something of a status symbol, the administration moved in. From an administrator’s point of view, it made more sense to put the computer together in one room – misleadingly named “computer lab” – under the control of a specialized computer teacher. Now all the children could come together and study computers for an hour a week. By an inexorable logic the next step was to introduce curriculum for the computer. Thus, little by little, the subversive features of the computer were eroded away: Instead of cutting across and so challenging the very idea of subject boundaries, the computer now defined a new subject; instead of changing the emphasis from impersonal curriculum to excited live exploration by students, the computer was now used to reinforce School’s ways. What had started as a subversive instrument of change was neutralized by the system and converted into an instrument of consolidation.

Y ésta es más o menos la manera como aprendimos computación aquellos que la experimentamos a nivel escolar: como un curso más, un lugar en la currícula, pero un lugar cuyas herramientas y modelos no se traducían ni extendían a otras áreas temáticas o a otros cursos. Uno iba al laboratorio de computación a trabajar durante un rato con la computadora, y ése era el fin de la experiencia acotada que eso significaba. Pero nuestra interacción con la computación hoy día se da desde el teléfono que llevamos en el bolsillo, los medios que nos transportan, las máquinas con las que interactuamos y los sistemas complejos que informan las decisiones que a su vez forman el entorno en el que vivimos. La computación no es algo que ocurre afuera o aparte, sino algo que se integra y coexiste con múltiples dimensiones de la vida cotidiana. Dicho de otra manera, como lo puso Marc Andreessen en un buen artículo sobre la expansión del software fuera de sus dominios tradicionales, el software se está comiendo el mundo. Y quizás, por lo mismo, no sea coincidencia que los dos dominios que Andreessen señaló como los siguientes desafíos, allí donde el software aún no había conseguido resultados suficientes, eran los de la educación y la salud.

En un taller sobre computación que estoy llevando con Nick Montfort estamos analizando este tipo de problemas respecto a la computación, el pensamiento computacional y la manera como está bien o mal comprendido, y cómo se puede integrar significativamente a diferentes tipos de proyectos. Hemos discutido, por ejemplo, sobre cómo somos introducidos diversamente el mundo de la computación, cómo aprendemos programación y esos modelos de aprendizaje funcionan o no, empezando por los clásicos programas de “Hola Mundo”. Aprendemos elementos de programación pero como vehículo para pensar en otras cuestiones menos evidentes, como el análisis crítico de código o el estudio de plataformas que incorporan desde dimensiones de hardware hasta convenciones sociales y culturales sobre cómo deben o pueden ser utilizadas. Sobre todo, nos obligamos a familiarizarnos con el código como realidad no esotérica, como una dimensión de significado accesible, analizable y discutible, pero con el entendimiento de que, como con cualquier otro tipo de texto, es necesario a aprender a hablar su lenguaje para poder interpelarlo e interrogarlo.

Una vez que se habla ese lenguaje y se entiende ese modelo, los problemas pueden irse volviendo más complicados e interesantes. Y esto es interesante desde el punto de vista informático, pero también desde el ámbito de las ciencias sociales y las humanidades, donde la computación y el código han tenido lugares tristemente reducidos. No sólo como objeto de estudio, sino también como método de aproximación a los problemas propios de su campo. Las ciencias naturales han empezado a reconocer esto cada vez con mayor intensidad, y así, por ejemplo, físicos o biólogos se ven en la necesidad de aprender a dominar lenguajes de programación y modelos computacionales cuando quieren resolver problemas utilizando conjuntos de datos masivos, con quizás miles o incluso millones de registros. Allí donde la captura de datos masiva es posible pero su análisis pormenorizado humanamente inaccesible, es donde se pueden implementar y utilizar herramientas computacionales con mucho éxito.

Pero en los ámbitos de ciencias sociales y humanidades el acercamiento ha sido más tangencial, aunque esto está cambiando rápidamente. Por ejemplo, mucho de la discusión sobre humanidades digitales se enfoca sobre aspectos externos (y no por ello quiero decir menos importantes) como la manera como los investigadores y académicos comunican su trabajo y sus resultados al público, o cómo conseguir que los humanistas utilicen blogs o Twitter para comunicar sus ideas. Eso está bien, pero son casos en los que la tecnología y la computación en particular son elementos externos a su práctica. Un ejercicio que hicimos en este taller, por ejemplo, exploraba los fundamentos de un uso de la computación como herramienta creativa para la investigación: como introducción al concepto de programación orientada a objetos elaboramos un programa simple capaz de capturar información sobre inscripciones en los edificios a través de un campus universitario, definiendo los parámetros que nos sean interesantes para la captura. El concepto es simple y por sí solo poco interesante, pero una vez que se capturan suficientes datos y se desarrolla una rutina para analizarlos, se puede empezar a revelar información interesante, que sólo sería visible a partir de un conjunto de datos suficientemente grande y un análisis computacional.

Pueden imaginarse fácilmente otras aplicaciones de modelos similares. Un estudio sobre la evolución del concepto de “sociedad civil” podría hacer una lectura de autores centrales para el concepto comparando sus caracterizaciones. Pero teniendo un conjunto de textos grande en formato digital, uno podría simplemente hacer una búsqueda de la frecuencia con la que aparece el término, e identificar otros términos recurrentes con los que aparece, y visualizar la evolución tanto de la frecuencia como de sus términos vinculados a través del tiempo. O podría, por ejemplo, hacer lo mismo con textos de noticias en periódicos. Y aunque esto, no agotaría de ninguna manera el análisis, llevaría inevitablemente a nuevas preguntas: ¿Por qué aparecen picos inesperados en la frecuencia? ¿Por qué aparecen términos inesperados alrededor? Y así.

Otro ejemplo: si quiero conocer los principales referentes a través de la obra de Marx, puedo dedicarme durante semanas a una lectura detallada de sus textos, sus notas al pie, sus bibliografías, en un intento por reconstruir las fuentes que utilizaba. O, puedo digitalizar todo el texto, y de nuevo hacer un análisis de frecuencia buscando nombres y títulos de obras, y cruzando esos datos con una línea de tiempo y con la obra en la cual se encuentran. Con esto podría tener, hipotéticamente, no sólo una perspectiva a las obras a las que refería, sino además cómo este conjunto evolucionaba en el tiempo.

A veces, un modelo computacional es una manera de descubrir nuevas preguntas, y a veces es un modelo para encontrar un cierto tipo de respuesta. No reemplaza a otros métodos, no desplaza las maneras que conocemos de investigar, sino que las complementa, las amplifica. Pero también nos brinda una vía de acceso para poder leer competentemente un conjunto de realidades que hoy son sumamente importantes pero que nos son en gran medida inaccesibles.

Yo mismo he intentado aprender a programar, sin mucho éxito, al menos una decena de veces, pero de cada una de ellas he ido asimilando un mínimo conocimiento funcional. Pero para aquellos interesados en aprender más, o para aquellos interesados en pensar cómo conseguir que niños y jóvenes puedan introducirse en este mundo, hoy día existen una serie de opciones interesantes: existen lenguajes de programación visuales, como Scratch o StarLogo (una versión visual del popular Logo creado por Seymour Papert) que permiten construir algoritmos y secuencias de instrucciones conectando bloques que tienen diferentes significados. Existen plataformas de aprendizaje en línea como CodeAcademy o Skillshare donde pueden encontrarse buenos recursos para aprender sobre lenguajes de programación. Y existen también lenguajes que son más accesibles para el aprendizaje, como puede ser Python, Ruby o CoffeeScript, o por supuesto, uno puede empezar familiarizándose con el código en HTML.

Borrón y cuenta nueva: ¿Debemos reiniciar nuestro social graph?

El viernes Facebook salió al mercado en una oferta pública inicial en el NASDAQ, con una valuación que fluctuó alrededor de los $115 mil millones. Son muchos millones. Hay quienes piensan que una compañía como Facebook no debería valer tanto, y otros dicen que la oferta pública inicial ha sido un fracaso o, por lo menos, una decepción, pues la acción cerró prácticamente al mismo valor al que abrió, desinflando las expectativas de millones de personas que esperaban una farra financiera.

Es interesante volver sobre la historia de cómo llegamos hasta aquí, en años recientes. Cuando empezamos a utilizar las redes sociales online, en realidad no teníamos idea de lo que hacíamos. Primero Friendster, luego Myspace, en algunos casos también Hi5 (¿recuerdan los “testimonials”?). Eventualmente Facebook abrió sus puertas y dejó que todo el mundo entre a jugar a su jardín amurallado, y nos adaptamos como mejor pudimos. La manera como utilizamos Facebook ha ido cambiando con el tiempo, de la misma manera que el producto mismo ha ido evolucionando, ampliándose y brindando nuevas posibilidades.

El conflicto es, quizás, que nunca hemos aprendido a ser muy diligentes respecto a nuestro rastro digital: el conjunto de perfiles, objetos y contenidos que hemos ido creando y publicando en la web a través de los años, y que hemos ido dejando atrás sin ningún tipo de mantenimiento, curaduría o consideración. Incluso dentro del mismo Facebook uno puede hacer este ejercicio de auto-arqueología continuamente: cada cierto tiempo verás el anuncio de que es el cumpleaños de alguien que quizás te importa poco, quizás no entiendes por qué lo saludarías o quizás simplemente no entiendes por qué rayos es tu amigo en Facebook.

Si recuerdan, al principio cuando estábamos construyendo nuestro “social graph”, nuestra red de conexiones en línea, no intentamos ser particularmente prolijos. En un esfuerzo por tener más “amigos” y ampliar nuestras redes, muchas veces aceptamos a cualquier persona, organización, objeto o ente como amigo en Facebook sin pensarlo mucho. Más aún, nunca nos detuvimos demasiado tampoco en limpiar eso posteriormente, eliminando personas o entes a los que quizás no queríamos darle acceso privilegiado a toda nuestra información personal (a medida que fuimos volcando más y más de ella en nuestros muros, perfiles y ahora, biografías).

Ahora, espero, somos un poco más conscientes de esas cosas, pero en muchos casos el daño a nuestro social graph ya está hecho. A medida que más y más aplicaciones se construyen utilizando ese social graph, esos primero “errores” o aprendizajes terminan afectando la información que recibimos y utilizamos: si los resultados de búsqueda en Google, por ejemplo, utilizan mi social graph para darme resultados más interesantes, ¿cómo aporta a esa relevancia la presencia de una persona que estuvo en mi colegio un año y no volví a ver más en la vida? Además, el costo de transacción de hacer limpieza es alto: no solamente consume tiempo, sino que eliminar gente de nuestra lista de amigos es una decisión complicada. ¿Estoy mandando un mensaje a esta persona? ¿Se enterará? ¿Se ofenderá? Todo lo cual hace que sea mejor no hacer nada que hacer algo.

Steven Levy escribía el año pasado que Facebook debería darnos la opción de empezar de nuevo. No perder nuestro contenido, no tener que crear un nuevo perfil, pero reiniciar nuestras lista de amigos para poder volver a empezar con mucha más consciencia de las consecuencias y las implicaciones. Michael Arrington fue un paso más allá al decir que esto podría convertirse en un talón de Aquiles a largo plazo para Facebook, cuando los usuarios empiecen a preferir opciones sociales online mucho más personalizadas y donde los “mundos no colisionen” continuamente.

No creo que pase ni lo uno ni lo otro, pero igual tenemos que empezar a observar y hacer algo respecto a las consecuencias de todo esto. Finalmente, no estamos realmente acostumbrados a cargar con toda nuestra historia social, todo el tiempo: pre-Facebook, era relativamente fácil dejar cosas atrás. Ya no. Ahora quedan marcadas como eventos en nuestra biografía, y cuando empezamos a marcarlas nunca pensamos que quizás, tiempo después, tendríamos que retroceder para hacer un poco de housekeeping.