La retórica del código

La semana pasada, en la segunda parte de la clase de tres horas que, a decir verdad, se pasaron volando, las lecturas recomendadas eran el prólogo y capítulo primero de La era de la información Vol. 1: La sociedad red, de Manuel Castells, “Part Three: Digital Life” de Being Digital por Nicholas Negroponte, y los capítulos del 1 al 6 de Linked. How Everything Is Connected to Everything Else and What It Means, una exquisita obra de divulgación de Albert-László Barabási.

Para esta semana teníamos nuevas e interesantes lecturas que poco a poco van introduciendo lo digital. Muy relevantes me resultaron los manifiestos de las Humanidades Digitales, tanto la primera versión como la 2.0, la entrevista a Daniel Shiffman que FlowingData tituló Por qué todo el mundo debería aprender programación, o el discurso de Umberto Eco al recibir el doctorado honoris causa en la Universidad de Sevilla hace algo menos de un año. Y por si fuera poca lectura, se añadió el artículo de Google al respecto de su nueva herramienta Books Ngram Viewer, titulado Análisis cuantitativo de la Cultura usando millones de libros digitalizados, creo que aquí tampoco es muy decisiva la noción de millón norteamericano o millón castizo, tal cantidad ya asusta de por sí.

Parte I

Comenzaba la clase de hoy con el debate sobre la comunicación broadcast vs. la comunicación on-demand y su utilidad o no para cambiar los modelos de enseñanza tradicional que se llevan a cabo en las asignaturas de cualquier índole. Se llegó de nuevo a la necesidad de establecer una audiencia: las academias virtuales tienen en la pequeña empresa su célula más pequeña mientras que cualquier individuo con suficiente tiempo libre y dedicación puede «formarse» a través de, por ejemplo, los más de 1 150 vídeos que la Universidad de Stanford publica gratuitamente a través de su canal en YouTube. Consumida de esta forma la formación se convierte en una colección de contenidos de más o menos calidad, pero sin la mayor garantía de que realmente se vaya a formar nadie con ello. Se hace necesario un mecanismo de interacción con los consumidores de los contenidos. Casi no importa si son difundidos en un clase de 3, 14 ó 160 personas, a través de la televisión o la radio o si están disponibles libremente para su descarga en una página web. ¿Se toma un curso porque se siente interés en el tema o porque se supone que se debe tomar para conseguir ser en un especialista en X? ¿Quién decide qué es lo apropiado para formar a los demás en tal o cual disciplina? ¿Por qué?

Estableciendo que en la práctica es irrelevante el medio en el que se difunda la información si éste no ofrece cierto grado de interacción –ya sea broadcasting, multicasting, on-deman o loqueseacasting–, necesitamos aun contestar a las preguntas anteriores en base al currículo de los «alumnos» potenciales, entendiéndolo como «el conjunto de estudios y prácticas destinadas a que el alumno desarrolle plenamente sus posibilidades». En el mundo de las Ciencias la justificación del background es evidente, nadie confiaría demasiado en un ingeniero que no ha estudiado matemáticas o físicas. Es más, en última instancia, todas las ciencias aplicadas, ingenierías y carreras técnicas están enfocadas a producir un bien en el mercado, están sometidas a los requisitos y leyes fijas que la sociedad de consumo impone. El buen ingeniero queda definido en términos de eficiencia y eficacia económicas. En cambio eso no sucede en las Humanidades. No hay una entidad que establezca los conocimientos necesarios para el perfecto humanista, en parte, porque sería casi antitético. El criterio, la capacidad de razonamiento, la comprensión o el análisis son básicos para los humanistas, pero no es fácil escoger, por ejemplo, las lecturas adecuadas para que afloren. Proponía Negroponte que no se diseccionen más ranas, la «hard fun» de Seymourt Paper, dale las herramientas al alumno y él buscará los resultados –aunque el proceso sería un poco menos frustrante si se supervisa un equilibrio entre el ensayo y error y el do it yourself. Se me antoja que es lo que las Humanidades han estado haciendo desde siempre, con el inconveniente añadido de tener 2 000 años de historia y muchas, muchísimas «herramientas» que conocer de antemano. Incluso demasiadas, tantas que a veces termina por convertir al humanista en un coleccionista de sus propios saberes, un curador hermético. ¿Preocupados por las subsistencia? No me extraña, ante el hermetismo cualquier nuevo camino se presenta como una amenaza. La adaptación es la clave, no hay por qué perder de vista el humanismo clásico, pero sí emborronar un poco las fronteras en todas las direcciones. Un cambio de paradigma. Enseñar a manejar herramientas que tarde o temprano arrojarán soluciones a problemas de naturaleza humanista no es una crisis, ni una amenaza, ni, mucho menos, un problema de subsistencia.

