Оригинал статьи: http://acmqueue.com/modules.php?name=Content&pa=showpage&pid=273
Вступление[]
Если вы хотите побольше узнать об истории персональных вычислений и языков программирования, почему бы не обратиться к одному из выдающихся пионеров этой области? Например к Алану Кэю (Alan Kay), получившему в 2003-ем году Премию Тьюринга за руководство командой разработавшей Smalltalk, а также за фундаментальный вклад в развитие области персональных вычислений.
Кэй был одним из основателей Xerox Palo Alto Research Center (PARC), где он руководил одной из нескольких групп, которые совместно разрабатывали современные рабочие станции (предшественники Macintosh), Smalltalk, интерфейс с перекрывающимися окнами, настольные издательские средства, Ethernet, лазерную печать и клиент-серверные сети.
До поступления в PARC, Кэй получил степень доктора наук в 1969г. в University of Utah, где он спроектировал графический объектно-ориентированный компьютер и являлся членом комманды, разработавшей пионерскую работу по 3D-графике для Advanced Research Projects Agency (ARPA). Кэй также принимал участие в первоначальном проектировании ARPANet, который позже стал Интернетом. Он имеет степени по математике и молекулярной биологии University of Colorado. После ухода из Xerox PARC Кэй стал главным руководителем исследовательских работ Atari (Fellow of Apple Computer) и вице-президентом по исследованиям и разработке в The Walt Disney Company.
Сейчас он является Senior Fellow в Hewlett-Packard Labs и президентом Viewpoints Research Institute, некоммерческой организации, ставящей цели изменить методы обучения детей на примере собственной школы, использующей медиа-средства для обучения математике и другим наукам. Школа планирует использовать Squeak в качестве медиа-платформы, и обещает быть высоко интерактивной и творческой. Основные интересы Кэя по обучению детей служили катализаторами многих его идей на протяжении нескольких лет.
В дополнение к Премии Тьюринга, Кэй недавно получил Draper Prize в National Academy of Engineering и Kyoto Prize в Advanced Technology, вручаемый каждые четыре года организацией Inamori Foundation.
Сопровождает наш экскурс в историю персональных вычислений с Кэем -- Стюард Фельдман (Stuart Feldman) из IBM Research, в которой он является вице-президентом и внештатным технологом области трансформации бизнеса. С момента начала работы в IBM, Фельдман успел поработать вице-президентом по Интернет-технологиям и был главой отдела компьютерной науки и разработок.
Фельдман также проработал 11 лет в Bellcore, где он занимал несколько должностей по управлению разработками программного обеспечения и вычислительных систем. Также он работал 10 лет в Bell Labs, где был исследователем в сфере компьютерных наук. Фельдман был членом первоначальной комманды разработчиков Unix. Он наиболее известен как создатель Make (системы управления конфигурациями) и как автор первого компилятора Fortran-77. Также он имеет степень доктора наук прикладной математики в Massachusetts Institute of Technology и является членом Queue Advisory Board.
Smalltalk[]
STUART FELDMAN (SF)Одна из тем, которая регулярно поднимается молодыми людьми на нашем Queue editorial board), это история языков программирования. На сайте 'Queue board чётко просматривается разделение аудитории, и участники в возрастном диапазоне 20-30 лет действительно путаются в вопросе, откуда же на самом деле пришли языки программирования. По моим наблюдениям, каждое десятилетие появляется один большой и один маленький языки. По видимому это язык, который покрывает все текущие потребности. Smalltalk - это одно из таких событий, которые происходят раз в пять или десять лет.
ALAN KAY (AK) В конце 1960-х Jean Sammet отследил и зарегистрировал около 3000 языков программирования существовавших на тот момент времени. Когда вещи были более простыми для понимания, (но сложнее в теории, потому что машины были медленнее, меньше, большинство из них не имели жесткого диска, и не было удобных инструментов), люди, тем не менее, являли миру свои собственные операционные системы и языки программирования, когда им этого хотелось. По этому существуют несметное количество компьютерных языков.
В статье для Scientific American 20 лет назад, я пришел к курьёзной теории циклов, просто отметив, что каждые 10 1/2 лет появляется один или два крупных языка, а между этими периодами наблюдается то, что можно назвать гибридными языками. Эти языки представляют собой улучшенные старые идеи или «почти новые» идеи. Я отметил в статье, что Fortran являлся улучшением старых идей или реализацией почти новых идеи, в то время как Algol и Lisp были языками, принесшими действительно новые идеи.
Затем был язык Simula, разработчики которого считали его расширением Algol. Изначально он был препроцессором к Algol, так же как и C++ был препроцессором для C. Это была великолепная концепция и мне посчастливилось увидеть эту почти новую идею. Smalltalk и Prolog появились в начале 1970-х. Предшественником Prolog был замечательный язык программирования, который Карл Хьюитт сделал в конце 1960-х и назвал Planner.
Возможно, именно коммерциализации в 1980-х годах убила очередную новую идею. Мы планировали и надеялись, что новое поколение детей придёт и сделает что-то лучше чем Smalltalk к 1984 году. Мы все полагали, что следующий уровень языков программирования должен быть более стратегическим, даже политико-ориентированным (policy-oriented), и должен иметь большее представление о том, что он собирается делать. Но звёзды сложились так, что следующее поколение не появилось. Кто-то мог бы возразить - как я это иногда делаю - что успех коммерческих персональных компьютеров и операционных систем фактически обернулся значительным регрессом во многих, многих отношениях.
Вы можете представить себе коммерческую разработку, как низкочастотный фильтр для интересных идей ’60-х и ’70-х годов: компьютеризация начала распространяться быстрее, гораздо быстрее, чем образование простых людей. Примерно за последние 25 лет мы получили нечто похожее на поп-культуру. Подобное случилось когда телевидение вошло в нашу жизнь, часть изобретателей телевизора думала, что он будет служить способом донесения Шекспира в массы. Но они не учли, что для понимания Шекспира нужно быть искушёнными и иметь широкий кругозор. Телевидению лучше всего удавалось захватывать внимание людей.
Я считаю, что отсутствие реальной компьютерной науки сегодня и отсутствие настоящей разработки ПО, частично являются следствием этой поп-культуры.
SF По вашему Smalltalk можно сравнить с Шекспиром, а Excel – с телевизионном шоу про автомобильные аварии?
AK Нет, если посмотреть с исторической точки зрения, то Smalltalk - это небольшая греческая пьеса, которая хоть и намного опередила всё то, что делали остальные культуры, но не даже близко не приблизилась к творениям Шекспира.
Если взглянуть на современное производство приложений через призму истории инженерного искусства, то оно конечно похоже на инженерию, но на такую, где работа ведётся людьми без понимания общей архитектурной концепции. Большинство программных продуктов сегодня очень напоминают египетскую пирамиду с миллионами кирпичей, водружённых друг на друга, без какой-либо структурной целостности, сделанные грубой силой тысяч рабов.
SF Аналогия даже лучше чем кажется, потому что в них есть скрытые помещения о которых никто ничего не знает.
AK Я бы сравнил Smalltalk систему, которую мы делали в 70-е с чем-то похожим на Готический собор. В действительности у нас были две идеи. Одну мы позаимствовали у Lisp: позднее связывание. Другая идея была об объектах. Это давало нам какое-то подобие архитектуры, так мы могли делать сложные и громоздкие на вид структуры из очень лёгкого материала. Но я бы не сказал, что мы далеко ушли от инженеров, работавших за 1000 лет до нас.
Если вы посмотрите демку [Doug] Engelbart’а [гипермедийную живую онлайн демонстрацию новаторской работы, сделанной группой Engelbart’а в Stanford Research Institute, представленную в 1968 на Fall Joint Computer Conference], то вы увидите гораздо больше идей об увеличении коллективного IQ и помощи в совместной работе, чем в существующих сегодня коммерческих системах. Мне кажется, существует очень большой разрыв между тем, что можно назвать лучшими практиками в компьютерных исследованиях за многие годы, и тем, что смогло просочиться и было адаптировано в более целесообразном и прагматичном внешнем мире.
Это не означает, что люди совершенно глупы, но если существует некоторая идея, а над ней довлеют дедлайны, целесообразность и конкуренты, очень вероятно, что она пройдёт через низкочастотный фильтр и будет реализована только часть этой идеи, а то, что должно быть дальше, будут упущено. Это происходит постоянно. Если вы используете языки раннего связывания, как и большинство людей, а не языки позднего связывания, то вы начинаете зависеть от вещей, которые уже реализовали. Вы не сможете легко переформулировать, отрефакторить что-либо.
Следует сказать, что выбор новых языков программирования очень часто происходил случайным образом, и акцент при этом чаще всего ставится на простоте реализации языка, нежели на его реальных достоинствах и возможностях. Например, Basic никогда бы не появился, потому что всегда были языки решающие те же задачи лучше. Таким языком был Joss, предшествовавший Basic'у, и он был замечателен. Но Basic'у посчастливилось оказаться в системе разделения времени GE (GE timesharing system), сделанной фирмой Dartmouth, и когда GE решила продолжить франчайзинг системы, вместе с ней начал распространяться Basic. Просто потому, что он уже был в системе, а не по причине собственных достоинств или каких бы то ни было внутренних преимуществ.
И такое происходит постоянно. Языки Никлауса Вирта распространялись стремительно и широко потому, что он был одним из самых добросовестных документаторов языков и одним из первых сделал алгоритмические языки на основе пи-кода (псевдокода) — нечто вроде того, что используем мы. Идея использования таких языков возникла из-за аппаратной начинки машины Burroughs B5000, которую в начале 1960-х возненавидел истэблишмент.
The Descriptor[]
SF Отчасти потому, что не было никакой публичной информации по большинству из них.
AK Позволю себе не согласится. Это все происходило на моих глазах, и Burroughs нанял выпускников колледжа, чтобы те объяснили работу машины менеджерам по обработке данных. Информации по этому вопросу было предостаточно. Проблема была в том, что менеджеры не хотели осваивать новые способы вычислений, и даже не хотели учиться пользоваться компьютером. Компания IBM это поняла, а вот Burroughs - нет.
SF Если мне не изменяет память, я был просто очарован этой машиной в то время, но мне негде было узнать подробности, чтобы разобраться в ней.
AK В действительности, первая машина имела 2 CPU, и была абсолютно адекватно описана в 1961г. основным проектировщиком Бобом Бартоном. Один из документов назывался “The Descriptor” и описывал всё в подробностях. Проблема была в том, что почти всё в этой машине не соответствовало документу, и она предназначалась для совсем других целей.
Причина, по которой эта линейка продолжала жить даже несмотря на нелюбовь со стороны истеблишмента, скорее всего была в том, что эти машины было почти невозможно привести к аварии (crash). Поэтому начиная с B5000 эта линейка машин пользовалась спросом у банковской индустрии. Бартон был одним из моих профессоров в колледже, и я использовал некоторые его идеи в первой сделанной мной настольной машине. Позже мы более активно использовали эти идеи в Xerox PARC (Palo Alto Research Center).
Ни Intel, ни Motorola, ни какой-либо другой производитель чипов не осознали преимущества той архитектуры.
В отступление от темы расскажу об одном бенчмарке: на схожей системе Xerox PARC оптимизированной схожим образом бенчмарк 1970 года сейчас выполняется всего лишь в 50 раз быстрее. Закон Мура должен дать нам где-то 40,000-60,000-кратный прирост производительности за этот промежуток времени. Так что из-за за плохой архитектуры процессора была потеряна эффективность примерно в 1000 раз.
Миф о том, что архитектура процессора не имеет значения -- и что закон Мура сделает всё за вас -- совершенно ошибочен.
SF Также надо что-то делать с тем, что языки становятся успешными в определённое время.
AK Да, в действительности и Lisp и Smalltalk были погублены восьмибитными микропроцессорами и не потому, что они были восьмибитными, а потому что их архитектура была плохой и они они поставили крест на динамических языках. Сегодня эти языки работают приемлемо несмотря на ту же плохую архитектуру из-за гигантских размеров кэша 2 уровня. Некоторая часть работы производится быстро прямо в кэше. Поэтому Lisp и Smalltalk жизнеспособны сегодня. Но оба они, конечно, абсолютно устарели
Модные сегодня языки содержат лишь половину всех достоинств тех языков программирования. У Sun Microsystems были люди, которые хотели сделать Java первоклассным языком. Я думаю, что именно именно маркетинговая политика Sun вывела язык на сцену до того как он была готов. Маркетологи Sun не дали разработчикам Sun выполнить то, что следовало.
SF Что должна иметь Java, чтобы стать языком высшего качества, а не только коммерчески успешным?
AK Как я уже говорил, всё дело в поп-культуре. Коммерческий музыкальный хит для подросток не обязан обладать какой-либо музыкальной ценностью. Мне кажется, что большая часть успешных языков программирования были придуманы для оперативного заделывания дыр. Perl является примером языка, придуманного для заполнения крошечной, кратковременной необходимости, и который затем стал большой проблемой в долгосрочном периоде. По существу, за последние 25 лет большинство проблем вычислительной области возникли в системах, где разработчики пытаются решать краткосрочные проблемы не задумываясь о том, что будет с идеей после её принятия и разрастания. В мире ПО должно существовать понятия периода полураспада, чтобы устаревшие программы просто испарялись через 10-15 лет.
В 60-е и 70-е существовала другая культура. ARPA (Advanced Research Projects Agency) и PARC изначально имели математическо-научную базу и были заинтересованы в масштабировании, и конечно Internet был тому примером. Это разные миры, и я не думаю, что имеет смысл жаловаться друг на друга, подобно тому как люди из литературных кругов жалуются на редко читающее большинство. Это бесполезно.
Я не буду тратить времени на сожаление, потому что происходившее последние 20 лет -- это абсолютно нормальное явление, хотя мне печально это осознавать. Когда что-то развивается быстрее чем происходит образование в этой области, вы обязательно столкнётесь с поп-культурой. Всем хорошо известно, что я пробовал убить Smalltalk в конце 70-х. В течение нескольких лет это был самый прекрасный язык программирования в мире. Он отвечал всем нуждам и был более компактным и красивым чем всё, что было сделано до него. Но время не стоит на месте. По мере того, как мы узнавали все больше и становились амбициознее, мы осознавали, что не всё в Smalltalk масштабируется должным образом. Например, рефлексия (reflection). Это был один из первых языков, который действительно был в состоянии заглянуть в себя. Но сейчас известно как сделать все уровни рефлексии гораздо лучше -- мы должны это реализовать.
Мы увидели после нескольких лет, что все это можно сделать гораздо лучше. Объектная модель могла бы быть гораздо лучше и т.д. Проблема в том (я сейчас говорю о Smalltalk и Lisp), что они, как правило, овладевают юными умами. Я имею ввиду, что оба и Lisp и Smalltalk были великолепными средствами, потому что у них была мета-систему. В них было так много способов решать задачи, сколько не могло быть в языках раннего связывания. Приверженцам Lisp и Smalltalk очень, очень трудно представить что-то иное.
Упомяну несколько вещей касательно Java: в этом языке действительно нет полноценной мета-системы. В Java всегда была проблема (по ряду причин) с введением двух режимов вместо одного. В нём есть вещи, которые не являются объектами и есть вещи, которые называются объектами. Очень сложно писать на Java действительно динамические вещи. Да, есть сборщик мусора. Ну и что из того? Они уже давно существуют. И не такая уж большая заслуга была в его добавлении.
На протяжении нескольких лет наборы средств разработки (development kits) для Java были написаны на C++. Это говорит само за себя.
Мы достаточно подробно рассматривали Java в 1995г. просто потому, что создать жизнеспособное ядро языка достаточно затратно. Меньше всего нам понравилось как Java была реализована. В основе была старая идея, которая никогда не работала: взять бумажные спецификации, затем реализовать виртуальную машину (ВМ) по ним и создать тесты на проверку только что реализованного кода. В результате системы никогда не была полностью кросс-платформенной.
При разработке Smalltalk мы написали ВМ на языке Smalltalk. У нас был симулятор ВМ на Smalltalk и он был, по-существу, единственной спецификацией ВМ. Вы могли отлаживаться его работу и таким образом отвечать на любой вопрос о ВМ. Любое изменение, которое предполагалось сделать в ВМ, осуществлялось сперва на симуляторе. После того, как все отлаживалось, вы просто нажимали кнопку и без участия человека генерировался код -- математически корректная версия на C, которая выполнялась на любой платформе.
В результате сегодня система под названием Squeak выполняется идентично более чем на двух дюжинах платформ. Java этого не может. Если вы задумываетесь о нуждах Internet, то вы обязаны сделать выполнение идентичным на всем, что подключено к Internet. Java постоянно игнорировала один из основных принципов разработки ПО в мире Internet.
Как только мы поняли, что Java зависит от платформы, мы решили создать собственную систему, абсолютно идентично работающую на различных платформах, что и сделали.
Любой может это сделать. Если ребята из Sun решат поправить это в Java, мир станет более приятным. Это не секретное знание. Это секрет для поп культуры.
Lisp[]
SF. К стати, Lisp был точно реализован в терминах Lisp.
AK. Да, для меня это было большим откровением во время моей аспирантуры. Я, наконец, понял, что код в нижней половине страницы 13 из руководства Lisp 1.5 – это Lisp на Lisp-е. Это можно назвать "Уравнения Максвелла в программном обеспечении!" Это целый мир программирования, помещённый в несколько строк, к которым я могу приложить свою руку.
Я понял, что в любое момент, когда я захочу узнать, что происходит, то могу просто записать ядро этого языка в половину страницы, и при этом оно ничего не потеряет. В действительности, такой подход только добавит мощности, так как появится возможность повторно заглянуть в себя. Причём это делается гораздо легче, чем в большинстве остальных систем.
Все эти идеи могут быть применены как в разработке программного обеспечения, так и в вычислительной технике. Но я опасаюсь, что (насколько мне известно) большинство бакалавров в области компьютерных наук в наши дни это в основном профессиональные Java разработчики.
Я слышал жалобы из могучего Стэнфордского университета с его знаменитым факультетом, что большая часть учебной программы магистратуры по компьютерной науке является не более чем сертификацией Java.
SF. Ну, должен признаться, я был удивлён, когда недавно обнаружил в руководимой мною группе очень хороших разработчиков, что почти никто из них не знал C достаточно хорошо, чтобы писать на нём профессиональные низкоуровневые вещи. Все из них были действительно хорошие Java кодеры (в оригинале "jock" - программист, пишущий программы "в лоб", не творчески).
AK. В 1960-е годы Тед Стил провёл несколько лет продвигая идею под названием UNCOL (универсальный компьютерно-ориентированный язык), и, на мой взгляд, в результате странного и интересного процесса (главным образом по причине простоты реализации) C стал тем самым UNCOL. Я не рекомендую кому-либо писать на C, но это важный шаг для тех, кто хочет писать мультиплатформенные вещи, особенно если вы правильно выбрали подмножество этого языка.
Проблема с различными реализациями C, как вы, наверное, знаете, если плотно работали с ними, в том, что они не совсем кошерны в вопросах арифметики. Предполагается, что они должны соблюдать стандарты IEEE, но это зачастую не так. Чтобы получить математически совершенное преобразование для вашей виртуальной машины, необходимо выбрать подмножество C и должна быть некоторая дополнительная информация.
SF. В чём, по вашему, отличительная черта долгосрочной любви к Smalltalk? Существует определённый набор языков, которые, как мне кажется, пользуются не только популярностью, но и любовью среди программистов. Я знаю многих людей, которые любят C. Я знаю очень мало людей, которые любят C++, хотя многие зарабатывают на этом языке.
AK. Чтобы любить C++ нужно быть особенным человеком. Это интересный пример того, как изначально хорошая идея пошла не так, потому что [создатель C++] Бьерн Страуструп не старался делать то, за что его потом критиковали. Его первоначальная идея состояла в том, что будет полезно сделать с C то же, что Simula сделал с Algol. То есть, по сути, создать препроцессор для различного рода архитектурных шаблонов программирования. По началу им пользовались только супер-хорошие программисты, которые делали собственные реализации всего, в том числе распределения памяти, чтобы иметь возможность в дальнейшем написать что-нибудь серьёзное. В результате, конечно, получилось так, что большинство программистов не собирались переписывать всё на свете. Так мои знакомые любители C++ были действительно железными-мужиками, потому что использовали C++ по прямому назначению -– как определённый вид макропроцессора. Я начинал с макро-систем в начале 60-х, и знаю, что нужно приложить много усилий, чтобы заставить их работать, иначе, они погубят тебя.
SF. Ну, C++, сущности, был запрограммирован как макропроцессор.
AK. Да, точно. Но так же было с Simula.
SF. Я поставил Smalltalk в категорию языков, у которых есть истинные поклонники – люди, которым по настоящему нравится язык или которые любят этот язык, а не просто знают и используют его.
AK. В истории Smalltalk, которую я написал для ACM, я описал один из способов классификации языков программирования: большинство языков либо предназначены для склеивания фич (features), либо для кристаллизации стиля. Языки, такие как APL, Lisp, Smalltalk можно назвать языками стиля, у которых есть определённый центральный стиль, которому нужно следовать при использовании. Другие примеры, такие как PL / I , представляют из себя языки, которые пытаются быть кумулятивными без обобщения и консолидации, и часто такие языки оказывались более успешными. Я думаю, языки стиля обращены к людям, у которых есть определённая математическая лень. Лень фактически окупится в дальнейшем, потому что через некоторое время вы скажете себе "ах, да, этот язык позволит мне сделать это очень, очень красиво, и в более общем виде, чем я мог это сделать раньше". Эта мысль, как правило, приходит в голову, когда после долгих лет у вас возникает новая отличная идея. Аддитивные, связывающие языки в свою очередь, как правило, приводят к накоплению кода, который очень, очень трудно распутать, когда к вам внезапно приходит новая идея.
Кроме того, я думаю, что языки стиля, как правило, являются языками позднего связывания. А аддитивные языки –- раннего связывания. Это оказывает огромное влияние на подход в целом. Виды ошибок, с которыми вам придётся иметь дело, и этапы, на которых вы с ними столкнётесь, совершенно иные.
Некоторые люди относятся к системе типизации как религиозные фанатики. Как математику мне нравится идея системы типов, но никто не придумал такой системы с достаточными возможностями. Если вы объедините Simula и Lisp (в Lisp нет структур данных, в нём есть объекты), у вас получится система с динамической типизацией, которая будет обладать широкими возможностями.
Это позволит вам думать в тех категориях, которые вам нужны, не беспокоясь о том, какой тип у той или иной вещи. У вас появится гораздо более широкий круг категорий. Платой за этой выступают некоторые проверки во время выполнения, и, особенно в старые времена, это отобразится на производительности. Сейчас мы получаем приблизительно ту же эффективность как у Бартона на машине B5000: мы просто говорим, "Забей, мы собираемся выполненить эту штуку как можно более прямолинейно." Мы больше не беспокоимся о том, возможно ли скомпилировать наш код для архитектуры фон Неймана или нет. Мы добавим в микрокод нужные нам возможности, и обойдём узкие места. Потому что большинство узких мест вышли из плохой архитектуры железа.
Я просто думаю, что дело в различии этих двух культур. Я видел много совещаний и встреч, где люди не могут общаться по причине стилистических различий в подходах.
SF. Я бы охарактеризовал языки стиля как языки с очень жёстким ядром, которое описывает их интеллектуально. По мере того, как Smalltalk прошёл несколько революций, в какой степени эти изменения коснулись ядра, в противовес повышению спектра полезности?
AK. Мы никогда не узнаем точный ответ на ваш вопрос, потому что в ходе разработки системы, с того момента, когда Xerox выпустила его и по сей день, все изменения произошли в один этап развития в Xerox PARC. Для внешнего мира, Smalltalk практически не изменился. В основном, он был построен на более и более широких библиотеках различного рода.
Что хорошо в изменениях в Smalltalk, так это то, что они никогда не обедняли язык, и сфера практических применений, в которых вы могли использовать Smalltalk, значительно разрослась в течение периода разработки в стенах Xerox PARC.
Основное изменение состояло в том, что язык стал больше и больше инструментом программистов и всё меньше и меньше был инструментом для детей -– версия Smalltalk '80, которую мы выпустили, я не думаю, что этой версией когда-либо пользовался ребёнок. Я не думаю, что ребёнок мог бы программировать нашим языком, потому что язык потерял часть своей мягкости и простоты, получив при этом прагматическую мощь.
Так смерть Smalltalk в какой-то мере произошла как только настоящие программисты признали его полезность. Они начали делать собственные образы, и система начала терять свою привлекательность для конечного пользователя.
Но это нормально. Проект, который мы начали в 1995 году, заключался в создании на основе Squeak системы, которой будут пользоваться дети. У нас получилось очень хорошо, и в настоящее время она используется многими, многими тысячами детей во всём мире. С другой стороны, нужно понимать, что компьютеры сделаны, чтобы быть запрограммированными человеком. Давайте просто сделаем свой собственный. Без оглядки на Java, или даже на Smalltalk.
В самом деле, давайте не будет беспокоиться о Java. Давайте не будем жаловаться на Microsoft. Давайте не будем беспокоиться о них, потому что мы тоже знаем, как программировать компьютеры, и на самом деле мы знаем, как сделать это в мета-стиле. Мы можем создать альтернативную точку зрения, и мы не единственные, кто так делает, как вы наверняка знаете.
В Интернете есть множество примеров людей, которые перешли на тот или другой уровень, делая это совершенно по своему. Squeak является наиболее полным, поскольку он охватывает все сферы. Он не требует какой-либо конкретной операционной системы для запуска, потому что представляет из себя самодостаточный и полный набор инструментов и приложений. И так далее. Но есть много интересных функциональных языков, особенно в Европе, которые представляют интерес.
Один из моих любимых старых языков это язык под названием Lucid сделанный Эдом Эшкрофтом (Ed Ashcroft). Идея была очень красивая. Он сказал: "Эй, смотрите, мы можем рассматривать переменную как поток, как своего рода упорядоченный список её значений и времени, и использовать идею Кристофера Стрэчи (Christopher Strachey) о том, что все замечательно в хвостовой рекурсии и Lisp-е, кроме внешнего вида". Когда он посмотрел на Lisp, его озарило: циклы с хвостовой рекурсией и Lisp настолько чисты, потому что вы создаёте правую часть всех операторов присваивания до того, как делаете любые присваивания. Так вы автоматически вынуждены использовать только старые значения внутри цикла. Вы не можете переназначить переменные, поэтому нет гонки условий (race conditions).
Вы просто записываете все вычисленные значения переменных, а затем, когда вы сделаете хвостовую рекурсию, вы переназначите все эти переменные этими новыми значениям. Стрэчи сказал: "Я могу написать последовательную программу, в виде одновременного присваивания и цикла, что упростит её понимание". Это в основном то, что сделано в Lucid –- нет необходимости думать рекурсивно в случае итеративных вещей. И вы можете сделать эти итерации чистыми, как в функциональных языках, если у вас есть лучшие знания о значениях переменных.
Эта идея, кстати, была использован в фантастическом сочинении Дэйва Рида (Dave Reed) [разработчик Squeak]. В этом сочинении описывался механизм координации семейства объектов, когда у вас есть один логический объект, но много его физических воплощений на разных машинах. И вам нужно отслеживать каждый из них путём транзакций.
Один из способов избавиться от таких вещей (как, например, Smalltalk) -– это сделать что-то гораздо, гораздо более мощное, с точки зрения вычислительной модели и очень выразительное для базовых программистов (core programmer). В этих поздних языках программирования, вы можете убрать старого парня и просто поставить на его место нового. Это то, чем мы занимаемся в настоящий момент.
GUI[]
Как вы думаете, чего должен достичь язык программирования и для кого, и, в таком случае, какая модель использования идёт с этой идеей?
AK. Даже если вы разрабатываете для профессиональных программистов, в конце концов, ваш язык программирования по сути является пользовательским интерфейсом. У вас получится лучше, независимо от того, что вы пытаетесь делать, если вы будете думаете о нем, как о дизайне пользовательского интерфейса. Неверно будет приписывать PARC изобретение GUI. Конечно, в 60-х там были GUI. Но я думаю, мы сделали одну хорошую вещь, которую до нас никто не сделал. Мы осознали идею непрерывных изменений.
SF. Нельзя дважды войти в одну и ту же реку.
AK. Пользовательский интерфейс, который по-прежнему является преобладающим подходом в разработке ПО -– это доступ к функциям. Если важно максимальное покрытие функций, вы в конечном итоге получите что-то наподобие пульта управления ядерным реактором. То есть у вас будет накопление фич.
SF. Да, кнопка на каждом пикселе.
AK. Корпоративные покупатели часто совершают покупки руководствуясь набором функций. Но в PARC наша идея была в том, поскольку нельзя дважды войти в одну и ту же реку, то первым делом вам захочется сделать из него обучающую среду -– что-то, что можно изучать различными способами, то, что будет меняться с течением времени, по мере того, как пользователя будет этой средой пользоваться. Новые вещи будут появляться, и как это повлияет на будущие изменения?
Это означает, улучшения не только в приложениях, но и в самом пользовательском интерфейсе. Некоторые из этих идей были заявлены в оригинальном Macintosh, но гораздо меньше проявляются в современных Маках. И, конечно, они никогда не доберутся до Microsoft. Просто это кардинально отличается от их способа мышления. Я думаю, похожая ситуация сложилась и с языками программирования. Даже если пользователь является абсолютным экспертом и в состоянии запомнить почти всё, меня всегда интересовала разница между тем, что называется закостенелым мышлением и подвижным мышлением.
Я провёл довольно много исследований за эти годы, чтобы понять влияние чего-то, что вы можете прочитать. Известно, что наш основной языковой механизм для чтения и слушания содержит быстрые и медленные процессы. Быстрый процесс имеет в основном поверхностный характер и действуют в масштабе фраз, затем идёт медленный. Вот почему шутки требуют пауз; шутка на самом деле -- это переход от одного контекста к другому, и медленные парень, который имеет дело с реальным мышлением, должен быстро схватывать.
В этом направлении было много исследований. Это доказывает, что поверхностная формы языка, какой бы она ни была, должна быть подвижной в некотором смысле.
SF. Как вы, наверное, знаете, недавние исследования показали, как различные участки мозга распознают и реагируют на шутки. Физиологически, они очень отличаются.
AK. Да. Всё творчество -– это расширенная форма шутки. Большинство творческих работ -– это переход из одного контекста в тот, где вещи становятся более удивительными. Существует элемент неожиданности, и особенно в науке, часто случается смех, за которым идет "Ага". В искусстве тоже присутствует этот элемент. Наша работа заключается в том, чтобы напомнить нам, что существуют и другие контексты, помимо того, в котором мы находимся. Тот, в котором мы думаем -– это реальность.
В 60-х годах одна из основных задач сообщества компьютерных учёных была в достижении расширяемого языка. Насколько я знаю, только три таких языка на самом деле работали. Первый Smalltalk входил в эту тройку. Другая очень интересная идея была предложена Недом Айронсом (Ned Irons), который изобрёл термин синтаксически-направленный компилятор (syntax-directed compiler) и сделал одну из первых версий в 60-х. У него получился прекрасный расширяемый язык под названием Imp.
Одна из вещей, которые люди поняли из таких расширяемых языков, состоит в том, что есть, к сожалению, трудности в создании простой мета-системы. Smalltalk-72 был, фактически, предназначен для детей. Ты постоянно расширяешь систему, не осознавая этого, когда создаёшь обычные классы. Результатом этого было то, что отпадает необходимость двигаться в эзотерические места, такие как компилятор компиляторов – Yacc или что-то подобное – чтобы немного расширить возможности языка.
Но обратной стороной медали оказалось то, что даже хорошие программисты и разработчики языка как правило делали ужасные расширения, будучи в самом разгаре программерского запала. А дизайн это то, что лучше всего делать медленно и осторожно.
SF. И написанные за ночь расширяемые программы не возможно поддерживать.
Это было не совсем то что нужно. Одна из вещей, которые, я думаю, стоило бы сделать сегодня, это построить забор, через который нужно перепрыгнуть, чтобы попасть в мета-область. Преодолевая эту преграду вы принудительно напоминаете себе, что вы теперь в плоскости мета-прораммирования, что вы сейчас конкретно копаетесь в самой системе, а не занимаетесь домыслами. Но система не должна ставить перед вами другие ограничения после перехода этого забора. Потому что, когда вы хотите сделать это, вы хотите сделать это.
Я мог бы продолжать и дальше. Я чувствую, что мои ответы слишком очевидны, потому что никто не знает, как спроектировать хороший язык. Даже я.
SF. Что вы бы хотели сделать иначе в эпоху Smalltalk?
AK. У меня была величайшая команда в мире, а мне нужно было сделать две величайшие команды в мире. Я не понимал преимуществ наличия реальных пользователей и реальных конструкторов языка. А также есть реальная польза, если начинать всё с самого начала каждые несколько месяцев. Я нанял доводчиков, потому что из меня хороший стартер и плохой доводчик. Но я потратил много времени, прежде чем понял, что я мешаю им своими вечными попытками что-то улучшить.
Я считаю, что единственный правильный вид компьютерной науки должен быть похож на науку строительства мостов. Кто-то должен строить мосты, а кто-то должен их взрывать, чтобы строить на месте взорванных ещё лучше. Необходимо продолжать возводить мосты.
SF. И так же нужно постоянно следить, чтобы они не падали в воду.