John McCarthy, Lisp y las raíces del diseño simbólico de la IA

Por qué McCarthy y Lisp siguen importando

Esto no es un tour de museo de la “IA antigua”. Es una lección histórica práctica para cualquiera que construya software—programadores, leads técnicos y responsables de producto—porque las ideas de John McCarthy moldearon cómo pensamos sobre para qué sirven los lenguajes de programación.

Lisp no fue solo una nueva sintaxis. Fue una apuesta de que el software podría manipular ideas (no solo números) y que las decisiones de diseño del lenguaje podían acelerar la investigación, la iteración de producto y ecosistemas de herramientas enteros.

Una forma útil de leer el legado de McCarthy es verlo como una pregunta que aún importa hoy: ¿qué tan directamente podemos convertir la intención en un sistema ejecutable—sin ahogarnos en boilerplate, fricción o complejidad accidental? Esa pregunta resuena desde el REPL de Lisp hasta los flujos modernos de “chat-a-aplicación”.

La gran idea de John McCarthy: hacer programable el razonamiento

John McCarthy no solo se recuerda por ayudar a lanzar la IA como campo de investigación, sino por insistir en un tipo específico de IA: sistemas que pudieran manipular ideas, no meramente calcular respuestas. A mediados de los años 50 organizó el Dartmouth Summer Research Project (donde se propuso el término “inteligencia artificial”) y luego influyó el trabajo en IA en MIT y después en Stanford. Pero su contribución más duradera quizá sea la pregunta que no dejaba de plantear: ¿y si el razonamiento mismo pudiera expresarse como un programa?

De números a símbolos

La mayoría de los primeros éxitos informáticos fueron numéricos: tablas balísticas, simulaciones de ingeniería, optimización y estadística. Esos problemas encajaban bien en la aritmética.

McCarthy apuntó a algo distinto. El razonamiento humano opera a menudo con conceptos como “si”, “porque”, “pertenece a”, “es un tipo de” y “todas las cosas que cumplen estas condiciones”. Eso no se representa de forma natural con valores de punto flotante.

El enfoque de McCarthy trataba el conocimiento como símbolos (nombres, relaciones, categorías) y concebía el pensamiento como transformaciones basadas en reglas sobre esos símbolos.

Una forma de verlo a alto nivel: los enfoques numéricos responden “¿cuánto?” mientras que los simbólicos intentan responder “¿qué es?” y “¿qué se sigue de lo que sabemos?”.

Lisp como la herramienta adecuada

Si crees que el razonamiento puede hacerse programable, necesitas un lenguaje que pueda representar cómodamente expresiones como reglas, afirmaciones lógicas y relaciones anidadas—y luego procesarlas.

Lisp se construyó para ese objetivo. En lugar de forzar las ideas en estructuras de datos rígidas y predefinidas, Lisp hacía natural representar código y conocimiento con formas similares. Esa elección no fue solo estilística: fue un puente práctico entre describir un pensamiento y ejecutar un procedimiento, que es exactamente el cruce que McCarthy quería para la IA.

Pensamiento simbólico, en términos llanos

Cuando McCarthy y los primeros investigadores en IA decían “simbólico”, no hablaban de matemáticas misteriosas. Un símbolo es simplemente una etiqueta con significado: un nombre como customer, una palabra como hungry, o una marca como IF y THEN. Los símbolos importan porque permiten a un programa trabajar con ideas (categorías, relaciones, reglas) en vez de solo números brutos.

Una forma sencilla de imaginarlo: las hojas de cálculo son geniales cuando tu mundo son columnas y operaciones aritméticas. Los sistemas simbólicos son geniales cuando tu mundo son reglas, categorías, excepciones y estructura.

Símbolos: nombres con intención

En muchos programas, la diferencia entre 42 y "edad" no es el tipo de dato—es lo que el valor representa. Un símbolo te da algo con lo que comparar, almacenar y combinar sin perder significado.

Eso hace natural representar cosas como “París es una ciudad” o “si la batería está baja, busca un cargador”.

Listas: la estructura más simple para “hecho de partes”

Para hacer algo útil con símbolos necesitas estructura. Lisp popularizó una estructura muy simple: la lista. Una lista es simplemente un grupo ordenado de elementos, y esos elementos pueden ser listas a su vez. Con esa única idea puedes representar oraciones, formularios y conocimiento con forma de árbol.

