jpl

Table of Contents

Лиспинг в JPL

Copyright (c) 2002 by Ron Garret ( fka Erann Gat ), все права защищены.

Это история о подъеме и падении Лиспа в Лаборатории реактивного движения (Jet Propulsion Lab, JPL), c моей личной (и очень предвзятой) точки зрения. Я не пишу в своем официальном качестве сотрудника JPL, и я никоим образом не представляю официальную позицию JPL. (Это станет довольно очевидным в ближайшее время.)

1988-1991 - годы робототехники

Я пришел в JPL в 1988 году для работы в группе искусственного интеллекта на автономных мобильных роботах. Тогда времена были разные. Доллары свободно текли из правительственной казны. AI Winter только начиналась, и она еще не дошла до JPL. (Технология в лаборатории, как правило, на несколько лет отстает от современного уровня техники :-)

JPL в то время находилась на ранних этапах планирования для миссии марсианского ровера под названием "Возвращение образца с марса" (Mars Rover Sample Return, MRSR). В те дни космические миссии были большими, с большой буквы Б. MRSR-ровер должен был весить почти тонну. Бюджет миссии был миллиардным (что было типично в те дни).

На этом фоне я пошел работать на одного из друзей по имени Дэвид Миллер , который также оказался моим советником по диссертациям. Тогда у Дейва была радикальная идея использовать маленьких роверов для изучения планет вместо больших. В 1988 году это было тяжело продать. Очень мало людей считали, что маленький ровер может сделать что-нибудь полезное. (Многие до сих пор считают)

nil

Используя некоторое творчески приобретенное финансирование НИОКР, Дэйв нанял Колина Энгла (тогда аспиранта на Род Брукс в Массачусетском технологическом институте, ныне генеральный директор IS Robotics) в качестве летнего студента. Колин построил маленький робот по имени Tooth , который сильно контрастировал с 2000-фунтовым Robby, который был испытательным стендом для миссии MRSR.

nil

В то время это было более или менее само собой разумеющимся, что вся AI работа была выполнена на Лиспе. C++ едва существовал. Perl был совершенно новым. Java был всего год. Космические аппараты были в основном запрограммированы на ассемблере, или, если бы вы были действительно радикальными, на Аде.

У Robby было два процессора Motorola 68020, работающих под управлением vxWorks, каждый (если память меня не обманывает) с 8 МБ ОЗУ. (В то время это считалось огромным количеством оперативной памяти. На самом деле работа Robby часто подвергалась критике за то, что, помимо всего прочего, он был слишком прожорлив в отношении памяти, чтобы быть полезным). Напротив, у Tooth было два Motorola 68hc11 8-битных микроконтроллера, каждый с 256 байтами ОЗУ и 2 Кбайт EEPROM. (В более поздних роботах мы использовали 6811 с "огромными" 32 Кбайтами ОЗУ).

(В качестве показателя того, насколько быстро и как радикально отношения могут измениться, на днях я услышал, как инженер жаловался, что "вы ничего не можете сделать только с 128 мегабайтами").

Оба ровера, Robby и Tooth, были запрограммированы с использованием Lisp. На Робби мы фактически запустили Лисп на борту. Лисп, который мы использовали, был T 3.1, который был перенесен с Sun3 на vxWorks с большой помощью от Джима Фирби, который пришел в JPL из Йеля. Джим также написал пакет совместимости T-in-common-lisp под названием Common T. Используя Common T, мы могли разрабатывать код на Macintosh (используя Macintosh Common Lisp и симулятор Robbie, также написанный Jim), а затем запустить полученный код напрямую на Robby без изменений.

