А как были устроены Lisp машины и операционные системы к ним? Процессор выполнял лисп? Там были файлы? Конфигурация была тоже лиспом и протоколы были лисповыми списками или как?
Thought for 35s
Lisp-машины (Lisp machines) — это специализированные компьютеры 1970–1980-х годов (Symbolics 3600, TI Explorer, LMI Lambda, MIT CADR и др.), созданные именно для эффективного выполнения программ на Lisp. Они не были «обычными» ПК с Lisp как надстройкой — вся архитектура была заточена под особенности языка (списки, динамическая типизация, рекурсия, сборка мусора).
en.wikipedia.org
Процессор: выполнял ли он Lisp «напрямую»?Нет, процессор не выполнял сырые S-выражения (как интерпретатор). Но он был максимально близок к этому:
- Это был стековый процессор (stack machine) с инструкциями, специально оптимизированными под скомпилированный Lisp.
- Основной «движок» — микрокод (microcode). Процессор в hardware выполнял микроинструкции, которые реализовывали примитивы Lisp: car/cdr, вызов функций (иногда за 20 тактов!), проверку типов, bounds checking и даже подсказки для сборки мусора.
- Tagged architecture: каждое слово памяти (обычно 36–40 бит) имело теги (тип данных: integer, float, list, symbol и т.д.). Типы проверялись аппаратно, параллельно с арифметикой — это делало динамическую типизацию Lisp почти бесплатной.
- Lisp-код компилировался в «машинный код» этой архитектуры (macrocode), а микрокод его интерпретировал/ускорял. Пример из CADR: процессор берёт макроинструкцию из памяти → запускает соответствующую микропрограмму → возвращается.
В итоге процессор «говорил на Lisp» на уровне железа лучше, чем любой обычный CPU того времени.
en.wikipedia.org
Операционная системаСамая известная — Genera от Symbolics (ранее называлась Symbolics Lisp OS или ZetaLisp-based).
Она была полностью написана на Lisp (ZetaLisp → Symbolics Common Lisp + Flavors/CLOS для ООП).
Ядро, драйверы устройств, планировщик процессов, сборщик мусора, оконная система, даже низкоуровневые вещи — всё Lisp-код, всё в едином адресном пространстве.
Аналогично у TI и LMI. Никакого отдельного «C-ядра» или Unix-подобного слоя — вся ОС это один большой Lisp-образ («world»).Файлы: да, были, и довольно необычные
- Основной файловый система — Lisp Machine File System (LMFS). Иерархическая, оптимизирована под кучу маленьких файлов (идеально для Lisp-пакетов).
- Плюс FEP File System (Front End Processor) для больших файлов.
- Главная фишка — версионирование: при каждом сохранении файла автоматически сохраняется старая версия (как в VMS). Можно откатиться в один клик.
- Файлы хранятся на локальном диске, но система легко монтировала NFS, FTP, Chaosnet-файловые серверы и т.д.
- Кроме обычных файлов существовали «worlds» — снимки всей памяти Lisp-машины (весь код + данные + состояние). Это как «сохранить весь компьютер» и загрузить за секунды.
Так что да, файлы были, но они жили внутри Lisp-мира, а не как в Unix.
en.wikipedia.org
КонфигурацияВсё было Lisp-кодом.
Нет отдельных .conf, ini или реестра. Конфигурация машины, сети, устройств, приложений — это просто Lisp-выражения, которые загружались при старте или менялись на лету.
Хочешь поменять поведение системы? Переопредели функцию в рантайме прямо в слушателе Lisp — и всё.
Система даже позволяла инспектировать и править свой собственный код в реальном времени (знаменитая «live hacking»).Протоколы и сетевые данные
- Основной протокол — Chaosnet (собственная разработка MIT/Symbolics). Позже добавили полный TCP/IP.
- Весь сетевой стек (от пакетов до приложений) написан на Lisp.
- Форматы данных в пакетах следовали стандартам Lisp-машины (tagged words, Lisp-friendly битовые поля). Высокоуровневые протоколы (file access, mail, eval-server, name service) работали напрямую с Lisp-объектами и списками.
- Например, протокол FILE позволял Lisp-машине открывать файлы на удалённом сервере как обычные потоки Lisp.
- Внутренне данные часто передавались как структурированные Lisp-списки или объекты (сериализованные, конечно, но семантически «Lisp-native»).
По сути, протоколы были «Lispовыми» не в смысле «сырые списки по проводу», а в том, что весь код и структура данных были написаны и хранились как Lisp-объекты. Никакого отдельного «JSON/XML-парсера» — всё родное.Итог в одной фразеLisp-машина — это не «компьютер + Lisp», а компьютер, который внутри себя был одним большим живым Lisp-миром. Процессор ускорял Lisp-примитивы, ОС и всё остальное были написаны на нём же, файлы и конфигурация — это Lisp-объекты, а протоколы — тоже часть этого мира. Поэтому разработчики чувствовали себя богами: можно было менять буквально всё на лету без перезагрузки.
Если хочешь поглубже — могу рассказать про конкретную модель (например, Symbolics 3600 или Ivory), про то, как выглядело программирование в Genera или даже про современные эмуляторы (LM-3, Open Genera).
Расскажи про Genera подробнее
Современные эмуляторы Lisp-машин
Они ещё интересны как параллельная ветвь эволюции или компьютеры отчасти из другого мира...
Searching the web
41 results
Да, Lisp-машины действительно ощущаются как параллельная ветвь эволюции компьютеров — или даже как артефакты из «другого мира», где развитие пошло не по пути фон-Неймана + Unix/C, а по пути символьных вычислений, живой среды и единого Lisp-мира. Это не просто железо с Lisp-компилятором, а целая альтернативная философия вычислений, которая расцвела в 1980-е, но потом почти исчезла.Почему они кажутся «из другого мира»?
- Всё — один живой объект. В обычном компьютере есть жёсткая граница: ОС (на C/ассемблере), приложения, файлы, память, сеть. На Lisp-машине (особенно Symbolics Genera) — единое адресное пространство, где код, данные, состояние системы, окна, даже сам процессор (через микрокод) — это всё Lisp-объекты. Ты можешь инспектировать и менять любой кусок системы прямо во время работы, без перекомпиляции и перезагрузки. Это как если бы твой компьютер был одним большим REPL, который никогда не «умирает».
- Инкрементальная разработка как норма. Сегодня мы гордимся hot-reload в некоторых фреймворках. Там это было базой: пишешь код → сразу видишь эффект → правишь на лету → сохраняешь в «world» (снимок всей машины). Сессии длились днями и неделями.
- Tagged architecture и hardware-поддержка Lisp-примитивов. Обычные CPU тратят циклы на проверки типов. Здесь типы (integer, cons, symbol и т.д.) проверялись аппаратно, параллельно с операцией. Сборка мусора была эффективной благодаря железу. Это делало динамическую типизацию почти бесплатной — противоположность статической типизации в C.
- Файловая система и конфигурация — не плоские тексты, а версиированные объекты с историей. Команды — не строки shell, а Lisp-выражения или презентационные UI (Dynamic Windows в Genera — предтеча современных GUI с мышкой и контекстными меню).
- Сеть и протоколы — тоже «лисповые»: Chaosnet позволял передавать объекты почти прозрачно.
Это был мир, где компьютер — не инструмент для запуска программ, а расширение ума программиста, как у Smalltalk, но ещё глубже и мощнее.Почему эта ветвь почти вымерла?К середине 1980-х Lisp-машины были самыми крутыми рабочими станциями для AI: Symbolics 3600, TI Explorer, LMI Lambda. Они превосходили PDP-10 и ранние мини-компьютеры по скорости Lisp-кода и удобству.Но потом:
- AI winter (зима ИИ) в конце 80-х — финансирование symbolic AI резко упало, а Lisp-машины ассоциировались именно с ним.
- Восход RISC-станций (Sun, HP, DEC) на Unix + дешёвые компиляторы Lisp (Lucid, Franz). Вдруг обычное железо стало быстрее и в разы дешевле.
- Микрокомпьютерная революция — PC и рабочие станции массового рынка победили дорогие специализированные машины (Lisp-машины стоили сотни тысяч долларов).
- Проблемы модели: единое пространство — уязвимо для ошибок (нет изоляции процессов, слабая безопасность). Трудно «поставлять» готовый продукт (каждая машина — уникальный «живой» мир). Нет чёткого разделения «разработка / продакшн».
В итоге к началу 90-х большинство компаний закрылись или перешли на софт. Symbolics продержалась дольше всех, но тоже ушла в нишу (Open Genera до сих пор существует как эмулятор).
en.wikipedia.org
Что они оставили после себя?Много идей «перетекло» в mainstream, хоть и в ослабленном виде:
- Garbage collection (теперь в Java, Python, Go и т.д.).
- Интерактивные среды разработки (IDEs с live coding — от Smalltalk/Lisp к Jupyter, REPL в современных языках).
- Современные GUI и оконные системы (Genera повлияла на ранние Macintosh и Windows).
- Object-oriented programming в полной мере (Flavors → CLOS).
- Идея «программа как данные» — макросы, метапрограммирование.
Сегодня Lisp-машины вдохновляют на размышления: а что если бы аппаратная оптимизация под высокоуровневый язык победила? Или если бы вместо C/Unix мы развивали системы «всё в одном языке»?Некоторые говорят, что современные GPU/TPU — это новые «Lisp-машины» для нейросетей: специализированное железо под определённую парадигму. Другие мечтают о возрождении: с нынешними объёмами памяти и мощностью можно построить «Lisp-машину» на обычном железе или даже на RISC-V с кастомным микрокодом. Есть эксперименты (эмуляторы вроде LM-3, Open Genera, проекты на Raspberry Pi), но пока это больше для энтузиастов.В каком-то смысле Lisp-машины — это как древние динозавры, которые были идеально адаптированы к своей нише (symbolic AI + хакерская культура MIT), но не пережили смену климата (массовый рынок + statistical AI + Unix/C). Они показывают, что компьютеры могли эволюционировать совсем иначе: не как набор слоёв абстракций, а как единая, живая, homoiconic среда.Если хочешь, могу углубиться:
- как именно выглядела повседневная работа в Genera (скриншоты или описания),
- сравнение с Smalltalk-машинами (Xerox Alto/Dorado),
- или современные попытки возродить идею (Mezzano OS на Lisp, или проекты «Lisp machine on modern hardware»).
Это действительно одна из самых красивых «что если» в истории вычислительной техники.
Расскажи про повседневную работу в Genera
Сравни с Smalltalk-машинами Xerox
Расскажи про повседневную работу в Genera
Searching the web
42 results
Повседневная работа в Genera (операционной системе Symbolics Lisp Machine) сильно отличалась от всего, что мы привыкли видеть в Unix, Windows или даже современных IDE. Это был не «компьютер с программами», а одна большая живая Lisp-среда, где ты постоянно находился внутри REPL-подобного мира. Многие, кто работал на ней в 1980–1990-е, вспоминают это как «машину, которая была на 20–25 лет впереди своего времени» — настолько seamless и интерактивной была разработка.Как начинался день
- Ты включал машину (или «cold boot» — загрузка «world» — полного снимка памяти). Загрузка занимала секунды-минуты, потому что весь образ уже содержал ОС, компилятор, редактор, отладчик и твои предыдущие изменения.
- Экран сразу показывал Dynamic Lisp Listener — основной «терминал». Это не просто shell, а полноценный Command Processor (CP): ты вводил команды вроде Show Directory, Edit File, Compile System или прямо Lisp-формы (defun ...).
Внизу экрана всегда была status line (дата, время, пользователь, текущий пакет Lisp, состояние процесса). Под ней — две строки mouse documentation: они динамически подсказывали, что сделает каждый клик мыши (левая, средняя, правая кнопки + комбинации). Это было очень удобно: Genera активно использовала mouse chording (нажатие нескольких кнопок одновременно).Основные «активности» (activities) и как ты между ними перемещалсяВ Genera всё — это activities (коллекции окон и процессов). Ты мог иметь одновременно открытыми:
- Zmacs — мощный Emacs-подобный редактор (SELECT E). Экран делился на основной буфер и минибуфер. Ты редактировал код, сразу компилировал отдельные функции (c-sh-C), запускал тесты. Поддержка версионирования файлов была встроенной.
- Zmail — почтовый клиент (SELECT M). Полноценный, с summary window, где сообщения были кликабельными объектами.
- Document Examiner — гипертекстовая система документации (SELECT D). Ты мог искать по символам, функциям, и она показывала не просто текст, а живые презентации.
- Dired — редактор директорий (аналог ls + rm в одном окне, но с мышкой).
- Lisp Listener — для экспериментов и команд.
- Графические приложения, инспектор объектов, debugger и т.д.
Переключение — мгновенное: SELECT + буква (L — Listener, E — Editor и т.д.) или через System Menu (Shift + правая кнопка мыши). Никакого «закрыть одну программу, открыть другую» — все процессы работали параллельно, делили данные в едином адресном пространстве. Ты мог редактировать код, пока в фоне компилировалась система или шёл расчёт.Dynamic Windows — сердце интерфейсаС Genera 7 (1986) появилась Dynamic Windows — presentation-based UI. Это революция:
- Всё, что выводилось на экран (файлы, числа, списки, объекты), запоминалось как typed presentations (с типом данных).
- Ты мог кликнуть мышкой на любой вывод (даже прокрутив историю назад) и выбрать контекстное действие: «Inspect this object», «Edit this file», «Send this as mail» и т.д. Система сама предлагала релевантные команды на основе типа.
- Окна имели историю вывода: можно было скроллить в прошлое, и старые объекты оставались кликабельными.
- Command Processor понимал как текст, так и клики: команды имели typed parameters, автодополнение (completion), history.
Это делало интерфейс невероятно fluid — ближе к современным GUI с drag-and-drop и контекстными меню, но на 10–15 лет раньше.Типичный цикл разработки (edit-compile-debug)Это было самое сильное место Genera — инкрементальная разработка на стероидах:
- Пишешь/править код в Zmacs.
- Выделяешь defun и компилируешь его мгновенно (не всю программу).
- Запускаешь функцию прямо из Listener или из редактора.
- Если ошибка — автоматически входишь в Debugger. Он показывал стек, переменные, позволял инспектировать объекты, менять значения на лету, продолжать выполнение или возвращаться назад.
- Исправляешь прямо в debugger’е или редакторе — и продолжаешь без перезапуска.
Многие говорили: «edit-compile-debug cycle происходит так быстро, что ты практически делаешь всё одновременно». Никаких долгих rebuild’ов, никаких «перезапустить приложение».Другие повседневные задачи
- Файлы и версии: LMFS автоматически сохраняла версии файлов (.1, .2 и т.д.). Можно было легко откатиться.
- Системы: Код организовывался в «systems» — декларативные описания, которые компилировались/загружались целиком (Make System).
- Инспектор и Inspector: Можно было осмотреть любой объект в памяти (структуры, closures, окна системы).
- Сеть: Chaosnet или TCP/IP — файлы с удалённых машин открывались прозрачно.
- Графика и мультимедиа: Поддержка высококачественной графики, даже анимации и звука (на поздних моделях).
Сессии часто длились днями: ты не выключал машину, а просто «suspend» задачи или сохранял world.Как это ощущалось эмоциональноЛюди, работавшие на Symbolics, описывают это как «магию» или «расширение ума». Ты чувствовал себя внутри компьютера, а не снаружи. Ошибка не убивала процесс — ты мог её починить и продолжить. Всё было связано: кликнул на символ → перешёл в документацию → в исходник → в debugger.Конечно, были минусы: единое пространство делало систему уязвимой к багам (одна ошибка могла «убить» весь world), машины были дорогими, и к 1990-м обычные Unix-станции догнали и перегнали по цене/производительности.Сегодня это можно попробовать в эмуляторах (Open Genera, LM-3) или на старом железе — и многие разработчики, попробовав, говорят: «Ничего подобного по удобству интерактивности до сих пор нет в mainstream».Если хочешь, могу рассказать подробнее про конкретный инструмент (Zmacs, Debugger, Dynamic Windows) или сравнить с современными IDE вроде Emacs + SLIME / IntelliJ. Или про то, как выглядел типичный рабочий стол на скриншотах.
Подробнее о Dynamic Windows
Сравнение с Smalltalk-машинами
Сравнение с Smalltalk-машинами
Searching the web
31 results
Lisp-машины (прежде всего Symbolics Genera) и Smalltalk-машины (Xerox Alto, Dorado, Dolphin, Daybreak и т.д.) — это две самые яркие параллельные ветви «живых» вычислительных сред 1970–1980-х. Они возникли почти одновременно в среде исследовательских лабораторий (MIT AI Lab для Lisp, Xerox PARC для Smalltalk), разделяют множество идей, но сильно отличаются в философии, архитектуре и ощущениях от работы. Оба подхода можно назвать «компьютерами из другого мира» — единая среда, где код и данные не разделены, а разработка инкрементальна и интерактивна.Общие черты (почему они так похожи)
- Image-based система: весь мир компьютера — один большой «образ» (image/world), который загружается целиком. Ты не запускаешь «приложения» — ты живёшь внутри единого адресного пространства, где всё (код, данные, окна, даже ОС) доступно для инспекции и изменения на лету.
- Live coding / hot reload: изменения кода применяются мгновенно, без перезагрузки. Можно править работающую программу, продолжать выполнение после ошибки, инспектировать любой объект.
- Мощный интерактивный debugger и inspector: ошибка не убивает сессию — ты входишь в отладчик, смотришь стек, меняешь значения переменных и продолжаешь.
- Графический интерфейс с мышкой: высококачественные bitmap-дисплеи, окна, меню. Оба повлияли на современные GUI (Macintosh вдохновлялся Smalltalk, Dynamic Windows в Genera — один из самых продвинутых presentation-based UI).
- Дорогое специализированное железо: микрокод, tagged architecture или byte-code интерпретация для ускорения высокоуровневого языка. Оба были дорогими рабочими станциями.
- Философия: компьютер как «расширение ума», а не как набор инструментов. Всё унифицировано: в Lisp — homoiconicity (код = данные в виде S-выражений), в Smalltalk — «всё есть объект» (включая классы и саму среду).
- Судьба: обе ветви почти вымерли из-за AI winter, подъёма Unix/RISC-станций и «worse is better» (простота и переносимость победили глубину и элегантность).
Ключевые различияЯзык и парадигма:
- Lisp-машина (Genera): основана на Lisp (ZetaLisp → Symbolics Common Lisp + Flavors/CLOS). Всё строится вокруг списков, функций, макросов и символов. Макросы позволяют радикально расширять язык. Объектная ориентация добавлена позже (Flavors → CLOS).
- Smalltalk-машина: чистый объектно-ориентированный язык. «Всё есть объект», взаимодействие только через отправку сообщений (message passing). Нет макросов в классическом смысле — вместо них reflection и метаклассы. Синтаксис минималистичный (keyword messages вроде object do: something).
Архитектура железа:
- Lisp-машины (Symbolics 3600, TI Explorer, LMI Lambda): специализированные стековые процессоры с tagged architecture (типы данных в hardware), микрокод напрямую ускоряет car/cdr, вызовы функций, GC hints. Очень эффективны для symbolic computation и AI.
- Smalltalk-машины (Xerox Alto → Dorado): микро-кодируемые машины (Alto был bitmap-ориентирован, Dorado — быстрее, с byte-code интерпретацией). Не такие глубоко оптимизированы под язык, как Symbolics; иногда использовали одно и то же железо для Interlisp и Smalltalk. Alto был медленнее, Dorado — мощнее, но всё равно уступал Symbolics по скорости Lisp-кода.
Интерфейс и повседневная работа:
- Genera (Lisp): Dynamic Windows + Command Processor. Всё — typed presentations (клик на объекте предлагает релевантные действия). Многооконность, mouse chording, Zmacs (Emacs-like редактор), Lisp Listener. Очень мощный для текстовой/символьной работы, гипертекстовая документация (Document Examiner). Ощущение — мощный REPL + IDE в одном.
- Smalltalk: Morphic или ранние UI на BitBlt. Browser-based среда: Class Browser, System Browser, Workspace, Inspector, Debugger. Ты перемещаешься по классам и методам как по живому графу объектов. Более визуально-ориентированный, «всё можно потрогать мышкой». Изменение класса сразу влияет на все экземпляры. Ощущение — как живой мир объектов, где даже интерфейс можно переписывать на лету.
Организация кода и разработка:
- Lisp: код в файлах (с версионированием в LMFS), организован в Systems (Make System для компиляции). Макросы и метапрограммирование позволяют bottom-up дизайн.
- Smalltalk: код живёт внутри image как объекты-классы. Нет традиционных файлов — изменения сразу в образе (позже появились parcel/export системы вроде Envy для командной работы). Более seamless для рефакторинга, но сложнее делиться кодом между разными images.
Производительность и ограничения:
- Lisp-машины часто быстрее для тяжёлых symbolic задач (AI, экспертные системы).
- Smalltalk-машины (особенно ранние Alto) иногда описывали как «majestic to glacial», но Dorado был приличным. Smalltalk больше фокусировался на GUI и образовательных/симуляционных приложениях.
Культура и применение:
- Lisp-машины: MIT AI Lab → коммерческие продукты для AI, CAD, graphics/animation (много ранней компьютерной графики на TV делали на Symbolics).
- Smalltalk: Xerox PARC → исследования персональных компьютеров, OOP, GUI (влияние на Macintosh). Больше образовательный и прототипный акцент.
Что осталось в современном миреОба подхода подарили нам:
- Garbage collection, live environments, powerful IDEs (от Eclipse/IntelliJ до Jupyter).
- Reflection, метапрограммирование, dynamic typing.
- Идею homoiconic / uniform модели (в Lisp — S-expr, в Smalltalk — объекты).
Сегодня можно попробовать оба в эмуляторах:
- Lisp: Open Genera, LM-3.
- Smalltalk: Squeak, Pharo, Cuis (они сохранили дух image-based среды).
В итоге Lisp-машины были «глубже» в symbolic power и hardware optimization, а Smalltalk — «чище» и радикальнее в объектной унификации и визуальности. Многие считают их двумя сторонами одной медали: «Lisp — code as data», «Smalltalk — everything as object». Вместе они показывают, насколько богаче могла быть эволюция компьютеров, если бы не победила Unix/C-модель.Если хочешь углубиться в конкретный аспект (например, как выглядел браузер в Smalltalk vs Zmacs в Genera, или сравнение debugger’ов), или посмотреть на скриншоты/эмуляцию — скажи!