Aquí hay un ejemplo conceptual pequeño (en estilo Lisp):

(sentence (subject robot) (verb needs) (object power))

Se lee casi como inglés: una oración compuesta por sujeto, verbo y objeto. Como está estructurada, un programa puede extraer (subject robot) o reemplazar (object power) por otra cosa.

De las estructuras al razonamiento: reglas, planificación, búsqueda

Una vez que la información está en estructuras simbólicas, las tareas clásicas de IA se vuelven abordables:

• Reglas: IF un patrón coincide, THEN concluye algo nuevo.
• Planificación: representa metas y acciones como listas, luego encadena acciones para alcanzar una meta.
• Búsqueda: explora diferentes combinaciones simbólicas posibles (estados) para encontrar una solución.

El cambio clave es que el programa no solo calcula; manipula piezas de conocimiento significativas en una forma que puede inspeccionar y transformar.

Por qué las decisiones de diseño de lenguaje repercuten por décadas

Las decisiones de diseño de Lisp no se quedaron en la academia. Influyeron en cómo la gente construyó herramientas y en la rapidez con que podían explorar ideas:

• Expresividad: Lisp facilitó representar conocimiento estructurado y transformarlo.
• Iteración rápida: el desarrollo interactivo acortó el ciclo entre “pensar” y “probar”.
• Extensibilidad: el lenguaje fomentó construir nuevas abstracciones en lugar de repetir patrones.

Esas cualidades tienden a producir ecosistemas donde experimentar es barato, los prototipos se convierten en productos más rápido y los equipos pueden adaptarse cuando cambian los requisitos.

Los objetivos de diseño detrás de Lisp

Lisp nació con un problema de diseño muy práctico: ¿cómo escribir programas que trabajen con símbolos tan naturalmente como trabajan con números?

McCarthy no intentaba crear una “mejor calculadora”. Quería un lenguaje donde una expresión como (is (parent Alice Bob)) pudiera almacenarse, inspeccionarse, transformarse y razonarse tan fácilmente como (+ 2 3).

Un lenguaje construido para datos simbólicos

La prioridad fue hacer que la información simbólica fuera fácil de representar y manipular. Eso llevó a enfocarse en listas y estructuras tipo árbol, porque encajan bien con formas que los humanos ya usan para expresar significado: oraciones, reglas lógicas, categorías anidadas y relaciones.

Sencillez que desbloquea flexibilidad

Otro objetivo fue mantener el núcleo del lenguaje pequeño y consistente. Cuando un lenguaje tiene menos “casos especiales”, pasas menos tiempo memorizando reglas y más tiempo componiendo ideas. Lisp se inclinó por un pequeño conjunto de bloques que podían combinarse en abstracciones mayores.

Programas con forma de datos

Una idea clave fue que los programas y los datos pueden compartir la misma estructura. En pocas palabras: si tus datos son una lista anidada, tu programa puede ser también una lista anidada.

Eso significa que puedes:

• generar un programa (como datos estructurados)
• modificarlo (como cualquier otro dato)
• y luego ejecutar el resultado

Un cambio cultural en el diseño de lenguajes

Lisp también popularizó una mentalidad: los lenguajes no tienen que ser talla única. Pueden diseñarse alrededor de un dominio—como razonamiento, búsqueda y representación del conocimiento—y aun así influir en la programación general durante décadas.

S-expressions: una estructura simple con grandes consecuencias

Las S-expressions (expresiones simbólicas) son la idea distintiva de Lisp: una forma única y consistente de representar código y datos como listas anidadas.

A simple vista, una S-expression es solo paréntesis alrededor de ítems—algunos ítems son átomos (nombres y números), y otros son listas. La regla de “listas dentro de listas” es todo el propósito.

Una forma para todo

Como la estructura es uniforme, los programas Lisp se construyen con los mismos bloques desde abajo hacia arriba. Una llamada a función, un fragmento de configuración y una pieza de la estructura del programa pueden expresarse como una lista.

Esa consistencia paga de inmediato:

• El parseo se simplifica: el lenguaje no necesita un zoológico de casos especiales.
• Transformar código es práctico: es más sencillo recorrer un árbol de listas y reescribir partes.
• Evaluar es más regular: el evaluador puede tratar muchas construcciones de forma consistente porque comparten la misma forma subyacente.

Incluso si nunca escribes en Lisp, ésta es una lección de diseño importante: cuando un sistema se construye a partir de una o dos formas previsibles, pasas menos tiempo luchando con casos límite y más tiempo construyendo.

Composición que se siente

Las S-expressions fomentan la composición porque piezas pequeñas y legibles se combinan naturalmente en otras mayores. Cuando tu programa es “solo listas anidadas”, combinar ideas suele implicar anidar una expresión dentro de otra o ensamblar listas a partir de partes reutilizables.

Esto te empuja hacia un estilo modular: escribes operaciones pequeñas que hacen una cosa y luego las apilas para expresar una intención mayor.

El trade-off: paréntesis

El inconveniente obvio es la falta de familiaridad. Para muchos recién llegados, una sintaxis cargada de paréntesis parece extraña.

Pero la ventaja es la previsibilidad: una vez entiendes las reglas de anidación puedes ver la estructura de un programa de forma fiable—y las herramientas también. Esa claridad es una gran razón por la que las S-expressions tuvieron consecuencias más allá de Lisp.

Recursión y procesamiento de listas como bloques centrales

La recursión se entiende mejor con una metáfora cotidiana: ordenar una habitación desordenada haciendo habitaciones más pequeñas. No intentas resolver todo a la vez. Recoges un objeto, lo pones donde corresponde y repites la misma acción con lo que queda. Los pasos son simples; el poder viene de repetirlos hasta que no quede nada por hacer.

Lisp apuesta por esta idea porque gran parte de sus datos se construye naturalmente a partir de listas: una lista tiene una “primera cosa” y “el resto”. Esa forma encaja perfectamente con el pensamiento recursivo.

Para procesar una lista, manejas el primer elemento y luego aplicas la misma lógica al resto. Cuando la lista está vacía, paras—ese es el limpio momento de “no queda nada por hacer” que hace que la recursión parezca bien definida en vez de misteriosa.

Mini-ejemplo conceptual: sumar una lista

Imagina que quieres el total de una lista de números.

• Si la lista está vacía, la suma es 0.
• Si no, la suma es el primer número más la suma del resto.

Eso es todo. La definición se lee como lenguaje natural y la estructura del programa refleja la idea.

Pensar en “recorrer un árbol”

La IA simbólica suele representar expresiones como estructuras en árbol (un operador con subexpresiones). La recursión es una forma natural de “recorrer” ese árbol: evalúa la parte izquierda como evalúas la derecha y sigue hasta llegar a un valor simple.

Estos patrones ayudaron a moldear la programación funcional posterior: funciones pequeñas, casos base claros y transformaciones de datos fáciles de razonar. Incluso fuera de Lisp, el hábito de dividir el trabajo en “haz un paso, luego repite sobre el resto” conduce a programas más limpios y menos efectos secundarios ocultos.

Recolección de basura: una característica de productividad, no un detalle

Los primeros programadores a menudo tenían que gestionar la memoria a mano: asignar espacio, seguir quién lo “posee” y recordar liberarlo en el momento adecuado. Ese trabajo no solo ralentiza el desarrollo: crea una clase de errores difícil de reproducir y fácil de enviar a producción: fugas que degradan el rendimiento y punteros colgantes que hacen fallar programas mucho después del error original.

Qué hace la recolección de basura (en términos llanos)

John McCarthy introdujo la recolección de basura para Lisp como una forma de permitir que los programadores se centraran en el significado en lugar de la contabilidad.

A alto nivel, la recolección de basura (GC) encuentra automáticamente piezas de memoria que ya no son accesibles desde el programa en ejecución—valores que nadie puede usar nunca más—y recupera ese espacio.

En vez de preguntar “¿liberamos cada objeto exactamente una vez?”, la GC cambia la pregunta a “¿este objeto sigue siendo accesible?”. Si el programa no puede alcanzarlo, se considera basura.

Por qué esto es realmente sobre productividad