Процессоры Tooth не имели достаточного количества ОЗУ для запуска Lisp непосредственно 1, поэтому вместо этого мы использовали специально разработанный компилятор, написанный в Lisp для генерации кода 6811. Сначала мы использовали Subumption compiler Рода Брукса, но позже я решил, что мне не нравятся ограничения, наложенные архитектурой subsumption, и написал мой собственный язык под названием ALFA 2 . Впоследствии ALFA использовалась для программирования целой серии роверов, серии Rocky, которая в конечном итоге привела к Sojourner rover для миссии Mars Pathfinder. (У Sojourner был процессор Intel 8085 с 1 МБ ОЗУ с переключением банков памяти, который был запрограммирован на C. Подробнее об этом решении позже.)

Tooth, Robby и Rocky были одними из самых способных роботов своего времени. Robby был первым роботом, который когда-либо ориентировался автономно в наружной среде, используя стереовидение в качестве единственного датчика. (ПРИМЕЧАНИЕ: код стереовидения был написан на Си Ларри Маттисом.) Tooth был всего лишь вторым роботом, который выполнял задачу по сборке объектов внутри помещений, а другой - Herbert , который был разработан годом или двумя ранее Джонатаном Коннеллом, работающим в Лаборатория мобильных роботов Рода Брукса в Массачусетском технологическом институте. (Но Tooth был намного более надежным, чем Герберт) Rocky-роботы были первыми микророверами, которые успешно работали в условиях пересеченной местности. В 1990 году Rocky III продемонстрировала полностью автономную миссию по сбору и сбору проб, которая не была воспроизведена до моего сведения за двенадцать лет.

Период между 1988 и 1991 годами был удивительно продуктивным для автономных мобильных роботов в JPL. Он также был, к сожалению, политически неспокойным. Группа Дэйва Миллера, увы, не была частью организационной структуры, которая имела «официальную» хартию для проведения исследований робототехники в JPL. Результатом стало кровопролитное подковерное сражение, которок в конечном итоге привело к роспуску группы робототехнических исследователей и уходу почти всех его членов (и, вероятно, тому факту, что Sojourner был запрограммирован на Си).

1992-1993 гг. - Разные истории

В 1993 году, для моей собственной лебединой песни робототехники, я вошел в конкурс мобильных роботов AAAI. Мой робот (RWI B12 по имени Альфред) был введен в два из трех событий (третий потребовал манипулятора, которого не хватало Альфреду) и занял первое и второе место. (Альфред на самом деле был единственным роботом, который смог закончить одно из событий.) Но крутой момент состоит в том, что весь код, специфичный для конкурса, был написан за три дня. (Я начал работать над этим на самолете на конференцию.) Я приписываю этот успех во многом тому факту, что я использовал Lisp, в то время как большинство других команд использовали Cи.

Также в 1993 году я использовал MCL для создания кода для магнитометра Gallileo. Магнитометр имел процессор RCA1802, по 2k ОЗУ и ПЗУ каждый, и был запрограммирован на Forth с использованием системы разработки, которая работала на давно выведенном из эксплуатации Apple II. В инструменте появился плохой байт памяти прямо в середине кода. Код должен быть исправлен, чтобы не использовать этот байт. Первоначально команда магнитометров оценила, что восстановление среды разработки и создание патча для кода займет так много времени, что они даже не попытаются это сделать. Используя Lisp, я написал с нуля среду разработки Forth для инструмента (включая симулятор для аппаратного обеспечения) и использовал его для создания патча. Весь проект занял менее трех месяцев part-time работы.

1994-1999 гг. - дистанционный агент

В 1994 году JPL приступила к работе над дистанционным агентом (Remote Agent, RA), автономной системой управления космическими аппаратами. RA был написан полностью в Common Lisp, несмотря на неумолимое политическое давление, чтобы перейти на C++. В какой-то момент была предпринята попытка перенести одну часть системы (планировщика) на C++. Эта попытка должна была быть заброшена через год. Основываясь на этом опыте, я думаю, можно с уверенностью сказать, что если бы не Lisp, Remote Agent потерпел бы неудачу.