Parte II

La segunda parta de la clase, coincidente con el momento en el que el Prof. Suárez estima que estamos divergiendo más de la cuenta y el tiempo de aula se agota, comienza con unas propuestas sobre las que pensar. Entre ellas el Digital Humanities Manifesto, que habla de muchos conceptos viejos en el mundo del Software Libre pero que, como observaba un alumno, no son para nada la norma en el mundo de la Informática. No sé cuál es la formación de las personas que han escrito el manifiesto, pero sí que el documento defiende valores no muy distintos a la filosofía stallmaniana. Y va más allá llegando a aseverar incluso mi postura: «las Humanidades Digitales tratan sobre convergencia: no sólo entre las disciplinas y los medios, sino también entre las artes, las ciencias y las tecnologías». Es decir, entre las visualizaciones de los datos, las teorías aplicadas y las herramientas de análisis.

A colación del código fuente surge una pregunta interesante: ¿es la programación (un) arte? Reformulando, ¿se puede disfrutar estéticamente con el código? Mi respuesta es clara: sí. Pero no exactamente en el mismo sentido en que se disfrutan de los recursos de la escritura. Un libro surge, intuyo, por la necesidad de contar algo. Tiene un fin. El Humanismo se ha encargado de difuminar el objetivo de cada libro, de cada escritura, dándole diversas interpretaciones y dotando al lenguaje de una retórica que puede estudiarse en sí misma sin tener en cuenta, a priori, la finalidad última del autor al escribirlo. En este sentido un programa de ordenador no es muy diferente. Consta de un origen, que es resolver o dar una solución válida a un problema, y está elaborado por código informático. El código son letras estructuradas como en casi cualquier lenguaje escrito y tiene un significado. Existen muchas maneras de resolver un problema con código de la misma forma que existen muchas maneras de decir una misma cosa. Sin embargo no todo el código responde ante un canon estético. Pese a que cumpla con su finalidad, hay códigos bien escritos, códigos brillantes, códigos elegantes y códigos feos, horribles e ilegibles. La premisa perseguida siempre es la misma: simplicidad, tiempo y espacio. Desde los orígenes de la programación sobre ordenadores reales, los programadores tuvieron la limitación del espacio que el código podía usar, tanto en memoria como en almacenamiento, esto es, la cantidad de información que en un momento dado podía usar y la longitud del programa. Además no podía ser interminablemente lento en su ejecución. Fueron estas circunstancias las que provocaron que escribir código se convirtiese en una tarea artesanal, en una proceso de conocimiento extremo de los recursos disponibles de cada procesador para sacarle el mayor partido, de hallar la mejor solución bajo estos términos. En los tiempos en los que se programaba para ensamblador la programación era un arte. Más tarde llegaron los lenguajes de segunda generación, tercera, etc. que abstraían el código final que la máquina debía interpretar. Auto-generaban programas de la manera más eficiente posible a partir de instrucciones mucho más asequibles por el intelecto. Esto, junto con la aparición de la Ingeniería del Software, provocó que el código se desatendiera en pos de los requisitos. No era importante la calidad sino la funcionalidad. No estoy para nada de acuerdo con esto. Por fortuna llegó el movimiento del Software Libre en el que más o menos desinteresadamente se pone a disposición del que lo requiera las fuentes originales de los programas.

Es fácil encontrar aberraciones desde el punto de vista estético. Por suerte, en lenguajes como Python los autores y la comunidad alrededor de ellos se encargaron de constituir una guía de estilo que desde entonces sirve para determinar qué es buen código Python y qué no lo es. La norma que lo recoge es la PEP8. No es más que una forma de canon estético, el lenguaje seguirá funcionando exactamente igual mientras no haya errores sintácticos. Entonces, ¿por qué esa fijación por el buen código? Lo primero por la posibilidad de que otros tengan que modificar programas que no son suyos, un mejor código es más legible. Lo segundo, bajo mi punto de vista, es mero placer estético, el disfrute de la retórica que puede existir tras un montón de líneas, del porqué se usan unas instrucciones y no otras, etc.

A modo de ejemplo dejo un extracto de código que cumple con todas las normas del PEP8…


def combine(items, k=None):
    """
    Create a matrix in wich each row is a tuple containing one of solutions or
    solution k-esima.
    """
    length_items = len(items)
    lengths = [len(i) for i in items]
    length = reduce(lambda x, y: x * y, lengths)
    repeats = [reduce(lambda x, y: x * y, lengths)
               for i in range(1, length_items)] + [1]
    if k is not None:
        k = k % length
        # Python division by default is integer division (~ floor(a/b))
        indices = [(k % (lengths * repeats)) / repeats
                   for i in range(length_items)]
        return [items[indices] for i in range(length_items)]
    else:
        matrix = []
        for i, item in enumerate(items):
            row = []
            for subset in item:
                row.extend([subset] * repeats)
            times = length / len(row)
            matrix.append(row * times)
        # Transpose the matrix or return the columns instead rows
        return zip(*matrix)

