Алан Кей: Да поможет мне небо дать короткий ответ на этот вопрос.
Во второй половине 50-х годов Джон МакКарти все больше стал интересоваться тем, что он называл “Искусственным интеллектом”. Он также много с кем консультировался, что и свело его с ПВО системой SAGE: огромные системы из еще бОльших компьютеров прикрепленных к радарным станциям и друг другу и приводящиеся в действие графическими дисплейными системами при помощи указывающих устройств.
Реакцией Джона было “такое будет в каждом доме Америки”. Он увидел, что подключенные друг к другу компьютеры могут являться “информационной службой общего пользования” (как параллельно с электрическими, водяными, газовыми и другими службами) и что в домах есть средства, которые могут обеспечить различные виды информационных услуг. Кроме того, это заставило его поддержать MIT и не только в разделении времени на пользование большими центральными компьютерами.
Он также понял, что все, что связано с компьютером 50-х — машинный код и новый Fortran — не особо пересекаются с интересами американских людей. Это заставило его написать работу “Programs With Common Sense” (1958 г.) — и предложить, что для интерфейса пользователя был нужен автоматизированный механизм — “Advice Taker” — который мог бы взаимодействовать с пользователями в понятном им режиме, мог бы обучить их, решить проблемы как от своего лица, так и от лица пользователя и так далее (MIT Al Memo 17). Это заставило его задуматься о том, как претворить в жизнь такого “Advice Taker”, основными процессами которого будут логические выводы, в том числе те, которые требуют действий. В то время было не так много жестов в “языке программирования”, так что он решил изобрести язык для функционирования “Advice Taker” (и других типов роботов), позволить символьному вычислению выйти на один уровень с уже существующим численным.
Поскольку Джон был потрясающим математиком и логиком, он также хотел создать “математическую теорию вычислений”, где более точно были бы сформированы старые и новые идеи. В итоге он создал LISP (сокращение от LIST Processing). Я уже где-то писал о его важности. В то время он также размышлял о том, как применить логику, математику и программирование (он понимал, что они тесно связаны между собой) так, чтобы взаимодействовать с роботом в реальности. Был конфликт межу at (робот, филадельфия) и at (робот, нью-йорк), который мог произойти не сразу же, а “через какое-то время”. Для программирования того времени это было проблемно, ведь там переменные были бы переопределены (и иногда даже файлы) — в общем-то, позволяя ЦП компьютера устанавливать “время”.
Этот деструктивный процесс способствует состоянию гонки и делает затруднительным анализ. Джон задумался о модальной логике, но потом осознал, что хранение данных об изменениях и классификация их с учетом “псевдо-времени”, когда утверждался “факт”, может помочь функциональные и логические объяснения и обработку данных.
Он назвал “ситуациями” все “факты”, которые происходили в определенное время — нечто вроде “слоя”, который пересекает мировые линии данных. (МакКарти “Situations, Actions, and Causal Laws” Стэнфорд, 1963, выпущенное после работы Марвина Мински для “Symbolic Information Processing”).
Один из вариантов рассмотрения данной схемы связан с тем, что “логическое время” должно было просто быть включено в моделирования и что при вычислениях “время ЦП” не учитывалось.
Эта идея не умерла, но она не смогла прижиться ни тогда, ни сегодня. Главной задачей было допустить свободный режим работы ЦП и защитить ее семафорами и т.д.
(В данном случае возникла проблема в системе блокировки, но какой бы слабой не была эта идея, она все еще является главной).
Частично или полностью наработки Джона использовались в таких системах как CPL Стрэча, Lucid, Simula и других. Взгляните на TimeWarp Дейва Джефферсона, NetOS Рида, Paxos Лэмпорта, the Croquet и так далее.
Рассмотрим одну из них; в начале 60х Стрэчи понял, что хвостовая рекурсия в Лиспе была все эквивалентна “циклу с единичным одновременным функциональным присваиванием”. И что оно было бы гораздо более точным при объединенном вычислении *следующих* значений переменных. Состояние гонки не представляется возможным, поскольку правая часть присваиваний вычисляется с использованием старых значений переменных, а само присваивание выполняется для одновременного представления новых значений переменных (цикл и присваивание могут быть точными, если сохраняются отдельные “временные зоны” и т.д.)
Более популярной идеей является идея о том, что большие системы данных используют *версии* вместо перезаписывания, а также “атомарные транзакции”, чтобы избежать состояния гонки.
Вернемся к МакКарти и поговорим про объекты. В PARC мы поняли, что было бы очень здорово воплотить в жизнь все возможные “ситуации” и “переменные величины” Джона, даже если данные хранились не так долго.
Это бы, например, позволило “реальным объектам” быть мировыми линиями стабильных состояний и они могли бы функционально перейти к следующему стабильному состоянию. Стрэчи считал, что они будут переходить к новой версии без не входя в состояние гонки.
Это было бы также полезно для множественных режимов, которые мы начали использовать. Вы действительно просто хотите, чтобы режимы были доступны на устойчивых объектах (/связях) и этого можно достичь посредством ограничения режимов на уже вычисленных “ситуативных уровнях”.
PARC также экспериментировал с UNDO и более широкое общество начало обращать внимание на “параллельное возможное обоснование миров”.
Также хотелось, чтобы сам процесс программирования происходил в режиме “данных и версий”, а также чтобы системы могли сами возвращаться к своим старым версиям (включая “величины”, а не просто код). Interlisp, особенно PIE (реализовано в Smalltalk Голдштейн и Бобровым).
Это была дополнительная мотивация для Джона в будущих системах, т.е. делать все относительно мировых линий и “модельного времени”. Недавняя работа Алекса Варта демонстрирует некоторые способы того, какими маломодульными можно создать “Миры”.
Последнее, о чем бы хотелось сказать это “Histories R US”, т.е нам необходимо и рост наших идей со временем и воспоминания, *и* мы также хотим иметь четкое обоснование о том, как появилась каждая делать (а также улучшить систему).
Джон МакКарти показал нам, как сделать это 60 лет назад и описал весь процесс, чтобы каждый смог прочесть и понять.
Итак: и объектно-ориентированное, и функциональное программирование могут взаимозаменять друг друга (и должны!). Нет никаких причин для того, чтобы их менять, как и для того, чтобы создавать “монаду” в функциональном программировании. Мы просто должны осознать, что “компьютеры — это средство моделирования” и придумать, что мы будем моделировать.
В июле я буду рассказывать об этом в Амстердаме (на конференции CurryOn).
Во второй половине 50-х годов Джон МакКарти все больше стал интересоваться тем, что он называл “Искусственным интеллектом”. Он также много с кем консультировался, что и свело его с ПВО системой SAGE: огромные системы из еще бОльших компьютеров прикрепленных к радарным станциям и друг другу и приводящиеся в действие графическими дисплейными системами при помощи указывающих устройств.
Реакцией Джона было “такое будет в каждом доме Америки”. Он увидел, что подключенные друг к другу компьютеры могут являться “информационной службой общего пользования” (как параллельно с электрическими, водяными, газовыми и другими службами) и что в домах есть средства, которые могут обеспечить различные виды информационных услуг. Кроме того, это заставило его поддержать MIT и не только в разделении времени на пользование большими центральными компьютерами.
Он также понял, что все, что связано с компьютером 50-х — машинный код и новый Fortran — не особо пересекаются с интересами американских людей. Это заставило его написать работу “Programs With Common Sense” (1958 г.) — и предложить, что для интерфейса пользователя был нужен автоматизированный механизм — “Advice Taker” — который мог бы взаимодействовать с пользователями в понятном им режиме, мог бы обучить их, решить проблемы как от своего лица, так и от лица пользователя и так далее (MIT Al Memo 17). Это заставило его задуматься о том, как претворить в жизнь такого “Advice Taker”, основными процессами которого будут логические выводы, в том числе те, которые требуют действий. В то время было не так много жестов в “языке программирования”, так что он решил изобрести язык для функционирования “Advice Taker” (и других типов роботов), позволить символьному вычислению выйти на один уровень с уже существующим численным.
Поскольку Джон был потрясающим математиком и логиком, он также хотел создать “математическую теорию вычислений”, где более точно были бы сформированы старые и новые идеи. В итоге он создал LISP (сокращение от LIST Processing). Я уже где-то писал о его важности. В то время он также размышлял о том, как применить логику, математику и программирование (он понимал, что они тесно связаны между собой) так, чтобы взаимодействовать с роботом в реальности. Был конфликт межу at (робот, филадельфия) и at (робот, нью-йорк), который мог произойти не сразу же, а “через какое-то время”. Для программирования того времени это было проблемно, ведь там переменные были бы переопределены (и иногда даже файлы) — в общем-то, позволяя ЦП компьютера устанавливать “время”.
Этот деструктивный процесс способствует состоянию гонки и делает затруднительным анализ. Джон задумался о модальной логике, но потом осознал, что хранение данных об изменениях и классификация их с учетом “псевдо-времени”, когда утверждался “факт”, может помочь функциональные и логические объяснения и обработку данных.
Он назвал “ситуациями” все “факты”, которые происходили в определенное время — нечто вроде “слоя”, который пересекает мировые линии данных. (МакКарти “Situations, Actions, and Causal Laws” Стэнфорд, 1963, выпущенное после работы Марвина Мински для “Symbolic Information Processing”).
Один из вариантов рассмотрения данной схемы связан с тем, что “логическое время” должно было просто быть включено в моделирования и что при вычислениях “время ЦП” не учитывалось.
Эта идея не умерла, но она не смогла прижиться ни тогда, ни сегодня. Главной задачей было допустить свободный режим работы ЦП и защитить ее семафорами и т.д.
(В данном случае возникла проблема в системе блокировки, но какой бы слабой не была эта идея, она все еще является главной).
Частично или полностью наработки Джона использовались в таких системах как CPL Стрэча, Lucid, Simula и других. Взгляните на TimeWarp Дейва Джефферсона, NetOS Рида, Paxos Лэмпорта, the Croquet и так далее.
Рассмотрим одну из них; в начале 60х Стрэчи понял, что хвостовая рекурсия в Лиспе была все эквивалентна “циклу с единичным одновременным функциональным присваиванием”. И что оно было бы гораздо более точным при объединенном вычислении *следующих* значений переменных. Состояние гонки не представляется возможным, поскольку правая часть присваиваний вычисляется с использованием старых значений переменных, а само присваивание выполняется для одновременного представления новых значений переменных (цикл и присваивание могут быть точными, если сохраняются отдельные “временные зоны” и т.д.)
Более популярной идеей является идея о том, что большие системы данных используют *версии* вместо перезаписывания, а также “атомарные транзакции”, чтобы избежать состояния гонки.
Вернемся к МакКарти и поговорим про объекты. В PARC мы поняли, что было бы очень здорово воплотить в жизнь все возможные “ситуации” и “переменные величины” Джона, даже если данные хранились не так долго.
Это бы, например, позволило “реальным объектам” быть мировыми линиями стабильных состояний и они могли бы функционально перейти к следующему стабильному состоянию. Стрэчи считал, что они будут переходить к новой версии без не входя в состояние гонки.
Это было бы также полезно для множественных режимов, которые мы начали использовать. Вы действительно просто хотите, чтобы режимы были доступны на устойчивых объектах (/связях) и этого можно достичь посредством ограничения режимов на уже вычисленных “ситуативных уровнях”.
PARC также экспериментировал с UNDO и более широкое общество начало обращать внимание на “параллельное возможное обоснование миров”.
Также хотелось, чтобы сам процесс программирования происходил в режиме “данных и версий”, а также чтобы системы могли сами возвращаться к своим старым версиям (включая “величины”, а не просто код). Interlisp, особенно PIE (реализовано в Smalltalk Голдштейн и Бобровым).
Это была дополнительная мотивация для Джона в будущих системах, т.е. делать все относительно мировых линий и “модельного времени”. Недавняя работа Алекса Варта демонстрирует некоторые способы того, какими маломодульными можно создать “Миры”.
Последнее, о чем бы хотелось сказать это “Histories R US”, т.е нам необходимо и рост наших идей со временем и воспоминания, *и* мы также хотим иметь четкое обоснование о том, как появилась каждая делать (а также улучшить систему).
Джон МакКарти показал нам, как сделать это 60 лет назад и описал весь процесс, чтобы каждый смог прочесть и понять.
Итак: и объектно-ориентированное, и функциональное программирование могут взаимозаменять друг друга (и должны!). Нет никаких причин для того, чтобы их менять, как и для того, чтобы создавать “монаду” в функциональном программировании. Мы просто должны осознать, что “компьютеры — это средство моделирования” и придумать, что мы будем моделировать.
В июле я буду рассказывать об этом в Амстердаме (на конференции CurryOn).
О школе GoTo
- 17-30 июня, 15-28 июля, 12-25 августа
Летние проектные GoTo школы в Подмосковье. - Группа в ВК
- Подписаться на рассылку