Para el trabajo de IA simbólica, los programas Lisp crean con frecuencia muchas listas, árboles y resultados intermedios de corta vida. La gestión manual de memoria convertiría la experimentación en una batalla constante con la limpieza de recursos.

La GC cambia la experiencia diaria:

• Iteración más rápida: puedes prototipar libremente sin diseñar una estrategia de memoria primero.
• Menos errores que provocan fallos: se reducen o eliminan categorías enteras de fallos relacionados con punteros.
• Código más limpio: las funciones pueden devolver estructuras nuevas sin contratos ocultos sobre quién libera qué.

La idea clave es que una característica del lenguaje puede ser un multiplicador de equipo: menos horas depurando corrupción misteriosa significa más tiempo mejorando la lógica real.

Influencia a largo plazo

La decisión de McCarthy no se quedó en Lisp. Muchos sistemas posteriores adoptaron GC (y sus variantes) porque el trade-off suele compensar: Java, C#, Python, entornos de JavaScript y Go dependen de la recolección de basura para hacer el desarrollo a gran escala más seguro y rápido—incluso cuando el rendimiento importa.

Evaluación y macros: extender el lenguaje desde dentro

Qué significa “evaluar” (sin jerga)

En Lisp, una expresión es un trozo de código escrito en una forma consistente (a menudo una lista). Evaluar es simplemente el proceso de decidir qué significa esa expresión y qué produce.

Por ejemplo, cuando escribes algo como “sumar estos números” o “llamar a esta función con estos inputs”, el evaluador sigue un pequeño conjunto de reglas para convertir esa expresión en un resultado. Piénsalo como el árbitro del lenguaje: decide qué hacer después, en qué orden y cuándo parar.

Por qué un evaluador pequeño y consistente es una superpotencia

El movimiento clave de McCarthy no fue solo inventar nueva sintaxis—fue mantener el “motor de significado” compacto y regular. Cuando el evaluador se construye con pocas reglas claras, suceden dos cosas buenas:

• El lenguaje es más fácil de razonar porque no lidias con docenas de casos especiales.
• Puedes extender el lenguaje sin reescribir todo el sistema, porque nuevas características pueden expresarse en términos de las existentes.

Esa consistencia es una de las razones por las que Lisp se convirtió en un terreno de pruebas para ideas en IA simbólica: los investigadores podían probar nuevas representaciones y estructuras de control rápidamente, sin esperar a que un equipo de compilador rediseñara el lenguaje.

Macros: automatización para patrones de código

Las macros son la forma en que Lisp te permite automatizar formas de estructura de código repetitivas, no solo valores repetidos. Donde una función evita repetir cálculos, una macro evita repetir estructuras comunes—como “haz X, pero también regístralo” o “define un mini-lenguaje para reglas”.

El efecto práctico es que Lisp puede crecer nuevas comodidades desde dentro. Muchas herramientas modernas hacen eco de esta idea: sistemas de plantillas, generadores de código y características de metaprogramación, porque sirven al mismo objetivo: experimento más rápido e intención más clara.

Si tienes curiosidad por cómo esta mentalidad influyó en flujos de desarrollo cotidianos, ve a /blog/the-repl-and-fast-feedback-loops.

El REPL y los bucles de retroalimentación rápida

Una gran parte del atractivo de Lisp no fue solo el lenguaje: fue cómo se trabajaba con él. Lisp popularizó el REPL: Read–Eval–Print Loop. En términos cotidianos, es como tener una conversación con el ordenador. Escribes una expresión, el sistema la ejecuta inmediatamente, imprime el resultado y espera tu siguiente entrada.

El flujo de trabajo en lenguaje llano

En lugar de escribir un programa completo, compilarlo, ejecutarlo y luego buscar qué falló, puedes probar ideas paso a paso. Puedes definir una función, probarla con algunos inputs, ajustarla y probar de nuevo—todo en segundos.

Ese ritmo fomenta la experimentación, lo cual importó mucho en la IA temprana donde a menudo no sabías cuál era el enfoque correcto desde el inicio.

Por qué los bucles de retroalimentación cortos cambian los resultados

La retroalimentación rápida convierte “apuestas grandes” en “chequeos pequeños”. Para la investigación, facilita explorar hipótesis e inspeccionar resultados intermedios.

