Недавно попалось на глаза одно очень интересное видео с динамическими шкалами по популярности разных языков программирования по годам (вроде как, начиная с 1980х). Удивительно, сколько всего и как много придумало человечество. И как быстро меняются тренды, а еще - сколько всего уникального уходит в тень истории. Вот был такой Лисп. Принято считать, что Лисп - это что-то из учебников по истории программирования. Где-то между перфокартами и первыми компиляторами. Условный артефакт. Язык, которым пользовались бородатые профессора, пока не пришел Python и не навел порядок.
Только вот Python тоже унаследовал из Лиспа некоторую часть. Но не все. Самое радикальное так и не забрал.
Откуда взялся Лисп - и почему именно для ИИ
Джон Маккарти был математиком, который всерьез решил, что машины можно научить думать. Не в переносном смысле - технически. И примерно с середины 1950-х он последовательно это доказывал.
Сам термин "artificial intelligence" появился в заявке на Дартмутский летний семинар - в 1955 году. А уже летом 1956-го встреча в Дартмуте фактически закрепила его как название новой научной области. Тогда Маккарти был одним из организаторов. Конечно же, не как маркетинговый слоган - как название дисциплины, под которую он хотел получить финансирование.
Осенью 1958-го Маккарти пришел в MIT. Вместе с Марвином Мински они запустили AI Project - то, что в хронологии MIT обычно датируется 1959-м. MIT AI Lab как отдельная структура выделилась позже, в 1969-м. И практически сразу Маккарти столкнулся с проблемой, которую современный разработчик понял бы мгновенно - нет подходящего инструмента.
FORTRAN создавался для численных расчетов (буквально, “Formula Translation”) и отлично справлялся с вычислениями по формулам. Но задачи искусственного интеллекта требовали работы с символьной информацией. Например - разбора предложений, доказательства теорем, оперирования логическими правилами вида “если А, то Б”. Теоретически любые структуры можно закодировать числами, но на практике описывать сложные вложенные правила в рамках строго числовой абстракции FORTRAN было крайне неудобно.
Для решения этой проблемы инженеры IBM Герберт Гелернтер и Карл Герберих при участии Маккарти разработали FLPL (Fortran List Processing Language) - набор подпрограмм для работы со списками внутри FORTRAN. FLPL помог запустить один из первых ИИ-проектов (геометрический доказыватель теорем), но выявил фундаментальные ограничения исходного языка. В FORTRAN того времени не было ни рекурсии, которая необходима для обработки вложенных списков, ни удобных условных выражений.
Поняв ограничения этого подхода, Маккарти начал проектировать новый язык с нуля. В 1960 году вышла его статья “Рекурсивные функции символьных выражений и их вычисление на машине”, ставшая одной из фундаментальных работ в истории компьютерных наук.
Что Маккарти придумал - и чего он сам не понял
Здесь есть одна примечательная деталь.
Маккарти взял из лямбда-исчисления Алонзо Черча нотацию LAMBDA для обозначения функций. Это стало основой синтаксиса Лиспа. Но сам Маккарти позже признавался, что в момент создания языка не очень-то разбирался в лямбда-исчислении - взял нотацию, потому что она казалась удобной и пошел дальше. Позже Дэвид Парк заметил, что рекурсивную LABEL-нотацию можно выразить через конструкцию на LAMBDA, аналогичную Y-оператору Черча. Но сама LAMBDA в Лиспе Y-комбинатором не является.
Это, кстати, нормальная история для фундаментальных вещей. Автор интуитивно нащупывает правильное решение, а теоретики потом объясняют, почему оно работает.
Главное, что получилось у Маккарти - это идея eval (сокращение от evaluate - “вычислить”). Функция, которая берет программу на Лиспе и выполняет ее. Сегодня это звучит банально. В 1958-м это была концептуальная бомба - программа стала данными, которые можно передавать, трансформировать и запускать.
Человек, который запустил то, что не должно было работать
Маккарти написал eval как математическую нотацию. Он, судя по всему, не планировал реализовывать ее на реальной машине - по крайней мере, не сразу.
Стив Расселл, молодой программист из его группы, прочитал статью и сказал, что может закодировать eval для IBM 704. Маккарти ответил примерно следующее: "Ты путаешь теорию с практикой. Это нотация для чтения, а не для вычислений."
Расселл все равно это сделал. Руками, в машинном коде IBM 704.
Так в 1960-м появился первый интерпретатор Лиспа. Вот просто потому что один человек решил проверить, работает ли теория.
Работала.
Что Лисп придумал первым - и что потом переизобрели все остальные
Итак.
Сборка мусора. Garbage collection - изобретение Лиспа, буквально. Маккарти разработал алгоритм mark-and-sweep (пометка и очистка), чтобы автоматически освобождать память от недостижимых списков. До этого программисты управляли памятью вручную. Java, Python, Go - все взяли эту идею оттуда.
Код как данные. В Лиспе программа и данные записываются одинаково - вложенными списками, S-выражениями. Функцию можно передать как аргумент, вернуть из другой функции, сгенерировать прямо во время выполнения. Это называется гомоиконичностью и именно на этом держатся макросы Лиспа - механизм, который позволяет писать код, генерирующий код.
Рекурсия как основа вычислений. FORTRAN и ранний Кобол работали с итерациями и GOTO. Маккарти показал, что рекурсивные функции - это самодостаточная вычислительная модель.
Условные выражения. if-then-else в том виде, в каком это существует в любом языке - тоже Лисп. Звучит странно, но до 1958-го условные переходы реализовывались как низкоуровневые инструкции, а не как выражения, возвращающие значение.
REPL. Интерактивный read-eval-print-цикл вырос из ранней Лисп-культуры - именно там сложилась привычка работать с живой средой, где пишешь строку и сразу получаешь результат. Сам термин REPL закрепился позже, в документации 1960-х. Jupyter Notebook, Python shell, Node.js repl - все это наследники той же идеи.
Как Лисп стал промышленным стандартом - и что пошло не так
К началу 1960-х Лисп - основной язык ИИ-исследований в MIT, Стэнфорде, Карнеги-Меллоне. К 1980-м на нем работают крупные прикладные системы.
Проблема обнаружилась не в языке. В железе.
Стандартные машины того времени гоняли Лисп медленно - сборка мусора, динамическая типизация, работа со списками требовали ресурсов, которых не хватало. Решение нашли радикальное. Строить специализированные компьютеры под Лисп.
Символы в памяти размечались тегами на уровне архитектуры. Сборка мусора делалась аппаратно. Компании Symbolics и Lisp Machines Inc. (обе - спиноффы MIT AI Lab) выпускали такие машины с конца 1970-х. Texas Instruments тоже вошла в этот рынок.
Цена вопроса - от 150 000 за рабочую станцию. Покупали лаборатории, крупные корпорации, военные.
Во второй половине 1980-х Unix-станции от Sun и других производителей подорвали рынок специализированного железа: стали дешевле и достаточно быстрыми, чтобы использовать Лисп без отдельного процессора. Специализированное железо потеряло экономический смысл.
Symbolics, кстати, пережила это особенно болезненно. Компания подала на банкротство в 1993-м и фактически ушла с рынка в 1990-х. Зато symbolics.com остался историческим артефактом по другой причине - это первый зарегистрированный домен в зоне .com (аж 15 марта 1985 года).
Почему ИИ ушел на Python
В 1980-х символьный ИИ еще переживал бум - на Лиспе и смежных системах строили экспертные системы. Но после “Зимы искусственного интеллекта” конца 1980-х фокус постепенно сместился к статистическому машинному обучению, а в 2010-х окончательно - к глубоким нейросетям. Лисп оказался в очень неудобном положении.
Увы, новые задачи требовали другого. Перемножать матрицы миллиарды раз - это чуть-чуть не про символы и списки. Это про BLAS, CUDA, числа с плавающей точкой в плотных массивах. Python здесь работает как обертка над C++ и CUDA, и делает это хорошо.
Тут, кстати, важный момент. Собственно, Python, с чего мы и начинали эту историю, унаследовал у Лисп - автоматическую память, функции как значения, интерактивную работу, динамические структуры данных. Но самое радикальное, такого как S-выражения или гомоиконичность - Python не взял. Это другая парадигма, и победила та, под которую оказалось больше денег и вычислительных ресурсов.
Но символьное мышление никуда не делось. Современные агентные системы - это в значительной мере управление символами, правилами, контекстом. LLM генерирует код и вызывает инструменты. Это структурно ближе к тому, что делал Лисп, чем к тому, что делает матричное умножение.
Что живет сегодня
Common Lisp, Scheme и Clojure - три основных живых диалекта.
Common Lisp стандартизирован в 1994-м и с тех пор почти не менялся. Это или минус, или плюс - зависит от задачи. Код, написанный тридцать лет назад, работает сегодня без изменений. Немного языков могут этим похвастаться.
Scheme - академический диалект, намеренно минималистичный. Навсегда связан со знаменитым учебником SICP - "Structure and Interpretation of Computer Programs", вышедшим в MIT в 1984-м. В самом MIT этот курс давно уже не является основным вводным, но учебник до сих пор читают как классику - и не только в университетах.
Clojure появился в 2007-м и работает на JVM. Из всех диалектов - самый близкий к промышленному применению. Команды на Clojure встречаются в финтехе и в backend-разработке, где важна иммутабельность данных и конкурентность.
Ни один из них не входит в топ-10 по числу репозиториев на GitHub. Это понятно. Но разработчики, которые их знают, обычно говорят об этом как о сдвиге в способе думать о программировании - не как о добавлении еще одного инструмента в набор.
И еще момент.
Пока это не массовый тренд, а исследовательская гипотеза. Но есть идея в том, что агентные системы, те, которые планируют, рефлексируют и вызывают инструменты - снова делают привлекательными вещи, которые Лисп умел давно. Живое окружение, код как данные, интроспекцию и изменение программы прямо во время выполнения. LLM подключают к живому REPL, агент пишет код и тут же запускает его в той же среде.
Есть конкретные исследовательские работы на эту тему. Хотя и до промышленного масштаба пока далеко, само собой.
Но вот идея, что архитектура шестидесятилетней давности снова оказывается уместной - это, согласитесь, занятно.
Комментарии (40)
Gutt
13.06.2026 03:21Что значит «LISP … из учебников истории»? А AutoCAD?
forthuse
13.06.2026 03:21А, ещё для Autocad была возможность делать скрипты на Форт - Atlast диалект, на Github, помимо оригинального сайта по описанию Atlast находится и такой архив https://github.com/Fourmilab/ClassWar
imitron
13.06.2026 03:21А в автокаде если я не ошибаюсь основные высокоуровневые возможности лиспа не имплементированы. Там лисп - это просто способ записи кода
Format-X22
13.06.2026 03:21Я писал на Common Lisp под AutoCAD в 2008, это было забавно, но больше как макросы чтобы вместо пяти кнопок нажать одну, которая исполняет лисп-код и вот у меня под мышкой нужный мне тип линий для проектирования газопровода. Думаю там потолще функционал был, но всё же автокад это когда человек проектирует, пусть и в эдакой IDE для проектировщиков.
next_account
13.06.2026 03:21может на AutoLisp? тоже было время мучал его - где то валяется томик Полещука
Скрытый текст
next_account
13.06.2026 03:21скорее всего он хотел показать как работать через консоль - нам в институте показывали это, на очень старом автокаде. там команды отрисовки примитивов, блоков, всего такого. помню что там координаты абсолютные по умолчанию (хотя конечно внутренние переменные перенастраиваются), а относительные через @. ну и консоль понимает автолисп - так что можно этим пользоваться - подставить выражение вместо чисел - типа (+ 100 200) вернет 300.
kmatveev
13.06.2026 03:21Для LLM-ной статьи в целом сойдёт. Остальное придирки.
Маккарти взял из лямбда-исчисления Алонзо Черча нотацию LAMBDA для обозначения функций. Это стало основой синтаксиса Лиспа. Но сам Маккарти позже признавался, что в момент создания языка не очень-то разбирался в лямбда-исчислении - взял нотацию, потому что она казалась удобной и пошел дальше. Позже Дэвид Парк заметил, что рекурсивную LABEL-нотацию можно выразить через конструкцию на LAMBDA, аналогичную Y-оператору Черча. Но сама LAMBDA в Лиспе Y-комбинатором не является.
Lambda сама по себе нигде не является Y-комбинатором, ни в Лиспе, ни в математике. Y-комбинатор составляется из Lambda-выражений, и его смысл в том, чтобы функция вызывала саму себя, не имея имени.
Код как данные. В Лиспе программа и данные записываются одинаково - вложенными списками, S-выражениями. Функцию можно передать как аргумент, вернуть из другой функции, сгенерировать прямо во время выполнения. Это называется гомоиконичностью и именно на этом держатся макросы Лиспа - механизм, который позволяет писать код, генерирующий код.
Не надо смешивать. То, что функцию можно передать как аргумент и вернуть как результат - это одно, в этом случае у функций с данными общим будет только возможность хранения и передачи. Такая возможность сейчас есть много где и не связана с гомоиконичностью никак. А сгенерировать во время выполнения - это eval, это уже мощнее.
Условные выражения. if-then-else в том виде, в каком это существует в любом языке - тоже Лисп. Звучит странно, но до 1958-го условные переходы реализовывались как низкоуровневые инструкции, а не как выражения, возвращающие значение.
if и сейчас не в любом языке является выражением.
redfox0
13.06.2026 03:21if и сейчас не в любом языке является выражением.
Знаю только один такой язык: Rust. Ну ещё с натяжкой конструкция conditional expression в Python.
yursdan
13.06.2026 03:21А как насчёт обилия скобок, делавших код многих (большинства?) программистов трудночитаемым? Разве не причина для более поздних времён, когда ни GC ни прочие накладные расходы уже так сильно не влияли на выбор?
REPL в Лиспе (если обложиться собственными функциями, как и в случае с другими языками) в нишевых задачах конечно хорош, но получается не принципиально лучше REPL в других языках.
punzik
13.06.2026 03:21А как насчёт обилия скобок
Скобки - это наверное лучшее, что есть в лиспе. Трудночитаемость - это миф, да и избыточное количество скобок - тоже (достаточно посмотреть на синтаксис современных языков, типа Rust и C++ - там кроме скобок разного вида ещё и куча закорючек). Этот миф распространяют те, кто никогда на лиспе не писал.
Format-X22
13.06.2026 03:21Тут есть нюансы. Это как развитие математики и системы символьной записи - с развитием и введением новых способ улучшается и восприятие, больше помещается в голове, появляется возможность делать больше открытий и быстрее обучать. Можно посмотреть как раньше некоторые формулы записывались, даже 200 лет назад. Ну и банально десятичная форма записи числа много чего в мир принесла, даже без формул и прочего.
Также и скобки - это хороший базис и, главное, единый. И всё же имея больше символов можно проще описывать то что ты хочешь передать. Та же запись хеш-мап уже скобками не очень будет, более того в современном лиспе таки добавили для этого дополнительную символику. Интерполяция строк, блоки, метки, декораторы - всё это позволяет увеличить ёмкость информации и упрощает оперирование. Не везде это хорошо реализовано, но ёмкость повышается. И пока, на самом деле, ограничение в наборе этих символов - на клавиатуре не так их и много и особо новые не появляются, клавиатуры застряли во времени очень давно. Конечно есть и верхняя грань, после которой уже будет набор иероглифов, но скобки в одном виде слишком малы для записи сложных систем. Кстати, люди, для которых иероглифы являются родным языком, лучше понимают математику и были на эту тему исследования - именно из-за ёмкости информации. Но переизбыток ведёт к другим проблемам, так что важен баланс. Скобки лиспа находятся у другой крайности - слишком мало ёмкости. Потому мир и шагнул дальше в способах описания кода и информации. Лисп сам по себе не плох, общие идеи прекрасны, но увы - внедрения новых символов не произошло и язык остался в скромной нише вдали от мейнстрима.
vybo
13.06.2026 03:21клавиатуре не так их и много и особо новые не появляются, клавиатуры застряли во времени очень давно
Не во времени, а в общем для всех кодировок диапазоне ASCII, это 128 символов, из которых 34 непечатных (пробел, перенос и табуляцию все же есть чем вводить), а остальные 94 размещаются по 2 на 47 клавишах (33 в "буквенных" рядах, 13 в "цифровом" ну и выбивающаяся более длинная кнопка с бекслешем)
Format-X22
13.06.2026 03:21UTF-8 нынче стандарт кодировок и много лет, в принципе клавиатуры уже могут подтягиваться за новыми символами.
imitron
13.06.2026 03:21Давно уже пора сделать программистскую клавиатуру, где кроме фигурных, угловых, квадратных и обычных будет еще 100500 скобок из уникода и заодно набор символов из APL
imitron
13.06.2026 03:21Такая уже есть: https://en.wikipedia.org/wiki/Space-cadet_keyboard - нашел по запросу "APL keyboard". Википедия говорит, можно ввести более 4000 разных символов
punzik
13.06.2026 03:21Интерполяция строк, блоки, метки, декораторы - всё это позволяет увеличить ёмкость информации и упрощает оперирование.
Скобки лиспа находятся у другой крайности - слишком мало ёмкости.
Категорически нет! Всё ровно противоположно. Лисповые скобки дают бесконечную ёмкость, поскольку позволяют выразить любую глубину абстракции единым и понятным способом. Как раз те костыли, в виде декораторов, меток и пр. - это попытка поднять уровень абстракции средствами, которые для этого не годятся.
Кроме того, в лиспе свободно и нативно реализуются все эти декораторы и строковые интерполяции. Но большинство этих вещей там не нужно, потому что есть способы лучше, и выражаются они через скобки.
forthuse
13.06.2026 03:21@" Итого, если в LISP скобка — это базовый эзотерический символ, а в прочих языках соблюдается некий баланс, то в Форте вся эзотерика строится на отсутствии скобок в записи выражений . Мегаследствие: все различия глобальных концептов в программировании определяются числом скобок в языке ! А не всякими там ООП , замыканиями и прочими коротящими мозги штуками ."
punzik
13.06.2026 03:21но получается не принципиально лучше REPL в других языках.
Таки репл в коммонлиспе - это совсем не репл в питоне (и в других языках). Это совершенно разные реплы. Репл в питоне - это интерактивный интерпретатор. Репл в лиспе - это переписывание работающей программы.
imitron
13.06.2026 03:21Как это возможно, если работающий код в данный момент исполняется?
punzik
13.06.2026 03:21Грубо - среда, в которой выполняется программа, имеет REPL. Заходите в него, и на ходу правите код. Или, например, крутится у вас web-сервер. Вдруг один из потоков выбрасывает исключение. Вы можете зайти в REPL, поправить код и продолжить выполнение с того места, где возникла ошибка. В других потоках код тоже исправится. Как-то так (грубо).
kmatveev
13.06.2026 03:21Про разницу между "интерактивным интерпретатором" и "переписывание работающей программы" я оставлю на совести комментатора, который это ляпнул. Но для повышения всеобщего уровня грамотности на ваш вопрос отвечу.
В C определение функции с именем f означает, что компилятор в пространстве кода сформирует код и символ f, который указывает на этот код и значение которого поменять нельзя. А в Scheme объявление (define f (lambda (x) (+ x 2))) означает, что глобальная переменная f имеет значение-функцию. При вызове функции через имя f, например, так (f 3), будет взято текущее значение этой переменной, а именно значение-функция, определённая лямбдой, и выполнена для переданного аргумента. Значение глобальной переменной можно поменять, и f может начать ссылаться на другую функцию. Когда к f обратятся в следующий раз, то там будет новое значение, но если код из f выполнялся на момент изменения, то он продолжит выполнение до выхода из функции.
REPL - это такое особое Lisp-приложение, в котором поток исполнения в бесконечном цикле читает ввод пользователя, парсит его, выполняет eval для динамического выполнения кода и печатает результат. Поэтому хоть в REPL, хоть не в нём можно поменять значение глобальной переменной с одной функции на другую, пропатчив код. Не у всякого рабочего Lisp-приложения это возможно, обычно для этого приложение, помимо основных рабочих потоков, должно специально оставить REPL-поток, через который можно подключиться и это сделать.
saidelman
13.06.2026 03:21Кажется, я пару лет назад где-то в комментариях на хабре читал объяснение подобного же механизма у виртуальной машины Эрланга. Поправьте меня, пожалуйста, если я говорю ерунду: я плохо знаком что с Лиспом, что с Эрлангом. Просто хочу узнать, правильно ли я помню, что там тоже можно “править прод на горячую” :)
gev
13.06.2026 03:21Как раз на днях допилил свой хот релоад для десктопных и мобильных приложений на своем диалекте лиспа
Hemml
13.06.2026 03:21В других языках скобок не сильно меньше, просто они расставлены по-другому. Визуально вид лиспового кода может напугать новичка, конечно, но если рельно начинаешь с ним работать, то сразу понимаешь, насколько это удобно. Любой вызов функции, например, это выражение в скобках, где первое это имя (на самом деле не совсем имя, но для простоты можем считать так) функции и остальные элементы -- ее параметры. Например
(sin x)-- это аналогsin(x)в C или Питоне (кстати, подсчитайте количество скобок там и тут). А вот сложение нескольких чисел:(+ a b c), аналогом в C будетa+b+c. Да, тут на пару скобок меньше. Зато для сложных выражений надо в памяти держать приоритеты операторов или, омг, тоже добавить скобки. А теперь смотрите -- в Лисп иsinи+это одно и то же, просто вызов функции, работа с ними абсолютно одинакова. Если у вас есть список чисел в переменнойxи вы хотите получить их сумму, вы просто пишете:(apply #'+ x)-- подставить список значенийxв функцию+, в C или Питоне для этого придется писать цикл. И вот таких трюков в Лиспе множество, многие из них возможны благодаря "скобочному синтаксису".А теперь о главном, зачем в Лисп скобки. Скобками обозначаются списки, то есть
(+ a b c)это просто список из символа+и символовa,b,c. Его можно сформировать программно и выполнить черезeval, например. То есть код, сама выполняемая программа, может создаваться "на лету", программно, поскольку это просто список из символов, чисел и других списков. И вот эта концепция "код как данные" делает Лисп на две головы выше остальных языков программирования, позволяет (безопасно и удобно) писать само-модифицирующиеся программы, создавать DSL -- специализированные мини-языки для прикладных задач, да и просто многократно сокращает количество кода, который нужно писать руками, ревьюить и поддерживать. При этом большинство Лиспов это компиляторы, то есть вы можете создать код программно, превратить его в машинные инструкции и вызывать его, прямо на лету, во время исполнения программы.Лисп сильно недооценен, сейчас это, по сути, самый развитый язык программирования на планете. Просто порог вхождения высокий и новички его боятся из-за непривычных концепций и синтаксиса.
Axelaredz
13.06.2026 03:21Так как все языки в основе своей используют математические формулы, то можно копнуть ещё глубже аж в 1903 год, когда разработали алгоритм цепи Маркова. Оное больше подходит под язык иИ на базе предсказаний^ ^
forthuse
Такие языки как Lisp, Prolog, Forth, Smalltalk думаю и сейчас, возможно, без афиширования используются в тематике ИИ.
Р.S. А, “проиграли” они историческую гонку в силу разных причин и предположу, что их концептуальная простота оказалась мало востребованной в мире развития алгоритмического мышления с проектированием разного синтаксиса языков и перекладыванием на него оформленных задач решаемых семантикой языка. Выражать разнообразную семантику в привязке к синтаксису оказалось в массе своей проще в “Алгол” языках., а IT “художники” остались не у дел.
forthuse
В рамках Форт (Forth) языка и ИИ, один из проектов в развитии на Github TensorForth https://github.com/chochain/tensorForth (Forth does tensors, in CUDA) - 56 звёзд на текущий момент.
P.S. C Форт такая проблема, что его почти не дают даже в Вузовских программах, не рассматривая школьников (соответственно вокруг его парадигмы не формируется методологический базис) и книги изданные по нему на русском языке в конце 80-х начало 90-х ориентированы на стандарт 83-го года, хотя сейчас в действии ANSI 94-года. Но Форт не забыт и рускоязычными пользователями в действующих форумах, телеграм каналах … и надеюсь увлечёнными “хакерами” :)
forthuse
При запросе на генерацию кода на нём, думаю, и ИИ подтянут свои скилы, если ещё этого нет и Форт (не путать с Фортран языком!) опять займёт подобающее ему место во всевозможных популярных рейтингах языков программирования.
P.S. А, если появятся кремневые Форт-процессоры (контроллеры), непосредственно поддерживающие Форт, то вообще хорошо. :) (GA144 им в пример https://habr.com/ru/search/?q=GA144)
kmatveev
Какой запрос на генерацию Forth-кода, мужик, ты о чём? Весь сгенерированный LLM-код нужно очень внимательно ревьюить, а ревьюить Forth-код - это такая адская боль, нужно его в голове интерпретировать, удерживая в своей памяти содержимое стека.
imitron
Не надо думать о форте так как о нем рассказывают в обзорных статьях про форт для самых маленьких (для того чтобы дать представление о том как он устроен внутри). Ревью современного форт-кода ничуть не сложнее чем ревью кода на любом другом языке.
forthuse
Отчасти это так, но это относится и к коду и на других используемых языках когда нужно удерживать в памяти логику действий с локальными переменными, которые, ккстати, добавили в стандарт и Форт 94-года.
P.S. А, часто Форт код и нет необходимости читать вне контекста его изменения, при этом достаточно проверить вход/выхход отдельного слова в интерактивном режиме.(в этом аспекте у меня никогда не возникало проблем по “корректировке” Форт кода) К любому коду полученному от той же LLM это также применимо.
imitron
Я бы хотел узнать как они работают на низком уровне эти локальные переменные
forthuse
В целом могут быть варианты реализации (касающиеся, к примеру, Форт- систем с нативной генерацией оптимизированного кода для использования регистров процессора/контроллера как SPF4, VFX Forth, iForth …), но один из вариантов - перенос лок. переменных со стека данных на стек возвратов, если для них не добавили ещё стек локальных переменных.
P.S. Чем интересен Вам Форт язык в сравнении с другими конкатенативными (цепочечными) языками https://concatenative.org (как пример Factor язык включающий и функциональную парадигму)
gev
Почитал каменты, и решил что нам нужен транслятор из Lisp в Forth и компилятор в байт-код для своей виртуальной машины стековой ;)