- Leslie Lamport es uno de los primeros desarrolladores de LaTeX y un pionero en el campo de los sistemas distribuidos. Ganó el Premio Turing en 2013
- En su keynote de SCaLE 22x enfatizó la importancia de la abstracción, señalando que la mayoría de los programadores se obsesionan con el código y el lenguaje, pero que pensar y diseñar en abstracto antes de codificar es lo esencial
Resumen de la charla
- Podrían esperar que yo hablara sobre concurrencia (Concurrency), pero no tengo nada nuevo que decir al respecto
- Sin embargo, las ideas sobre "escribir programas concurrentes" también se aplican a toda la programación en general
- Esta charla trata sobre la programación en su conjunto
Algoritmo vs. programa
- Algoritmo: una idea abstracta independiente del lenguaje. Es un concepto más abstracto y de nivel superior que un programa
- Programa: la forma concreta de implementar un algoritmo en un lenguaje específico. Los lenguajes de programación son demasiado complejos para expresar algoritmos
- Un algoritmo no se ejecuta y por lo general es corto y simple
- Especialmente en código relacionado con concurrencia, primero hay que definir e implementar el algoritmo correcto
La abstracción vista con el ejemplo del máximo de un arreglo
- Incluso en un problema simple hay que definir con claridad "qué se va a hacer (What)"
- Ejemplo: "devolver el valor máximo de un arreglo de enteros" → "devolver el menor número que sea mayor o igual que todos los elementos"
- También hay que definir de antemano cómo manejar un arreglo vacío (por ejemplo, usar
-∞)
- Con una definición clara como esta, es posible derivar un algoritmo (How) más simple y robusto
La ejecución de un programa es un flujo de estados
- La ejecución de un programa no es solo una secuencia de instrucciones, sino una sucesión de estados (state)
- Cada transición de estado representa la ejecución de una parte del código
- Esta forma de verlo es importante para demostrar la corrección de un algoritmo (uso de invariantes, etc.)
Una herramienta para sistemas complejos: TLA+
- Para expresar la abstracción con precisión se necesita un lenguaje exacto
- TLA+ es una herramienta diseñada para ese propósito
- Amazon Web Services usó TLA+ para detectar con anticipación fallas graves de diseño
- Virtuoso, el sistema operativo de la sonda Rosetta, también fue diseñado con base en TLA+, y su código era conciso y estable
El papel de la abstracción incluso con especificaciones incompletas
- Ejemplo: en un pretty printer, los criterios de alineación pueden ser subjetivos
- Aun así, definir un conjunto de reglas abstractas es importante para el debugging y el mantenimiento
La relación entre escribir y pensar
- Poner los pensamientos por escrito ayuda a aclarar el razonamiento
- La abstracción no debe hacerse solo en la cabeza; hay que expresarla por escrito para que sea efectiva
- Lamport mencionó que su formación matemática le ayudó a desarrollar su capacidad de abstracción
- Los matemáticos pueden enseñar abstracción a los programadores
Cómo ver las librerías y los bugs
- En la segunda parte de la charla, "Por qué los programas deben tener bugs", trató el problema de la complejidad
- El software moderno depende de muchas librerías, pero estas carecen de descripciones precisas e independientes del lenguaje
- Por eso, durante la integración aparecen bugs inesperados
- Ejemplo: su experiencia depurando JavaScript en el sitio de su curso de TLA+
- La perspectiva basada en estados es útil para entender esta complejidad
Temas tratados en la sesión de preguntas y respuestas
- El impacto de la IA en la abstracción
- La desconexión entre el open source y la academia
- La realidad de que los desarrolladores descuidan las definiciones formales (formal definition)
- Lo más importante sigue siendo "pensar antes de codificar"
Conclusión: la esencia de programar es pensar
- Lamport sostiene que se debe priorizar el pensamiento abstracto y las especificaciones formales por encima de la simple codificación
- Aunque el esfuerzo inicial sea grande, al final conduce a software más robusto y más fácil de mantener
- Codificar es solo una parte de programar; la programación de verdad comienza con algoritmos precisos y abstracción
- En un mundo moderno donde aumentan la complejidad de los sistemas y la concurrencia, la abstracción es una capacidad esencial, y los programadores necesitan entrenarse para pensar y abstraer
5 comentarios
Yo también estoy de acuerdo con este artículo.
Creo que definir los problemas con valores de estado abstraídos es útil para descubrir problemas, y estoy intentando crear herramientas de gestión de estados que sean claras de forma visual y explícita, como la visualización de estados con diagramas, Unreal Blueprint o los flujos de trabajo.
Supongo que primero tendré que fijarme en el lenguaje.
¡Es un texto que me recuerda a las clases de teoría de la computación! Se lo recomiendo a quienes programan para que lo estudien.
Me da curiosidad saber qué es TLA
Tendré que buscarlo
Yo también tenía curiosidad, así que lo busqué.
TLA+ - un lenguaje avanzado para modelar programas y sistemas concurrentes/distribuidos
Comentarios de Hacker News
Los "coders" de la demoscene se llaman así y se sienten orgullosos de ello, y a menudo también son excelentes "programmers" e "ingenieros de software". Ya sea que uses el nombre coder, programmer, ingeniero de software o cualquier otro, lo importante es lograr que la computadora haga lo que quieres
Parece que la keynote del próximo año será "vibing no es coding, ni tampoco programming...; a veces es una pirámide de basura que medio funciona". Menos mal que Dijkstra no llegó a ver esto. Ya estaba enojado en la sala de estar de mis padres en los 80. Ni me imagino cómo habría reaccionado al ver el "vibe coding"
Keynote de Leslie Lamport en SCaLE 22x: pensar, abstraer y luego codificar. Lamport argumentó a favor de un cambio fundamental en la forma de programar, enfatizando el pensamiento y la abstracción antes de codificar, y esto aplica a todo código no trivial
Programar debería ser un proceso deliberado que siga un diseño cuidadoso (abstracción) y luego la implementación (codificación), con énfasis en especificaciones claras y en comprender el comportamiento del programa a través de secuencias de estados e invariantes. Pensar siempre es mejor
Un profesor de matemáticas llamaba coding a cualquier acto de transformar conceptos a una forma más precisa y legible por máquina. No solo escribir en un lenguaje de programación lo que quieres que haga una computadora, sino también codificar datos. La palabra "encode" lo deja claro. Daban tareas para definir una manera de codificar un árbol binario como un número natural. La palabra coding es demasiado ambigua, así que no la usan mucho
Lamport sostiene que hay que separar el "qué" del "cómo". Pero me pregunto si, en la mayoría de los problemas, el "qué" y el "cómo" de un programa no terminan algo mezclados. Por ejemplo, ¿las consideraciones de rendimiento son parte del "qué" o del "cómo"?
Resumen interesante: un algoritmo no es un programa, no debería escribirse en un lenguaje de programación y debería ser simple. En cambio, un programa debe ejecutarse rápido sobre conjuntos de datos potencialmente grandes, así que necesita ser complejo. Esto se discute especialmente porque el orden de ejecución de los programas concurrentes que corren en múltiples CPU varía
Define un programa como código que requiere pensar antes de escribirlo, código que usarán personas que no quieren leer el código. Esta charla se viene dando desde hace mucho tiempo. El ejemplo de simplificar la búsqueda del elemento más pequeño coincide exactamente con "Define Errors Out of Existence" del libro de John Ousterhout
Disfruto la ironía de que la sección de comentarios esté llena sobre todo de personas que no entendieron el mensaje. El punto central de Leslie Lamport es que desarrollar la capacidad de pensar en abstracto lleva a mejores programas. La abstracción en el sentido matemático y lógico permite eliminar todos los detalles irrelevantes. El desarrollo de software guiado por IA también es así
Como cabría esperar de cualquier cosa relacionada con el rigor, mucha gente reaccionó negativamente con solo leer el título. Un hacker en Hacker News puede ser un programador hábil capaz de resolver problemas. Ahora también puede significar "You're a Hack": alguien incompetente que produce resultados de baja calidad
Esta charla y la discusión son excesivamente minuciosas
Ahora mismo hay un buen artículo en ACM que dice que no se ponen de acuerdo sobre qué es la abstracción, pero que aun así es muy útil. En general estoy de acuerdo en dónde está el punto importante. No estoy de acuerdo sobre exactamente qué es ni por qué es importante. Se puede sacar mucha inspiración de ahí, y eso ya tiene valor por sí mismo
Hacking no es coding, ni programming, ni desarrollo de software, ni ingeniería de software. Pero al final mucha gente usa estos términos casi como si fueran intercambiables, y enfatizar las diferencias de definición que uno usa personalmente casi nunca es un uso productivo del tiempo