Мы использовали четыре разных Common Lisp в ходе проекта Remote Agent: MCL, Allegro, Harlequin и CLisp. Они выполнялись в разных комбинациях в трех разных операционных системах: MacOS, SunOS и vxWorks. Harlequin был Лиспом, который, в конце концов, полетел на космический корабль. Большая часть наземного развития была выполнена в MCL и Allegro. (CLisp был также перенесен на vxWorks, и, вероятно, мог бы стать тем Lisp, который полетел, но фактически ему не хватало threads-многопоточности). Мы легко перемещали код взад и вперед среди этих систем.

Программное обеспечение удаленного агента, работающее на пользовательском порту Harlequin Common Lisp, вылетел на борту Deep Space 1 (DS1), первой миссии программы New Millennium Progran НАСА. Remote Agent управляел DS1 в течение двух дней в мае 1999 года. За это время мы смогли отладить и исправить состояние гонки, которое не было обнаружено во время наземных испытаний. (Отладка программы, работающей на аппаратной части стоимостью 100 млн. долларов, которая находится на расстоянии 100 миллионов миль, представляет собой интересный опыт. Наличие цикла чтения-выполнения-печати (REPL), запущенного на космическом корабле, оказалось неоценимым в поиске и устранении проблемы. История ошибки в Remote Agent сама по себе интересна).

Remote Agent впоследствии был назван "NASA Software of the Year".

Предупреждение! Отсюда рассказ принимает несколько менее приятных поворотов. Если вы не настроены на плохие новости и много циничных разглагольствований, перестаньте читать. Вы были предупреждены.

1999 - MDS

Теперь вы можете ожидать, что с таким послужным списком, с одними технологическими успехами, NASA будет спешить принять Lisp. И вы, конечно, ошибетесь.

Миссии "New Millennium" должны были стать флагманами новой «лучшей, быстрой и дешевой» НАСА, что означало, что нам был предоставлен бюджет, который был невероятно мал, и график, который был невероятно плотным. Когда начался неизбежные выходы за график и бюджет, проекту нужен козел отпущения. Важнейшим поворотным моментом стал крупный обзор, в котором приняли участие около 200 человек, включая многих топ-менеджеров JPL. В какой-то момент инженер по интеграции программного обеспечения давал свою презентацию и перечислял все то, что было не так. Кто-то (я не знаю, кто) прервал его и спросил, может ли он изменить только одно, чтобы улучшить ситуацию, что бы это было. Его ответ был: избавиться от Лиспа 3 .

Это событие было в значительной степени концом Lisp в JPL. Remote Agent был понижен от "mainline flight software" до "flight experiment" (теперь он переименован в RAX). Он все еще летал, но он контролировал корабль только два дня.

Я попытался воскресить Lisp в моем следующем проекте (JPS Mission Data System или MDS), но ущерб был нанесен. В попытке решить одно из главных возражений против Lisp, что он был слишком большим, я нанял Гэри Байерса, который написал компилятор для Macintosh Common Lisp (MCL) для переноса MCL на vxWorks. (По пути он также выпускал порты для Linux и Solaris.) Образ MCL был всего 2 МБ (по сравнению с 16 или около того для Harlequin), но оказалось, что это не имеет значения. Лисп умер, по крайней мере, в JPL. Спустя два года Гэри понял, что его работа никогда не будет использоваться кем-либо, и он тоже оставил JPL. Несколько месяцев спустя я последовал за ним и пошел работать в Google. (Работа, которую Гэри сделала на порту Linux, в конце концов нашла свой путь в OpenMCL, так что это не была полная потеря для мира.)

В JPL было по крайней мере еще два крупных события Lisp: Марк Джеймс написал систему под названием SHARP (Spacecraft Health Automated Reasoning Prototype), которая диагностировала аппаратные проблемы на космическом корабле Voyager, а Курт Эггемейер написал планировщик под названием Plan-It, который использовался для наземного планирования нескольких миссий. Было много других. Все давно забыты.

2000-2001 - Google

Этот раздел немного не по теме, поскольку это, как предполагается, история Lisp в JPL, но некоторые аспекты моего опыта в Google могут, тем не менее, представлять интерес.