Para la creación de productos, reduce el coste de iteración: puedes validar comportamientos con datos reales rápidamente, notar los casos límite antes y refinar funciones sin esperar largos ciclos de compilación.

Esto es también por qué las herramientas modernas de vibe-coding resultan atractivas: son esencialmente una compresión agresiva del bucle de retroalimentación. Por ejemplo, Koder.ai usa una interfaz de chat (con una arquitectura basada en agentes debajo) para convertir la intención de producto en código web, backend o móvil funcional rápidamente—a menudo haciendo que el bucle “probar → ajustar → probar otra vez” se parezca más a un REPL que a una tubería tradicional.

Equivalentes modernos que ya conoces

La idea del REPL aparece hoy en:

• shells interactivos de Python/Node
• Jupyter y otros notebooks
• consolas de herramientas de desarrollo del navegador
• “live reload” y hot module replacement en apps web

Diferentes herramientas, mismo principio: acortar la distancia entre pensar y ver.

Cuando el desarrollo interactivo ayuda más

Los equipos se benefician más de flujos tipo REPL cuando exploran requisitos inciertos, construyen características con muchos datos, diseñan APIs o depuran lógica compleja. Si el trabajo implica aprendizaje rápido—sobre usuarios, datos o casos límite—la retroalimentación interactiva no es un lujo; es un multiplicador.

Cómo las ideas de Lisp se propagaron por la programación

Lisp no “ganó” convirtiéndose en la sintaxis de todos los días. Ganó sembrando ideas que se volvieron normales en muchos ecosistemas.

Patrones funcionales en código cotidiano

Conceptos que Lisp trataba por defecto—funciones como valores, uso intensivo de operaciones de orden superior y preferencia por componer partes pequeñas—aparecen hoy por doquier. Incluso lenguajes que no se parecen a Lisp fomentan transformaciones con map/filter, hábitos de datos inmutables y pensamiento recursivo (a menudo expresado con iteradores o folds).

El cambio clave es mental: trata las transformaciones de datos como pipelines y el comportamiento como algo que puedes pasar alrededor.

Representaciones simbólicas: de la IA a compiladores y herramientas

Lisp facilitó representar programas como datos. Esa mentalidad aparece hoy en cómo construimos y manipulamos ASTs (árboles de sintaxis abstracta) para compiladores, formateadores, linters y generadores de código. Cuando trabajas con un AST, haces un primo cercano de “código como datos”, aunque las estructuras sean objetos JSON, nodos tipados o grafos de bytecode.

El mismo enfoque simbólico impulsa la automatización práctica: formatos de configuración, sistemas de plantillas y pipelines de construcción dependen de representaciones estructuradas que las herramientas pueden inspeccionar, transformar y validar.

DSLs y extensibilidad sin reescribir todo

Los lenguajes familiares a la familia Lisp (en sentido amplio: Lisps contemporáneos e inspirados en Lisp) siguen influyendo en cómo los equipos diseñan DSLs internas: pequeños mini-lenguajes enfocados para tests, despliegue, procesamiento de datos o UI.

Fuera de Lisp, sistemas de macros, bibliotecas de metaprogramación y frameworks de generación de código buscan el mismo resultado: extender el lenguaje para ajustarlo al problema.

Una conclusión pragmática: las preferencias sintácticas cambian, pero las ideas duraderas—estructura simbólica, funciones componibles y extensibilidad—siguen rindiendo frutos a través de décadas y bases de código.

Trade-offs y conceptos erróneos sobre Lisp

Lisp tiene una reputación que oscila entre “brillante” e “ilegible”, a menudo basada en impresiones de segunda mano más que en la experiencia diaria. La verdad es más ordinaria: Lisp toma decisiones potentes en el contexto adecuado y poco prácticas en otros.

“Demasiados paréntesis” (y la cuestión de la legibilidad)

Para los recién llegados, la sintaxis uniforme de Lisp puede sentirse como ver el “interior” de un programa en lugar de su superficie pulida. Esa incomodidad es real, especialmente si vienes de lenguajes donde la sintaxis separa visualmente las construcciones.

Históricamente, sin embargo, la estructura de Lisp es también la intención: código y datos comparten la misma forma, lo que facilita transformar, generar y analizar programas. Con buen soporte de editor (indentado, navegación estructural), el código Lisp a menudo se lee por su forma más que por contar paréntesis.

