Programación: aspectos sicológicos

Esta entrada tiene una doble (o triple) motivación. Por un lado, servir de de introducción a otra en la que se tratará la sicología de la estadística y la ciencia de datos. Por otro, plantear una serie de cuestiones —sin intención de aportar solución alguna— relevantes sobre el asunto. Y si se me permite, una tercera: dejar constancia que en su día semileí el librito The Psychology of Computer Programming, que fue el que me ha hecho pensar de vez en cuando sobre estos asuntos y prestarles atención desde entonces.

La programación de ordenadores es una actividad humana y está condicionada hasta lo más hondo por ella. Al fin y al cabo, los ordenadores no ven otra cosa que secuencias de bits y las CPUs se limitan a ejecutar operaciones simples sobre ellas. Existe un número finito y corto de tales operaciones y no sé hasta qué punto sería posible hacer ingeniería inversa e identificar quién programó y en qué lenguaje un código que generase una secuencia dada de operaciones de bajo nivel (en lenguaje máquina, por centrar ideas).

Los lenguajes de programación intermedian entre un dispositivo supersimple —la CPU— y un agente humano, el programador, ofreciendo una API. Esta API puede estar más próxima a los requisitos de la máquina, como en C, o a los del programador, como en R o Logo.

Cuando un lenguaje como Haskell hace gala de una gran abstracción matemática, en el fondo está diciendo: esperamos del programador humano familiaridad con las abstracciones matemáticas. Puede que incluso algún proponente de Haskell esté asumiendo que todo programador humano —incluso todo ser humano— debería encontrar natural un altísimo grado de abstracción matemática. Lo que, al final, no es sino una afirmación que pertenece al ámbito no sé si de la sicología o de la antropología.

Otros lenguajes de programación son mucho más laxos en ese sentido. Y puede que por ello más exitosos.

Ya casi no recuerdo detalles del libro mencionado más arriba. El más notorio es que es muy viejo —¿de primeros de los setenta?— y que casi todos los ejemplos de programación están basados no sé si en PL-I o PL-II —sí, la familia de lenguajes de los que acabó derivándose SAS— y, por lo tanto, y en ese sentido concreto, obsoleto. A pesar de ello, me pareció que todo aquello que tocaba al lado del programador era todavía muy actual. En su día traté de encontrar literatura posterior sobre el asunto y no encontré nada relevante —aunque a día de hoy pudieran haber cambiado las cosas—.

Lo que sí que encuentra uno por doquier en todos esos libros sobre programación son apotegmas pop —p.e., keep it simple, divide y vencerás, don’t repeat yourself, etc.— que constituyen con respecto a lo que ando buscando y por analogía, lo equivalente a la literatura de autoayuda con respecto al canon académico de la sicología.

De todos modos, si la gente sigue construyendo código complejo, no divide para vencer o se repite una y mil veces es porque existen motivos poderosos, anclados en el ámbito de la sicología, que nos hacen incurrir una y otra vez en ellos.

No puedo contar mucho más porque no sé lo suficiente. Sí que informo que sigo interesado —¿alguien me puede echar un cable?— sobre literatura más moderna sobre el asunto y que estoy pensando en escribir una entrada en la que traslade el meollo del asunto de la programación a la estadística y la ciencia de datos.