Одной из причин, по которым я оставался в JPL в течение двенадцати лет, было то, что я был потрясен тем, чем стала индустрия программного обеспечения. Мир управления пытался разработать процессы разработки программного обеспечения, которые позволяют подключать людей к ним, как взаимозаменяемые компоненты. "Спецификация интерфейса" для этих человеческий "компонентов" обычно включает в себя список инструментов, в которых инженер получил "тренинг". (Я действительно ненавижу использование слова "тренинг" в отношении профессиональной деятельности. Тренинг (training) - это то, что вы делаете с собаками. То, что вы должны делать с людьми, - это их обучение (educating), а не тренинг их. Это очень, очень большая разница).

На мой взгляд, отличительной чертой взаимозаменяемой компонентной модели инженеров-программистов является Java. Не вдаваясь в слишком много деталей, я просто скажу, что, имея опыт программирования в Lisp, недостатки Java очевидны, а программирование на Java означает постоянную и неустанную боль. Поэтому я поклялся, что никогда не буду программистом на Java, и это, в значительной степени, закрыло для меня 90% всех работ по разработке ПО в конце 90-х. Это было нормально, так как мне удалось сделать достаточно успешную карьеру в качестве исследователя. Но после Remote Agent я все больше и больше расстраивался, и возможность работать в Google просто совпадала с локальным минимумом расстройства.

Одна из причин, по которой я решил работать в Google, заключалась в том, что они не использовали Java. Так что, конечно, вы можете догадаться, что мое первое задание было: возглавить инаугурацию Java-разработки в компании, что в конечном итоге стало Google AdWords . Слава богу, у меня был младший инженер, который работал на меня, который действительно знал что-то о Java, и не возражал против этого. В древней традиции отношений старшего и младшего он выполнял всю работу, и я взял на себя все заслуги. (Ну, не совсем, я написал систему биллинга, в том числе довольно проворную систему безопасности, которая защищает номера кредитных карт даже от недобросовестных сотрудников. Но Джереми написал львиную долю AdWords версии 1.)

Я попытался ввести Lisp в Google. Имея некоторый опыт продажи Lisp в JPL, я выставил все сильнейшие стороны в ряд, провел крутую демонстрацию, показал ее всем остальным членам команды объявлений и убедился, что это хорошая идея. Осталось только получить одобрение от вице-президента по разработкам. Разговор шел примерно так:

Я: Я хотел бы поговорить с вами о чем-то … Он: Позвольте мне угадать - вы хотите использовать Smalltalk. Я: Э, нет … Он: Лисп? Я: Верно. Он: Ни в коем случае.

И это был конец Lisp в Google. В ретроспективе я не уверен, что он принял неправильное решение. Очевидно, что взаимозаменяемая компонентная модель инженеров-программистов работает достаточно хорошо. Это просто не та бизнес-модель, в которой я хочу участвовать, по крайней мере, не со стороны поставщика "компонентов". Поэтому через год в Google я ушел и вернулся в JPL.

2001-2004 Ваши налоговые доллары в работе

Когда я вернулся в JPL, они поставили меня работать над - (я дождался) - поисковыми системами! По-видимому, у них появилась такая идея, потому что я работал в Google в течение года, и теперь я был экспертом в поисковых системах (неважно, что на самом деле я не работал над поисковой системой). К счастью для меня, работа над поисковыми системами в JPL не означает то же самое, что работать в поисковых системах в Google. Когда вы работаете в поисковых системах в Google, это означает, что вы на самом деле работаете над поисковой системой. Когда вы работаете в поисковых системах в JPL, это означает покупку поисковой системы, о которой я действительно знал совсем немного. (Позвоните в Google, разместите заказ.) Вы не хотите знать, сколько из ваших налоговоых долларов заплатили мне за помощь в ведении заказов на покупку через бюрократию JPL.

Но я отвлекся.