Rendimiento: mito, historia y realidad actual

Un estereotipo común es que Lisp es inherentemente lento. Históricamente, algunas implementaciones sí tuvieron dificultades frente a lenguajes de bajo nivel, y las características dinámicas pueden añadir sobrecarga.

Pero no es exacto tratar “Lisp” como un único perfil de rendimiento. Muchas implementaciones de Lisp han soportado compilación, declaraciones de tipo y optimización seria. La forma más útil de plantearlo es: ¿cuánto control necesitas sobre el layout de memoria, latencias previsibles o rendimiento crudo?—y ¿tu implementación de Lisp apunta a esas necesidades?

Ecosistema y contratación: limitaciones prácticas, no fracasos morales

Otra crítica válida es el encaje en el ecosistema. Dependiendo del dialecto y el dominio, librerías, herramientas y pools de talento pueden ser más pequeños que los stacks mainstream. Eso puede importar más que la elegancia del lenguaje si necesitas lanzar rápido con un equipo amplio.

Una conclusión equilibrada

En vez de juzgar Lisp por sus estereotipos, evalúa sus ideas subyacentes independientemente: estructura uniforme, desarrollo interactivo y macros como herramienta para construir abstracciones de dominio. Incluso si nunca despliegas un sistema Lisp, esos conceptos pueden afilar cómo piensas sobre diseño de lenguajes y cómo escribes código en cualquier lenguaje.

Conclusiones prácticas para diseño de lenguajes y codificación diaria

McCarthy no solo nos dejó un lenguaje histórico—nos dejó un conjunto de hábitos que todavía hacen el software más fácil de cambiar, explicar y extender.

6 lecciones que vale la pena copiar

1. Prefiere núcleos simples sobre superficies inteligentes. Un pequeño conjunto de bloques ortogonales es más fácil de aprender y más difícil de romper.

2. Mantén formas de datos uniformes. Cuando muchas cosas comparten la misma representación (como listas/árboles), las herramientas se simplifican: impresoras, depuradores, serializadores y transformadores se pueden reutilizar.

3. Trata los programas como datos (y los datos como programas) cuando convenga. Si puedes inspeccionar y transformar estructuras, puedes construir refactors, migraciones y generadores de código más seguros.

4. Automatiza lo aburrido. La recolección de basura es el ejemplo clásico, pero el punto es más amplio: invierte en automatización que prevenga clases enteras de errores.

5. Optimiza los bucles de retroalimentación. La evaluación interactiva (estilo REPL) fomenta pequeños experimentos, verificación rápida y mejor intuición sobre el comportamiento.

6. Haz que la extensión sea un objetivo de diseño de primera clase. Las macros de Lisp son una respuesta; en otros ecosistemas pueden ser plugins, plantillas, DSLs o transformaciones en tiempo de compilación.

Un pequeño ejercicio (10 minutos)

Antes de elegir una librería o arquitectura, toma una función real—por ejemplo “reglas de descuento” o “enrutamiento de tickets”—y dibújala como árbol. Luego reescribe ese árbol como listas anidadas (o JSON). Pregúntate: ¿cuáles son los nodos, cuáles las hojas y qué transformaciones necesitas?

Llevar ideas de Lisp a cualquier stack

Aunque no uses Lisp, puedes adoptar la mentalidad: construye representaciones estilo AST, usa generación de código para el pegamento repetitivo y estandariza en pipelines orientados a datos (parsear → transformar → evaluar). Muchos equipos obtienen los beneficios simplemente haciendo explícitas las representaciones intermedias.

Si te gusta el principio REPL pero entregas funciones de producto en stacks mainstream, también puedes tomar el espíritu en las herramientas: ciclos de iteración cortos, snapshots/rollback y planificación explícita antes de ejecutar. Koder.ai, por ejemplo, incluye un modo de planificación además de snapshots y rollback para mantener la iteración rápida más segura—un eco operacional del “cambia rápido, pero mantén el control” de Lisp.

La influencia duradera de McCarthy es esta: programar se vuelve más poderoso cuando hacemos programable el razonamiento mismo—y mantenemos el camino de la idea al sistema ejecutable lo más directo posible.