18 дек. 2025 г.·7 мин
Джон Маккарти, Lisp и истоки символического подхода в дизайне ИИ
Как идеи Джона Маккарти — символическое представление знаний, списки, рекурсия и сборщик мусора — повлияли на ИИ и современное программирование.
Как идеи Джона Маккарти — символическое представление знаний, списки, рекурсия и сборщик мусора — повлияли на ИИ и современное программирование.
Это не экскурсия по музею «старого ИИ». Это практический урок истории для тех, кто создаёт софт — программистов, техлидов и продуктовых менеджеров — потому что идеи Джона Маккарти сформировали наше понимание того, для чего нужны языки программирования.
Lisp был не просто новой синтаксической формой. Это была ставка на то, что софт может манипулировать идеями (не только числами), и что архитектурные решения языка могут ускорить исследования, итерации продукта и целые экосистемы инструментов.
Полезный способ читать наследие Маккарти — как вопрос, который остаётся актуальным: насколько прямо мы можем превратить намерение в исполняемую систему — без тонущих в шаблонном коде, трениях и случайной сложности? Этот вопрос отзывается от REPL в Lisp до современных «чат→приложение» рабочих процессов.
Маккарти запомнился не только как один из инициаторов исследований в области ИИ, но и как сторонник конкретного подхода: систем, которые могли манипулировать идеями, а не лишь вычислять ответы. В середине 1950‑х он организовал летний исследовательский проект в Дартмуте (там был предложен термин «искусственный интеллект») и позже работал в MIT и Стэнфорде. Но возможно его самое долговременное наследие — постоянный вопрос: а что если само умозаключение можно выразить программой?
Большинство ранних успехов в вычислениях были числовыми: баллистические таблицы, инженерные симуляции, оптимизация и статистика. Эти задачи удобно ложатся в арифметику.
Маккарти целился в другое. Человеческое рассуждение часто оперирует такими понятиями, как «если», «потому что», «принадлежит», «является видом», или «все вещи, удовлетворяющие этим условиям». Это не воспринимается естественно как числа с плавающей точкой.
Подход Маккарти рассматривал знания как символы (имена, отношения, категории) и мышление как правилообразные преобразования этих символов.
Высокоуровневая иллюстрация: численные подходы отвечают на «сколько?», а символические — на «что это?» и «что следует из того, что мы знаем?».
Если считать, что умозаключение можно сделать программируемым, нужен язык, который естественно представляет выражения вроде правил, логических утверждений и вложенных отношений — и может их обрабатывать.
Lisp был создан именно для этой цели. Вместо того чтобы принуждать идеи в жёсткие заранее заданные структуры данных, Lisp сделал естественным представление кода и знаний в похожей форме. Это был не академический каприз, а практический мост между описанием мысли и выполнением процедуры, что и было целью Маккарти для ИИ.
Когда Маккарти и ранние исследователи по ИИ говорили «символическое», они не имели в виду какую‑то таинственную математику. Символ — это просто значимая метка: имя вроде customer, слово вроде hungry или тег IF/THEN. Символы важны тем, что позволяют программе работать с понятиями (категории, отношения, правила), а не только с сырыми числами.
Проще представить: электронные таблицы хороши, когда мир укладывается в колонки и арифметику. Символические системы хороши, когда в мире правила, категории, исключения и структура.
В многих программах разница между 42 и "age" — не в типе данных, а в том, что значение означает. Символ даёт то, с чем можно сравнивать, хранить и комбинировать без потери смысла.
Это делает естественным представление вроде «Париж — это город» или «если батарея разряжена, найти зарядное устройство».
Чтобы что‑то полезное делать с символами, нужна структура. Lisp популяризовал очень простую структуру: список. Список — это упорядоченная группа элементов, и эти элементы сами могут быть списками. С этой одной идеей можно представлять предложения, формы и древовидные знания.
Вот небольшой концептуальный пример (в Lisp‑подобном стиле):
(sentence (subject robot) (verb needs) (object power))
Читается почти как по‑английски: предложение из подлежащего, сказуемого и дополнения. Благодаря структуре программа может выбрать (subject robot) или заменить (object power) на что‑то другое.
Как только информация хранится в символических структурах, классические задачи ИИ становятся доступными:
Ключевой сдвиг в том, что программа уже не просто вычисляет; она манипулирует значимыми кусками знаний в форме, которую может анализировать и преобразовывать.
Идеи Lisp не остались в академии. Они повлияли на то, как люди строили инструменты и как быстро могли апробировать идеи:
Такие черты дают экосистемы, где эксперименты дешёвы, прототипы быстрее становятся продуктом, а команды гибко реагируют на изменения требований.
Lisp родился из практической задачи: как писать программы, которые могли бы работать с символами так же естественно, как с числами?
Маккарти не пытался создать «лучший калькулятор». Он хотел язык, где выражение вроде (is (parent Alice Bob)) можно было хранить, инспектировать, преобразовывать и рассуждать о нём так же просто, как (+ 2 3).
Приоритетом было сделать представление символической информации простым и удобным. Это привело к фокусу на списках и древовидных структурах, потому что они хорошо соответствуют тому, как люди выражают смысл: предложения, логические правила, вложенные категории и отношения.
Ещё одна цель — держать ядро языка маленьким и согласованным. Когда в языке меньше «особых случаев», меньше надо запоминать правил и больше можно концентрироваться на композиции идей. Lisp сделал ставку на небольшой набор строительных блоков, которые можно комбинировать в большие абстракции.
Ключевая идея: программы и данные могут иметь одинаковую структуру. Проще говоря: если ваши данные — вложенные списки, ваша программа может быть вложенным списком тоже.
Это означает, что вы можете:
Lisp также популяризовал установку: языки не обязаны быть универсальными «под всё». Их можно проектировать вокруг проблемной области — например, рассуждения, поиска и представления знаний — и при этом эти идеи будут влиять на общее программирование на десятилетия.
S-выражения (symbolic expressions) — фирменная идея Lisp: единый, согласованный способ представлять код и данные как вложенные списки.
Внешне S-выражение — просто скобки вокруг элементов: некоторые элементы — атомы (имена и числа), некоторые — списки. Правило «списки внутри списков» — весь смысл.
Поскольку структура единообразна, программы в Lisp строятся из одних и тех же блоков на всех уровнях. Вызов функции, кусок конфигурации и часть кода — всё можно описать списком.
Эта согласованность даёт выгоды:
Даже если вы никогда не пишете на Lisp, важный урок: когда система строится из одной‑двух предсказуемых форм, вы тратите меньше сил на экзотические пограничные случаи.
S-выражения стимулируют композицию: маленькие читабельные части естественно складываются в большие. Когда программа — это «просто вложенные списки», комбинирование идей часто сводится к вложению одного выражения в другое или к сборке списков из переиспользуемых частей.
Это толкает к модульности: пишете маленькие операции, которые делают по одной вещи, а затем складываете их для выражения более сложного намерения.
Очевидный минус — непривычность. Для многих новичков синтаксис с множеством скобок выглядит странно.
Но плюс — предсказуемость: понимая правила вложенности, вы можете надёжно видеть структуру программы — и инструменты тоже. Эта ясность объясняет, почему S-выражения повлияли далеко за пределами Lisp.
Рекурсию проще объяснить на метафоре: уборка беспорядочной комнаты путём разбиения её на «меньшие комнаты». Вы не пытаетесь решить всё сразу. Берёте одну вещь, кладёте на место, повторяете ту же операцию для оставшегося. Шаги просты; сила в их повторении до тех пор, пока не останется ничего.
Lisp опирается на эту идею, потому что многие данные естественно устроены списками: у списка есть «первый элемент» и «остаток». Эта форма идеально подходит для рекурсивного мышления.
Чтобы обработать список, вы берёте первый элемент, затем применяете ту же логику к остальным. Когда список пуст — останавливаетесь; это чистый момент «делать нечего», который делает рекурсию определённой, а не мистической.
Хотите сумму списка чисел.
Всё. Определение похоже на обычную речь, а структура программы отражает идею.
Символический ИИ часто представляет выражения как деревья (оператор с подвыражениями). Рекурсия — естественный способ «ходить» по такому дереву: вычисляете левую часть так же, как правую, и продолжается до простого значения.
Эти паттерны повлияли на функциональные языки: маленькие функции, понятные базовые случаи и трансформации данных, которые легко анализировать. Даже вне Lisp привычка разбивать задачу на «сделай шаг, затем повтори над остатком» даёт чище код и меньше скрытых сайд‑эффектов.
Ранним программистам часто приходилось управлять памятью вручную: выделять, отслеживать владение и не забывать освобождать в нужный момент. Эта работа не только замедляла разработку — она порождала класс ошибок, трудно воспроизводимых и простых для распространения: утечки, которые тихо ухудшают производительность, и висящие указатели, вызывающие крахи спустя долгое время после ошибки.
Маккарти ввёл сборщик мусора для Lisp как способ позволить программистам фокусироваться на смысле, а не на учёте ресурсов.
На высоком уровне GC автоматически находит участки памяти, недоступные из выполняющейся программы — значения, которые никто больше не использует — и освобождает их. Вместо вопросов «освободили ли мы объект ровно один раз?» GC ставит вопрос «доступен ли этот объект?» Если недоступен — он мусор.
Для символических задач Lisp‑программы часто создают много короткоживущих списков, деревьев и промежуточных результатов. Ручное управление памятью превратило бы экспериментирование в постоянную борьбу с уборкой ресурсов.
GC меняет повседневный опыт:
Идея в том, что фича языка может быть умножителем команды: меньше часов на отладку — больше времени на логику.
Выбор Маккарти не остался в Lisp. Многие последующие системы приняли GC (в различных вариациях): Java, C#, Python, рантаймы JavaScript и Go опираются на сборщик мусора, чтобы сделать крупную разработку безопаснее и быстрее — даже при требованиях к производительности.
В Lisp выражение — кусок кода в согласованной форме (часто список). Оценивание — это процесс, в котором решают, что выражение означает и что оно порождает.
Например, когда вы пишете «сложить эти числа» или «вызвать функцию с этими аргументами», интерпретатор следует набору правил, чтобы получить результат. Можно представить его как судью языка: он решает, что делать дальше, в каком порядке и когда остановиться.
Ключевой ход Маккарти — не просто придумать новый синтаксис, а сделать «механизм смысла» компактным и регулярным. Когда правила оценки просты, происходят две вещи:
Эта согласованность сделала Lisp площадкой для идей в символическом ИИ: исследователи могли пробовать новые представления и управляющие структуры быстро, не ожидая переработки компилятора.
Макросы позволяют автоматизировать повторяющиеся формы кода, а не только повторяющиеся значения. Если функция помогает не дублировать вычисления, макрос помогает не дублировать структуры: «сделать X, но ещё и залогировать», «определить мини‑язык для правил» и т.д.
Практический эффект: Lisp может порождать новые удобства изнутри. Многие современные инструменты повторяют эту идею — системы шаблонов, генераторы кода и метапрограммирование — потому что они дают то же преимущество: быструю проверку гипотез и ясность намерений.
Если интересно, как это повлияло на рабочие процессы, см. /blog/the-repl-and-fast-feedback-loops.
Большая часть привлекательности Lisp — не только язык, но и способ работы с ним. Lisp популяризовал REPL: Read–Eval–Print Loop. Проще говоря, это разговор с компьютером: вы вводите выражение, система мгновенно его выполняет, печатает результат и ждёт следующего ввода.
Вместо того чтобы писать всю программу, компилировать, запускать и потом искать ошибку, вы пробуете идеи мелкими шагами. Можно определить функцию, опробовать её на входах, поправить и снова проверить — всё в считанные секунды.
Этот ритм поощряет эксперименты, что было критично для раннего ИИ, где часто не было заранее правильного подхода.
Быстрая обратная связь превращает «большие ставки» в «малые проверки». Для исследований это облегчает проверку гипотез и инспекцию промежуточных результатов.
Для прототипирования продукта это снижает стоимость итераций: вы быстро проверяете поведение на реальных данных, замечаете крайние случаи и улучшаете фичи без долгих сборок.
Это также причина популярности современных инструментов интенсивной разработки. Например, Koder.ai использует чат‑интерфейс (с агентной архитектурой под капотом), чтобы преобразовать намерение продукта в работающий код веба, бэкенда или мобильного приложения быстро — делая цикл «попробуй → поправь → попробуй снова» ближе к опыту REPL, чем к традиционному пайплайну.
Идея REPL встречается сегодня в:
Разные инструменты — тот же принцип: сократить расстояние между мыслью и её результатом.
Команды получают наибольшую пользу от REPL‑подобных потоков, когда исследуют неопределённые требования, строят датасеты, проектируют API или отлаживают сложную логику. Если работа связана с быстрым обучением — о пользователях, данных или крайних случаях — интерактивность не роскошь, а множитель эффективности.
Lisp не «выиграл», став повсеместным синтаксисом. Он выиграл, посеяв идеи, которые стали нормой во многих экосистемах.
Концепции, которые в Lisp были по умолчанию — функции как значения, активное использование высших порядков и предпочтение композиции — теперь повсеместны. Даже в языках, далеких по синтаксису от Lisp, принципы map/filter, иммутабельности и рекурсивного мышления (через итераторы или свёртки) стали обыденностью.
Сдвиг — в мышлении: рассматривайте преобразования данных как конвейеры, а поведение как то, что можно передавать.
Lisp упростил представление программ как данных. Это видно сегодня в работе с AST (абстрактными синтаксическими деревьями) для компиляторов, форматтеров, линтеров и генераторов кода. Когда вы работаете с AST, вы делаете близкое к «код как данные» — даже если структуры представлены JSON, типизированными узлами или графами байт‑кода.
Тот же символический подход лежит в основе практической автоматизации: конфиги, шаблоны и сборки зависят от структурированных представлений, которые инструменты могут инспектировать, преобразовать и проверять.
Современные «семейства» Lisp и инструменты, вдохновлённые Lisp, продолжают влиять на дизайн внутренних DSL — маленьких специализированных языков для тестов, деплоя, обработки данных или UI.
Вне Lisp макрос‑системы, библиотеки метапрограммирования и генераторы кода преследуют ту же цель: расширить язык под задачу.
Практический вывод: синтаксис меняется, но прочные идеи — символическая структура, композиция функций и расширяемость — продолжают приносить дивиденды годами.
У Lisp есть репутация, колеблющаяся между «гениальным» и «нечитаемым», зачастую основанная на вторичных впечатлениях, а не на повседневном опыте. Правда прозаична: Lisp делает выборы, мощные в одних условиях и неудобные в других.
Для новичков единообразный синтаксис Lisp кажется как будто вы видите «внутренности» программы, а не отшлифованную поверхность. Это ощущение реально, особенно если вы привыкли к языкам, где синтаксис визуально разделяет конструкции.
Однако структурность — и есть суть Lisp: код и данные имеют одинаковую форму, что облегчает генерацию, анализ и трансформацию программ. При хорошей поддержке редактора (отступы, навигация по структуре) Lisp-код часто читают по форме, а не по подсчёту скобок.
Распространённый стереотип — Lisp медленный. Исторически некоторые реализации действительно отставали от низкоуровневых языков, а динамические возможности добавляют накладные расходы.
Но неверно считать «Lisp» единым профилем производительности. Многие системы Lisp поддерживают компиляцию, объявления типов и серьёзную оптимизацию. Полезнее спрашивать: сколько контроля вам нужно над размещением памяти, предсказуемой задержкой и сырой пропускной способностью — и целится ли конкретная реализация Lisp на эти нужды?
Ещё одно справедливое замечание — пригодность экосистемы. В зависимости от диалекта Lisp, библиотеки, инструменты и кадры могут быть меньше, чем в мейнстрим‑стэках. Это важнее, чем эстетика языка, если вам нужно быстро выпускать с большой командой.
Вместо того чтобы судить Lisp по стереотипам, оценивайте его идеи отдельно: единообразная структура, интерактивная разработка и макросы как инструмент для создания предметно‑ориентированных абстракций. Даже если вы никогда не будете выпускать продукт на Lisp, эти концепции помогут по‑другому думать о дизайне языков и о написании кода в любом стеке.
Маккарти оставил нам не просто исторический язык — он оставил набор привычек, которые делают софт проще менять, объяснять и расширять.
Предпочитайте простое ядро вместо сложной поверхности. Малая ортогональная база проще в изучении и надёжнее.
Держите представления данных единообразными. Когда многие вещи используют одно представление (как списки/деревья), инструменты проще: принтеры, дебаггеры, сериализаторы и трансформеры можно переиспользовать.
Рассматривайте программы как данные (и данные как программы), когда это помогает. Если вы можете инспектировать и трансформировать структуры, можно строить безопасные рефакторы, миграции и генераторы кода.
Автоматизируйте скучную работу. Сборщик мусора — классический пример, но более широкий смысл: инвестируйте в автоматизацию, которая предотвращает целые классы ошибок.
Оптимизируйте для циклов обратной связи. Интерактивная оценка (REPL‑стиль) поощряет маленькие эксперименты, быструю проверку и лучшее понимание поведения.
Сделайте расширение приоритетом дизайна. Макросы Lisp — один ответ; в других экосистемах это могут быть плагины, шаблоны, DSL или трансформы на этапе компиляции.
Прежде чем выбрать библиотеку или архитектуру, возьмите реальную фичу — скажем, «правила скидок» или «маршрутизация заявок поддержки» — и нарисуйте её как дерево. Затем перепишите это дерево как вложенные списки (или JSON). Спросите: какие узлы, какие листья и какие преобразования нужны?
Даже без Lisp вы можете перенять мышление: строить представления вроде AST, генерировать код для однообразных связок и стандартизировать конвейеры данных (парсинг → преобразование → оценка). Многие команды получают преимущества просто явно выделяя промежуточные представления.
Если вам нравится идея REPL, но вы разворачиваете продукт в мейнстрим‑стеке, можно позаимствовать дух инструментов: плотные итерации, снимки и откаты. Koder.ai, например, включает режим планирования, снапшоты и откат, чтобы сделать быструю итерацию безопаснее — операционная отсылка к принципу Lisp «меняй быстро, но с контролем».
Влияние Маккарти в том, что программирование становится мощнее, когда мы делаем само умозаключение программируемым и сохраняем путь от идеи до исполняемой системы как можно короче.
Символическое мышление представляет понятия и отношения напрямую (например, «customer», «is-a», «depends-on», «if…then…»), а затем применяет к этим представлениям правила и преобразования.
Это особенно полезно, когда задача полна структуры, исключений и смысла (движки правил, планирование, компиляторы, конфигурации, логика рабочих процессов), а не просто арифметики.
Маккарти отстаивал идею, что умозаключение можно выражать программами, а не только вычислениями.
Эта точка зрения повлияла на:
Списки — минимальный и гибкий способ представить «вещи, состоящие из частей». Поскольку элементы списка сами могут быть списками, вы естественно получаете деревьевидные структуры.
Это облегчает:
S-выражения дают одну единообразную форму для кода и данных: вложенные списки.
Эта единообразность упрощает систему, потому что:
Макрос автоматизирует повторяющуюся структуру кода, а не просто повторяющиеся вычисления.
Макросы полезны, когда нужно:
Если вам нужна только повторяемая логика, обычно достаточно функции.
Сборщик мусора (GC) автоматически возвращает память, которая больше недоступна из работающей программы, что уменьшает целые классы ошибок (висячие указатели, двойное освобождение).
Это особенно важно, когда программа часто создаёт короткоживущие структуры (списки/деревья/AST): можно свободно прототипировать и рефакторить, не продумывая заранее схему владения памятью.
REPL сокращает цикл «подумай → попробуй → посмотри». Вы определяете функцию, запускаете её, корректируете и снова запускаете — всё в секунды.
Чтобы перенести этот эффект в не‑Lisp-стек:
Связанный материал: /blog/the-repl-and-fast-feedback-loops
Идеи Lisp проникли в повседневное программирование через:
map/filter, композиция)Даже если вы не используете Lisp напрямую, многие привычки из него вы встречаете ежедневно.
Реальные компромиссы:
Практический подход — оценивать идеи и соответствие задачам, а не полагаться на репутацию.
Попробуйте простое упражнение (10 минут):
Это часто показывает, где «код как данные», движки правил или конфиги‑DSL упростят систему.