Автор, как и другие разработчики на Common Lisp и CLOS, подвержен сильному влиянию стиля разработки Массачусетского Технологического института и Стэндфорда. Существо этого стиля может быть кратко выражено словосочетанием «правильная вещь». Для разработчика этого стиля важно правильно понимать следующие характеристики (выделения наименований характеристик жирным шрифтом сделаны переводчиком – Н.В.Ч):
Автор полагает, что большинство людей согласятся с этими характеристиками. Будем называть такую философию проектирования Массачусетским подходом.
Философия «хуже – лучше» отличается совсем немного (курсив ниже – мой, курсивом выделены отличия от Массачусетского подхода – Н.В.Ч):
Ранние Юниксы и Си служат примерами этой школы проектирования. Будем называть эту стратегию проектирования подходом Нью-Джерси. Карикатуризация философии «хуже – лучше» проведена автором намеренно, чтобы убедить читателя, что это очевидно плохая философия и что подход Нью-Джерси – это плохой подход.
Тем не менее, автор верит, что подход «хуже – лучше», даже на взгляд его противников, имеет лучшие шансы на выживание, чем «правильная вещь», и подход Нью-Джерси применительно к программам лучше, чем Массачусетский подход.
Автор предлагает начать с пересказа истории, демонстрирующей, что различие между Массачусетским и Нью-Джерсиевским подходами действительно имеет место, и приверженцы каждой из этих философий действительно верят в то, что их философия лучше.
Две известных персоны, одна из Массачусетса, другая из Беркли (но работающая в Юниксе) встретились однажды, чтобы обсудить некоторые проблемы операционных систем. Персона из Массачусетса была сведуща в ITS (операционная система MTI AI Lab) и просмотрела исходные тексты Юникса. Персона заинтересовалась, как Юникс решает проблему («the PC loser-ing problem», по-русски можно назвать «потеря счётчика команд лоха» – Н.В.Ч.). Проблема возникает, когда программа пользователя вызывает системную программу, чтобы выполнить длительную операцию, которая может иметь высокий статус, например, буферизацию ввода-вывода. Если произойдёт прерывание, то статус программы пользователя должен быть сохранён. Поскольку вызов системной программы производится, как правило, одной командой, счётчик команд программы пользователя не улавливает адекватно статус процесса. Системная программа должна отработать возврат или продолжиться. Правильно было бы вернуться и возобновить программу пользователя с команды, вызвавшей системную программу, таким образом, чтобы программа пользователя вновь вошла в системную программу. Это и называется «потеря счётчика команд лоха» («PC loser-ing»), потому что счётчик команд принудительно возвращается к программе пользователя, а «лох» (loser) -- ласковое наименование пользователя в Массачусетсе.
Парень из Массачусетса не видел текста программы, обрабатывающей этот случай, и спросил парня из Нью-Джерси, как решается проблема. Парень из Нью-Джерси ответил, что народ Юникса в курсе проблемы, но её решение в том, чтобы системная программа всегда заканчивалась, но иногда возможен возврат с кодом ошибки, сигнализирующим о неуспешном завершении действия. Правильная программа пользователя должна проверить код ошибки и определить, не следует ли вызвать системную программу снова. Парень из Массачусетса не одобрил этого решения, поскольку оно не было «правильной вещью».
Парень из Нью-Джерси сказал, что юниксовское решение правильно, поскольку философия Юникса – простота, а «правильная вещь» слишком сложна. К тому же, программисты могут легко вставить в программу дополнительный текст и сделать цикл. Массачусетский парень указал, что реализация проста, однако интерфейс с функциональностью операционной системы усложнился. Парень из Нью-Джерси ответил, что именно для Юникса выбор был сделан правильно, потому что простота реализации важнее простоты интерфейса.
Массачусетский парень пробормотал что-то типа: «нужны крутые мужики, чтобы приготовить нежных цыплят», но парень из Нью-Джерси его не понял (автор не уверен, что он тоже понял).
[Примечание . «Только грубые руки настоящего мужчины могут вырастить нежного цыпленка» -- слоган владельца сети птицефабрик Франка Перду. Справку предоставил Шмайсер: http://www.livejournal.com/userinfo.bml?user=schmeisser , Н.В.Ч.].
Теперь поспорим, что «хуже – лучше» действительно лучше. Си – это язык программирования, созданный для написания Юникса и создавался с подходом Нью-Джерси. Си, таким образом, стал языком, для которого легко написать приличный компилятор, и он требует от программиста писать текст, который легко компилировать. Многие называют Си навороченным ассемблером. И ранний Юникс, и ранние компиляторы Си имели простую структуру, легко переносились с одной ЭВМ на другую, требовали мало машинных ресурсов и предоставляли около 50%..80% процентов того, чего Вы ожидаете от операционной системы или языка программирования.
Половина компьютеров, существующих в произвольный момент времени, хуже среднего современного компьютера (меньше (по памяти, Н.В.Ч.) или медленнее). Юникс и Си прекрасно работают на них. Философия «хуже – лучше» означает, что простота реализации имеет более высокий приоритет, и это обеспечивает простоту установки Юникса и СИ на такие машины. Следовательно, если мы полагаем, что 50% процентов функциональности Юникса и СИ достаточны, то они начнут появляться повсеместно. И они появляются, не так ли?
Юникс и Си – величайшие компьютерные вирусы.
Дальнейший выигрыш от философии !хуже – лучше» происходит от того, что программист поставлен в условия, когда он должен в некоторой степени жертвовать безопасностью, удобством и своими усилиями, чтобы получить хорошее исполнение и скромное использование ресурсов ЭВМ. Программы, написанные в подходе Нью-Джерси, будут работать и на маленькой ЭВМ и на большой. Программы будут переносимы, поскольку написаны на базе вируса.
Важно помнить, что исходный вирус должен быть в основном хорошим. При этом распространение вируса обеспечивается до тех пор, пока он переносим с одной ЭВМ на другую. Когда же вирус распространится, возникнет внешняя потребность в его улучшении, возможно в повышении его функциональности до 90%, но пользователи уже будут приучены воспринимать худшее как «правильную вещь». Таким образом, программы «хуже – лучше» сперва получают распространение. Затем приучают пользователя ожидать меньшего. И, наконец, подвергаются улучшению до состояния «почти правильной вещи». В конкретных терминах сказанное означает, что хотя в 1987 году компиляторы Лисп были практически так же хороши, как компиляторы СИ, сегодня больше компьютерных профессионалов, желающих улучшить компиляторы СИ, чем тех, которые хотят улучшить компиляторы Лисп.
Хорошая новость заключается в том, что в 1995 году мы получим хорошую операционную систему и хороший язык программирования. Плохая новость, что это будут Юникс и Си++.
Есть, всё-таки, и выигрыш от «хуже – лучше». Поскольку язык и система Нью-Джерси не являются действительно достаточно мощными для построения цельного программного обеспечения, большие системы должны создаваться с повторным использованием ранее разработанных компонентов. Таким образом, возобновляется традиция интеграции.
Как растёт «правильная вещь»? Имеются два основных сценария: «сценарий большого комплекса» и сценарий «алмаза».
«Сценарий большого комплекса» развивается так. Сначала «правильная вещь» должна быть спроектирована. Поскольку это – «правильная вещь», и она имеет около 100% процентов желаемой функциональности, а простота реализации никогда не была предметом интереса, то требуется длительное время для реализации «правильной вещи». Она большая и сложная. Она требует сложных инструментов для правильного использования. Последние 20% требуют 80% процентов усилий, и «правильной вещи» требуется длительное время, чтобы выйти в практику, и она может использоваться только на самом изощрённом оборудовании.
Сценарий «алмаза» идёт так. Для проектирования «правильной вещи» требуется бесконечное время, но в любой конкретный момент она ещё весьма мало проработана. Реализовать «правильную вещь» быстро либо невозможно, либо требует запредельных усилий.
Эти два сценария соответствуют Common Lisp и Scheme.
Первый сценарий соответствует также классическому программному обеспечению искусственного интеллекта.
Зачастую «правильная вещь» представляет собой единый кусок программного обеспечения, но единственная причина этого заключается в том, что она реализуется именно единым куском. Поэтому данная характеристика является случайным обстоятельством.
Урок, который следует извлечь, заключается в том, что часто нежелательно сразу идти за «правильной вещью». Лучше получить половину «правильной вещи», чтобы она распространилась как вирус. Когда люди «подсядут» на него, потребуется некоторое время, чтобы довести вирус до 90% «правильной вещи».
Неправильный урок был бы в том, чтобы воспринять литературную параболу буквально и придти к выводу, что Си – это правильное средство для программного обеспечения искусственного интеллекта. Половинные решения в основном правильны, но не в этом случае.
Но следует понять только, что сообществу языка Лисп необходимо серьёзно переосмыслить свою позицию в проектировании Лисп. Автор обещает ещё высказаться об этом.