- Gerald Sussman dice que desde 1962, pasando por entornos de cómputo tempranos como IBM 7094, PDP-6, Mac Hack 6 y Maxima, ha seguido aferrándose al placer de programar en sí mismo
- Programar no es codificar trasladando mecánicamente una especificación a código, sino algo más cercano a un diseño de ingeniería abstracto en el que se buscan a la vez una especificación posible y una implementación bajo objetivos incompletos
- Al poner lado a lado la estructura de eval/apply de Lisp y la interacción de las ecuaciones de Maxwell, ve la programación como una actividad creativa que aborda problemas conceptuales profundos, como la física, las matemáticas o la filosofía
- Los bugs no son simples fracasos, sino oportunidades de aprendizaje que surgen cuando humanos finitos resuelven problemas con planes simplificados, y forman parte de la “resolución de problemas depurando un plan casi correcto”
- La diferenciación automática, la ampliación de operaciones genéricas en Scheme y la experiencia de expresar la mecánica clásica como programas ejecutables muestran que la programación puede volver más claras otras disciplinas, y subraya que la diversión se completa al compartirlo como free/libre software
Diseño y exploración más allá del código
- Sussman usó computadoras desde 1962, cuando estaba en la secundaria, y conoció la computación en el Columbia Science Honors Program
- Las primeras computadoras, como la familia IBM 7094, costaban millones de dólares, solo podían direccionar 2^15 palabras de 36 bits y operaban con un ciclo de unos 2 microsegundos
- Tras entrar al MIT, conoció computadoras como la DEC PDP-6, y ese sistema podía direccionar 2^18 palabras de 36 bits
- La memoria grande era necesaria para sistemas tempranos de manipulación simbólica como Maxima
- MIT encargó memoria grande a Fabritek, tardó un año en fabricarse y en los registros figura con un costo de unos 380 mil dólares
- Como esa memoria era enorme para la época, la llamaron Moby, por el nombre de una ballena
- Participó en inteligencia artificial, diseño de nuevas computadoras, invención de lenguajes de programación, simulación numérica de mecánica celeste y escritura de grandes sistemas simbólicos, pero en el centro siempre estuvo su amor por programar
- Programar no es una tarea mecánica de convertir una especificación bien definida en código ejecutable
- Una buena especificación normalmente no baja desde arriba
- Primero se explora qué es implementable, y luego se redacta la especificación según lo que realmente se puede lograr
- Por eso, programar es una exploración conjunta para encontrar una especificación posible y una implementación posible hacia un objetivo parcialmente definido
- A diferencia de la ingeniería física, la programación está mucho más limitada por la capacidad de organizar el pensamiento que por restricciones físicas como tolerancias, curvaturas de corte o errores de resistencia
- El programador elige representaciones, algoritmos y niveles de abstracción mientras trabaja con una enorme máquina virtual
La programación como arte creativo
- Para explicar la sensación de programar, Sussman cita un texto en el que Edgar Allan Poe explica cómo escribió «The Raven»
- Poe dice que la obra no se completó por azar ni por intuición, sino paso a paso, como un problema matemático, y muestra un proceso complejo de elección, eliminación, inserción y revisión
- Ese proceso se parece mucho más a la sensación real de programar que a la idea de convertir una especificación en código
- La programación se parece más a un arte creativo como la arquitectura, la música, las matemáticas o la física teórica
- Las matemáticas son una actividad para inventar teoremas bellos
- La física teórica es una actividad para inventar explicaciones del mundo físico
- Programar también es una actividad de inventar y pulir ideas y estructuras
La estructura que mostraron eval/apply y las ecuaciones de Maxwell
- La experiencia de aprender Lisp 1.5 y el intérprete eval/apply en su primer año en MIT fue un punto de inflexión que cambió la vida de Sussman
- eval toma una expresión y un entorno, evalúa operador y operandos para producir un procedimiento y sus argumentos; apply toma el procedimiento y los argumentos, enlaza los argumentos a los parámetros formales y luego vuelve a la evaluación del cuerpo
- Sussman cree que esta estructura también se aplica a todos los lenguajes de programación y al propio funcionamiento de las computadoras
- En la misma época, al aprender las ecuaciones de Maxwell en una clase de electromagnetismo, recibió otra impresión muy fuerte
- Maxwell añadió el término de corriente de desplazamiento para resolver la inconsistencia entre la conservación de la carga y las ecuaciones existentes
- Como resultado apareció la ecuación de las ondas electromagnéticas y surgió la conexión de que la luz es una onda electromagnética
- Hay una profunda similitud entre la interacción de eval/apply y la estructura en la que los campos eléctrico y magnético generan cambios mutuos en las ecuaciones de Maxwell
- Esa similitud también se conecta con la relación entre variables duales como posición y momento, o energía y tiempo
- La programación se encuentra con problemas filosóficos de manera cotidiana
- No es simple cómo el nombre
Chicagodentro de un programa refiere a la ciudad real - Si dos objetos son idénticos se revela cuando, al modificar uno, también cambia el otro, y la mutación se conecta con el problema de la identidad
- En un programa puramente funcional no hay mutación, así que la identidad debe entenderse de otra manera
- Dentro de expresiones citadas puede romperse el principio de que “lo mismo puede sustituirse por lo mismo”
- Proposiciones como “todos los cuervos son negros” vuelven difícil el sentido de la evidencia, como en la paradoja del cuervo de Hempel
- No es simple cómo el nombre
Cómo tratar los bugs
- Sussman ve los bugs no como fracasos vergonzosos, sino como oportunidades de aprendizaje
- Dice que depurar con buenas herramientas puede ser tan divertido como una aventura, y que los bugs deberían tener nombres, como fencepost error o reader-writer bug
- Los bugs también son resultado de una estrategia de diseño poderosa
- Los humanos no pueden pensar en todo al mismo tiempo, así que hacen planes
- Los planes exigen simplificación, y la simplificación deja partes fuera
- Como resultado aparecen bugs, y depurar se vuelve el proceso de corregir un plan casi correcto hasta llevarlo a la dirección deseada
- Sussman llama a este enfoque “resolución de problemas depurando un plan casi correcto”
- El ejemplo del diseño de filtros eléctricos muestra esta estrategia
- Para crear un filtro con respuesta entre 30Hz y 3kHz, se factoriza la función del sistema
- Se construyen los subcircuitos necesarios combinando resistencias y capacitores
- Pero cada subcircuito asume que “no sale corriente”, así que al conectarlos juntos aparece un loading bug
- Un parche con amplificador puede resolver este problema en algunas situaciones
- No todos los bugs son divertidos
- Sussman critica a C y C++ por estar llenos de trampas
- También relaciona con código escrito en C las situaciones en que se necesita a menudo un kernel nuevo por bugs de manejo de memoria
- Incluso en Python menciona ejemplos de falta de consistencia:
{}es un diccionario, pero{1}es un set, y las tuplas se definen por la coma, no por los paréntesis
Diferenciación automática y física ejecutable
- En 1992, Sussman pasó tiempo en Caltech con el grupo de Kip Thorne, aprendió relatividad general y dice que usó programas como medio para almacenar conocimiento
- Junto con Dan, diseñador de chips de punto flotante en Hewlett-Packard, al pensar en la derivada de funciones redescubrió de forma independiente la diferenciación automática en modo directo (forward-mode automatic differentiation)
- El objetivo no era la diferenciación simbólica que inspecciona el interior de la función, ni una aproximación numérica
- La clave era la chain rule
- Si se extienden los números a objetos diferenciales con una parte finita y una parte infinitesimal, la chain rule opera automáticamente en la composición de funciones
- Como usaban Scheme, pudieron redefinir los operadores aritméticos primitivos para ajustarlos a esos objetos diferenciales, y Sussman dice que lo implementó durante la noche en un “hack attack”
- Después, varias personas contribuyeron a pulir derivadas de funciones de orden superior, derivadas múltiples y la ampliación dinámica de operaciones primitivas en Scheme
- Abelson ayudó a ordenar la teoría correcta de las derivadas múltiples
- Jeff Siskind, Barak Pearlmutter y Alexey Radul depuraron bugs sutiles en las derivadas de funciones de orden superior
- Hansen ideó una forma eficiente de ampliar dinámicamente las operaciones primitivas de Scheme
- Ese trabajo llevó al sistema Scmutils, usado junto con Jack Wisdom para enseñar e investigar mecánica clásica y geometría diferencial
- El libro de Sussman y Wisdom, Structure and Interpretation of Classical Mechanics, es un intento de aclarar la comprensión de la mecánica clásica mediante técnicas computacionales
- La notación tradicional de las ecuaciones de Lagrange es ambigua sin conocimiento cultural previo, y también tiene problemas desde la perspectiva del tipo de función
- Si se escribe con notación funcional y código Scheme, la idea matemática se vuelve un programa ejecutable claro
- En el ejemplo del oscilador armónico, se calculan la ecuación correcta del movimiento y la relación de frecuencia angular a partir de la masa, la constante del resorte y la posición
La diversión se completa cuando se comparte
- Sussman resume el placer de programar en varias dimensiones
- El placer de descubrir similitudes profundas entre mundos diferentes
- El placer de encontrarse, en el trabajo real, con problemas que filósofos llevan mucho tiempo pensando
- El placer de la cacería al rastrear bugs
- El placer de descubrir buenas ideas y abstracciones
- El placer de hacer más claras otras disciplinas mediante programas
- La diversión de programar se completa al compartir el trabajo con otras personas, y recomienda usar y crear free/libre software
- Sussman lamenta que haya tenido que grabarlo por Zoom, y dice que quiere software que pueda leerse, modificarse y volver a compartirse
- Sobre el software libre y la libertad del software, recomienda ver la filosofía del software libre de GNU y pide participar y donar a la Free Software Foundation
1 comentarios
Comentarios en Hacker News
Esta parte me encantó de verdad: “Escribo programas como una forma de recordar cosas. Mi memoria son los programas que escribo. Si aprendo cosas como matemáticas, física o biología y escribo programas que las expresen, cuando los releo después no son ambiguos y son fáciles de entender, así que es una manera de guardar conocimiento”
https://www.infoq.com/presentations/Expression-of-Ideas/
Trata un tema muy cercano a la cita de arriba y aborda cómo programar ayuda a entender más profundamente cosas como las matemáticas y la física
Por ejemplo, entender cómo funcionan los analgésicos ayuda a comprender un keylogger o un ataque man-in-the-middle, y ver la “revisión gramatical” del ADN durante la mitosis permite aprender mucho sobre compilación en general
El hecho de que los cachorros se traguen cualquier cosa que ven también le da al sistema inmune suficientes datos de prueba sobre el entorno, así que se parece al aprendizaje automático, y una buena parte de los conceptos de ciberseguridad también se puede entender a través de la biología
Yo tiendo a pensar en imágenes, así que me costaba mucho entender de verdad las matemáticas, pero programar me permitió crear imágenes y relaciones dentro de mi cabeza
Tuve suerte de descubrir eso de niño; sin eso, creo que me habría perdido
El problema, las decisiones, las razones, los hechos que las sustentan y las alternativas que se revisaron son conocimiento, y desde esa perspectiva cada instrucción introducida en un lenguaje de programación también es una decisión
El diseño de software puede durar tanto que se olviden decisiones previas y su contexto, y también tanto que la gente se vaya, el conocimiento se pierda y llegue gente nueva con poco contexto
Lograr que la computadora entienda el código fuente no es la parte difícil; lo más difícil es permitir que otras personas entiendan qué se logró para poder trabajar mejor y más rápido
Cuando la cabeza y la memoria no bastan, hay que apoyarse en tecnologías como la escritura, la imprenta o el software para recordar y organizar conjuntos de conocimiento más grandes
En matemáticas, mi mayor problema también era que no podía confiar en no cometer errores, ni en que sería capaz de detectarlos
El compilador o el intérprete hace que me dé cuenta
Hace tiempo escuché una charla de Sussman en un sótano de NYU junto con unos 20 estudiantes de doctorado en neurociencia
Ya hablaba de interpretabilidad de IA mucho antes de que se pusiera de moda
Le hice una pregunta, detectó de inmediato que había alguien de ingeniería eléctrica en la sala y se fue al pizarrón de al lado para mostrar que se puede deducir desde primeros principios cómo funciona un amplificador operacional
Esa persona tenía una cantidad increíble de energía e inteligencia, y sin duda dejó una impresión profunda
Aún no veo el video, pero enseguida pensé en la cita de Alan J. Perlis que Sussman y Abelson usaron en la dedicatoria de SICP
Dice que en ciencias de la computación es muy importante preservar la diversión de la computación, y que al principio realmente era divertida
A veces los clientes salían perjudicados y empezamos a tomarnos esas quejas en serio, pero desde esa mirada no se considera que tengamos la responsabilidad del uso perfecto, exitoso y libre de errores de estas máquinas
Más bien tenemos la responsabilidad de llevar las máquinas al límite y empujarlas en nuevas direcciones para mantener la diversión, y lo central es esperar que las ciencias de la computación no pierdan ese sentido de diversión ni se comporten como misioneros o vendedores de biblias
No hay que sentir que la clave de la computación exitosa está solo en nuestras manos; lo que tenemos en las manos es el intelecto, es decir, la capacidad de ver la máquina como algo más de lo que parecía al principio y hacerla más grande
Para la mayoría de los demás, que hacen programas para contar frijoles, desde el punto de vista de quien paga el salario es mucho más importante no perder ni un solo frijol que cuánto nos divertimos o cuánto ampliamos las posibilidades
O sea, no es un bug sino una pequeña bola de diversión /s
Un mejor título sería algo más cercano a “la ciencia de la computación académica es divertida, o debería serlo”
La idea central es que descubrir analogías, pensar filosóficamente, depurar, tener buenas ideas y ganar claridad son cosas divertidas, pero eso se parece más al lujo de un profesor al que le pagan por hacer ese tipo de actividades, y no encaja demasiado en el mundo de “el cliente quiere esto para este fin de semana”, salvo quizá por el placer debatible de depurar
La mayor parte de la “programación” probablemente debería verse más como una materia de escuela técnica, como la soldadura
Desarrollar una nueva técnica de soldadura sí sería un tema de investigación de posgrado, pero la mayoría de los soldadores y programadores trabajan con herramientas bien conocidas y sistemas relativamente simples
Un estudiante de escuela técnica quizá no quiera perder tiempo aprendiendo MIT/GNU Scheme para luego no volver a usarlo en su vida profesional, mientras que para un estudiante académico puede ser algo valioso, como para un estudiante de lingüística aprender a leer y escribir Linear B
Cualquier trabajo puede ser divertido, pero al final siempre pesaron más factores como la capacidad y estabilidad emocional de colegas y gerentes, el diseño y la seguridad del espacio de trabajo, una remuneración digna y si la cultura organizacional permite o no dejar pasar trabajo chapucero; y lo mismo vale para otras profesiones especializadas, como la programación de sistemas de control industrial
Una persona curiosa, reflexiva y culta, sea autodidacta o no, termina haciendo mejor cualquier trabajo que alguien que no lo es
Cuando trabajé como soldador hace muchos años, la gente inteligente, motivada y curiosa también lo hacía mejor que quienes solo estaban matando el tiempo
Así que sí estoy de acuerdo en que programar se parece a soldar, pero de una manera distinta a la que se pretendía
SICP cambió por completo mi forma de pensar sobre el código, la abstracción y la modularidad, mientras estaba al lado de compañeros que hacían hacks en Pascal o C
Con Lisp/Scheme podía construir un modelo mental del problema, mientras que mis compañeros tenían que hacer la abstracción en su cabeza y luego implementarla en lenguajes que exigían enfocarse en el bajo nivel
Por eso estaré eternamente agradecido de haber conocido SICP desde temprano
Dependiendo del lenguaje en el que programes, puede resultar más divertido o más cómodo
Creo que probablemente nunca llegaré a sentirme cómodo con C++
Está bueno escuchar la perspectiva sobre la programación de uno de los autores de SICP, y las anécdotas de los primeros minutos también están buenas
Cuando dije que lo necesitaba sí o sí porque iba a ver a Sussman al día siguiente, un empleado llamó al co-op de Harvard, le dijeron que tenían un ejemplar en stock, así que tomé un Uber a la librería de Harvard y compré SICP
Al día siguiente fui a la oficina de Sussman en MIT y, por casualidad, Abelson también estaba ahí y justo estaba por irse, así que los dos firmaron mi ejemplar de SICP
Sussman agregó: “¡Si hubieras llegado 15 minutos antes, mi esposa también te lo habría firmado!” y hasta ese momento yo no sabía que su esposa había sido la correctora de SICP
También tengo una gran foto con estos dos magos y el libro morado que acababan de firmarme
Tengo muchas ganas de ver este video pronto
Todavía no me he metido de lleno con SICP, pero ya tomé prestado el libro y escuché las clases mientras hacía reparaciones en la casa
Suelo poner una cita de Sussman sobre entender cosas complejas en presentaciones relacionadas con arquitectura, y siempre es una diapositiva que la gente se apura a copiar
Siendo honesto, amé programar durante años, y en algún momento incluso fue mi hobby principal
Solía probar nuevos lenguajes o software, leer libros de programación y participar en varios chats como libera/freenode
Pero cuando me volví freelancer y empecé a enfocarme en entregar rápido código suficientemente bueno dentro de contextos más pequeños, esa pasión fue disminuyendo
Como ingeniero, en general puede ser algo bueno, pero en el trabajo cotidiano desaparecieron mucho de la diversión y el aprendizaje
El freelance y la consultoría normalmente consisten en resolver problemas, incluso en apagar incendios, y eliminar el problema lo más rápido posible; la elegancia no es indispensable
Si lo que quieres es ser alguien que construye herramientas, no parece que eso vaya a pasar mucho en el freelance, aunque tal vez sí si te mueves a un rol de consultor
Como veo al consultor como una relación un poco más de largo plazo, podría valer la pena considerarlo como siguiente paso