Комментарий

Кончина Лиспа в JPL - трагедия. Язык особенно хорошо подходит для разработки программного обеспечения, которое часто делается здесь: уникальные, высокодинамичные приложения, которые должны разрабатываться в чрезвычайно жестких бюджетах и графиках. Эффективность языка в такой среде достаточно документирована благодаря большому количеству непревзойденных технических достижений.

Ситуация особенно иронична, потому что аргумент, который был выдвинут для отказа от Lisp в пользу C++ (а теперь и для Java), заключается в том, что JPL должен использовать "лучшую отраслевую практику". Проблема с этим аргументом двояка: во-первых, мы смешиваем передовую практику со стандартной практикой. Эти два варианта не совпадают. Во-вторых, мы предполагаем, что наилучшая (или даже стандартная) практика является инвариантом относительно такой задачи задачи: лучший способ написать текстовый процессор - также лучший способ написать систему управления космическим кораблем. Это не так.

Это невероятно расстраивает, наблюдая, как все это происходит. Моя работа сегодня (теперь я работаю над software verification and validation) - это решение проблем, которые можно проследить непосредственно до использования чисто императивных языков с плохо определенной семантикой, такой как Cи и C++. (Ситуация немного лучше с Java, но не настолько) Но, конечно, очевидное решение - использовать неимперативные языки с четко определенной семантикой, такой как Lisp, - это не вариант. Я даже не могу сказать слово Lisp, не закрепив свою репутацию сумасшедшего лунатика, который думает, что Лисп - это ответ на все. Поэтому я держу свой рот закрытым (в основном) и беспомощно смотрю, так как миллионы налоговых долларов теряются. (Я бы наложил некоторую надежду на волну возмущения снизу по поводу этой вопиющей траты денег, но, увы, по масштабам отвратительных растрат, которые обычно происходят в правительственных начинаниях, это мелочь, не стоящая упоминаная)

По словам Элтона Джона: Это печально. Очень печальго. Это печальная, печальная ситуация. Моя лучшая надежда на этот момент заключается в том, что крах доткомов сделает с Java то, что AI Winter сделала c Lisp, и мы можем в конечном итоге выйти из "DotCom Winter" в более чистый мир. Но я бы не стал ставить на это.

ЗАМЕТКИ:

Footnotes:

1

Можно запустить Lisp на удивительно маленьких процессорах. Мой первый Lisp был P-Lisp, который работал на Apple II с 48 КБ оперативной памяти. Проблема с трехдисковыми ханойскими башнями была связана с его возможностями.

2

ALFA была аббревиатурой, которая означала "Язык для действий", A Language For Action. Мой план состоял в том, чтобы в конечном итоге разработать язык, который будет называться BETA, который будет поддерживать "Better Even than ALFA". Но я никогда не обхоешел его.

3

Это ставит вопрос о том, почему он это сказал. Причина, которую он дал в то время, заключалась в том, что большую часть времени занимались вопросами многоязыковой интеграции. Однако это было опровергнуто следующим фактом: незадолго до обзора я встретился с инженером-интегратором и предложил ему помочь с любыми проблемами, связанными с Lisp, с которыми он сталкивался. Он ответил, что я не могу помочь. Поэтому, хотя возникли проблемы, связанные с тем, что Лисп должен был взаимодействовать с Си, я не считаю, что были предприняты добросовестные усилия для решения этих проблем.

Постскриптум: многие из проблем, связанных с многоязыковой интеграцией, были вызваны системой межпроцессного взаимодействия (Inter Process Communication, IPC), которая позволяла взаимодействовать Lisp и C. IPC полагался на центральный сервер (написанный на C), который регулярно падал. Избавление от Lisp действительно облегчало эти проблемы (поскольку ненадежный IPC больше не нужен). Тем не менее, в высшей степени иронично, что гибель Лиспа в JPL в конечном счете была вызвана в немалой степени ненадежностью программы на С.

Яндекс.Метрика
Home