…y otro que no.


def GaborFilter():
    var = pos_var/10.0
    w = pos_w/10.0
    phase = pos_phase*CV_PI/180.0
    psi = CV_PI*pos_psi/180.0

    cvZero(kernel)
    for x in range(-kernel_size/2+1,kernel_size/2+1):
        for y in range(-kernel_size/2+1,kernel_size/2+1):
            kernel_val = math.exp( -((x*x)+(y*y))/(2*var))*math.cos( w*x*math.cos(phase)+w*y*math.sin(phase)+psi)
            cvSet2D(kernel,y+kernel_size/2,x+kernel_size/2,cvScalar(kernel_val))
            cvSet2D(kernelimg,y+kernel_size/2,x+kernel_size/2,cvScalar(kernel_val/2+0.5))
    cvFilter2D(src_f, dest,kernel,cvPoint(-1,-1))
    cvShowImage("Process window",dest)
    cvResize(kernelimg,big_kernelimg)
    cvShowImage("Kernel",big_kernelimg)
    cvPow(dest,dest_mag,2)
    cvShowImage("Mag",dest_mag)

Actualización: Me envía el Prof. Suárez una iniciativa recién estrenada, de hecho salida directamente de unos de los foros de HASTAC tras la MLA 2011, una de las conferencias sobre Humanidades más grandes de todos los Estados Unidos. Su nombre es Critical Code Studies. Mark C. Marino lo ha resumido perfectamente en un sólo párrafo:

«Cada vez más el código determina, transforma y limita nuestras vidas, nuestras relaciones, nuestro arte, nuestras culturas y nuestras instituciones cívicas. Es el momento de sacar al código de las dobles comillas y moverlo más allá de la ejecución para comentarlo, documentarlo e interpretarlo. Saquemos el texto del código».

Parte III

Por último me gustaría mencionar un proyecto más que interesante que inspiró otro compañero de clase: Understanding Rayuela –al estilo del famoso Understading Shakespeare. Sucede que Rayuela, a pesar de la línea tradicional de lectura que Cortázar propone, más alguna que otra adicional, se puede construir de otras muchas. Siendo puristas, si la novela consta de 155 capítulos podríamos obtener las novelas correspondientes a todas las permutaciones, es decir, 155! novelas distintas. Si mis cálculos no me fallan, más de 4 mil hexadecillones de veces el número de partículas del universo. Un número bastante aterrador. Siendo un poco realistas no creo que realmente se puedan combinar de cualquier manera y con total seguridad el número de novelas posibles a partir de Rayuela será algo más abarcable. Lo que propongo es crear una aplicación capaz de obtener un resumen de todas las posibilidades de ordenación distintas de los capítulos de Rayuela e incluso las analice en los términos habituales de minería de textos. Podríamos ver cómo la aparición de ciertos términos en momentos concretos siguen desencadenando o no los mismos sucesos, o analizar cómo la frecuencia de los términos a lo largo de la obra determina o no el mensaje. Un conjunto interesante de posibilidades que luego podríamos aplicar a otras obras como 62 Modelo para amar o incluso a obras tradicionales para comprobar cómo afecta el orden de los capítulos a la creación de un resumen de la idea que se transmite.

4 Comments

Filed under Debates

4 Responses to La retórica del código

  1. Juan Luis Suárez

    Yo me apunto al Proyecto Rayuela y creo que debería ser uno de los proyectos-viernes-de-Google del CulturePlex. Hagamos el diseño de un proyecto completo, YA, con la inclusión posterior de líneas de debate y lectura “acogidas” por diferentes lectores o grupos de lectores para que la novela crezca como una red en las direcciones que la gente crea. Pero con una base que sea la aplicación nueva que describes y que nos obligue a pensar cómo es “un” proyecto de literatura en el marco de las humanidades digitales, de principio a fin. Serviría para que los que vayan aprendiendo NLTK lo vayan haciendo sobre problemas “reales” y tengan como tareas el desarrollo de nuevos módulos. Combinaría diseño de proyectos, creación de comunidad, desarrollo de una aplicación, escribir código, procesamiento de lenguaje natural, diseño gráfico, análisis literario, ……¿Qué más?

  2. Pingback: Qué sbornia tengo, hermano | diariosdenada

  3. Pingback: Miedo mainstream | In my humble opinion…

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <s> <strike> <strong>