Проклятие Лиспа
Мощь Лиспа — его главный враг.
Для доказательства проведем мысленный эксперимент: пусть есть два не объектно-ориентированных языка программирования. Если вы готовы, ваша цель — сделать их объектно-ориентированными, сохранив обратную совместимость с исходным языком (возможно, за исключением некоторых краевых случаев) Очевидно, что в любой паре языков, взятых для эксперимента, для одного языка это будет сделать проще, чем для другого. В этом и суть эксперимента. Тривиальный пример: Intercal и Pascal.
Теперь сделаем эксперимент интересным: предположим нам нужно добавить объектную ориентированность в языки C и Scheme. Сделать Scheme объктно-ориентированной это задачка на дом для второкурсника. С другой стороны, реализация объектной ориентированности в С требует программистской хватки Бьёрна Страуструпа.
Эта разница в требуемом таланте и усилиях и является причиной “Проклятия Лиспа”:
Лисп настолько могуч, что проблемы, являющиеся техническими для других языков, становятся для него социальными.
Обратимся еще раз к случаю Scheme. Так как в нее легко добавить объектно-ориентированноcть, это могут многие хакеры. Более того, многие конкретные хакеры так и поступили. В 90-х это привело к поистине огромному списку объектно-ориентированных пакетов для языка. Один лишь парадокс выбора гарантировал, что ни один из них не станет стандартом. Сейчас, когда некоторые реализации Scheme имеют собственные средства для объектно-ориентированного подхода, все уже не так плохо. Тем не менее, тот факт, что большинство этих пакетов были продуктом одиноких разработчиков, привел к проблемам, о которых писал Олин Шиверс в документации к Scheme Shell (scsh).
Программы, написанные одиночками склонны “чесать там, где чешется”. Эти программы решают проблему хакера, игнорируя сопутствующие части, которые могли бы сделать программу более полезной для других. Более того, программа проверена на работоспособность только на окружении хакера, но может быть непереносима на другие реализации Scheme или на ту же реализацию, но под другую платформу. Документация может отсутствовать. Будучи, по сути, проектом, написанным в обильное свободное время, программа может пострадать от реальной жизни, которая обрушится на хакера. Как отметил Олин Шиверс: что эти проекты одного актера обычно решают восемьдесят процентов проблемы.
В эссе доктора Марка Тарвера “Биполярный программист на Лиспе” содержит описание этого феномена. Он пишет об этих хакерах-одиноких волках и их
…неспособности правильно заканчивать дела. Слова “одноразовый проект” отлично подходят для ГБУ1 и они пришли из сообщества Лиспа. Лисп освобождает от кучи вещей с такой простотой, что это легко принять как должное. Я обратил на это внимание, когда 10 лет назад искал интерфейсную библиотеку. Сразу нашлось 9 разных вариантов. Проблема была в том, что ни одна из 9 библиотек не была нормально задокументирована и во всех из них были баги. В сущности, каждый автор реализовал свое собственное решение, которое для него работало и этого было достаточно. Это мировоззрение ГБУ: это работает для меня, и я это понимаю. Это так же следствие отсутствия нужды или желания искать чьей-то помощи.
Еще раз вернемся к мысленному эксперименту, на этот раз к С. Так как его сложно сделать объектно-ориентированным, только две попытки нашли популярность: С++ и Objective-C. Objective-C наиболее популярен на Macintosh, а С++ — на всем остальном. Это означает, что для конкретной платформы вопрос какое объектно-ориентированное расширение С использовать, уже имеет точный ответ. Это означает, что объектно-ориентированные возможности этих языков были задокументированы, что среды разработки о них знают, что код библиотек с ними совместим, и т.д.
Доктор Тарвер в своем эссе отмечает:
В противоположлость этому, подход C/C++ заметно отличается. Чертовски трудно сделать что-то с помощью пинцета и клея, поэтому все что вы сделаете, будет настоящим достижением. Вы захотите это задокументировать. Для работы с достаточно крупным проектом на С вам так же потребуется помощь, вам потребуется общаться и работать с другими. Вам это необходимо, иначе ничего не выйдет.
Все это привлекательно с точки зрения работодателя. Десяток человек, которые общаются, все аккуратно документируют и работают вместе предпочтительнее одного ГБУ с Лиспом, которого можно заменить только другим ГБУ (если получится найти), в случае если ваш вырубится и без шансов на перезагрузку.
Следовательно, знающие С не задаются вопросом: “Какую бы объектную систему мне изучить?”. Вместо этого, они используют C++ или Objective-C, в зависимости от того, на чем пишут коллеги и переходят сразу к “Как мне применить объектно-ориентированный подход X?” Ответ: “Гуглящий да обрящет”.
Настоящие Хакеры, конечно же, давно знают, что объектно-ориентированное программирование это не панацея, что бы ни говорили его адепты. Настоящие Хакеры уже перешли на более продвинутые концепции, такие как неизменяемые структуры данных, интерфейсы типов, ленивые вычисления, монады, стрелочные функции, сопоставление шаблонов, программирование в ограничениях и так далее. Настоящие Хакеры так же давно знают, что С и С++ не подходят для большинства программ, в которых не требуется прямое манипулирование битами. Тем не менее, “Проклятие Лиспа” никуда не исчезло.
Некоторые чопорные любители Лиспа познали текущий урожай академических языков (Haskell, OCaml и т.д.) и нашли его худым, и рекли они, что все их возможности есть уже в Лиспе, или реализуемы легко — и улучшаемы — путем макросов его. Вероятно, они правы.
Жаль их.
Уже дважды процитированный доктор Тарвер написал диалект Лиспа — Qi 2 Язык представляет собой менее чем 10 тыс строк макросов поверх Clisp. В Qi реализована большая часть уникальных особенностей Haskell и OCaml. По некоторым параметрам Qi их превосходит. Например, система интерфейсов типов в Qi полна по Тьюрингу. В мире, где потребовались команды талантливых исследователей чтобы написать Haskell, один человек, доктор Травер, создал Qi в одиночку.
Перечитайте этот параграф еще раз и сделайте выводы.
Задача для читетеля: Предположим, что между Haskell и Common Lisp началась сильная конкуренция. Что будет дальше?
Ответ: Сработает “Проклятие Лиспа”. Каждый второй-третий способный Лиспа хакер выкатит собственную реализацию ленивых вычислений, чистых функций, стрелочных функций, сопоставления шаблонов, интерфейсов типов и прочего. Большая часть этих проектов сделают одиночки. Следовательно, в них будут реализовано 80% функций, которые нужны большинству (разные 80% в каждом случае). Они будут плохо документированы. Будут не переносимы на другие Лисп-системы. Некоторые будут выглядеть многообещающе, пока их не забросит разработчик, которому нужно как-то оплачивать счета. Некоторые победят Haskell по тому или другому параметру (опять, разному в каждом случае), но их развитие увязнет в холиварах на comp.lang.lisp.
Эндшпиль: Случайным образом собранная коллекция макросов олдовых Лисп хакеров будет представлена как недокументированная, непереносимая, забагованная реализация 80% от Haskell, потому что Лисп круче Hakell.
Мораль истории в том, что имеют значение вторичные и третичные эффекты. Технологии влияют не только на то, что мы можем сделать технически, но так же влияют и на наше социальное поведение. Наше социальное поведение может в свою очередь повлиять на исходные технологические проблемы.
Лисп болезнено яркий образец подобного. Лисп настолько могуч, что поощряет индивидуальную независимость, граничащую с полным безумием. Эта независимость породила невероятные инновации во времена Лисп-машин. Эта же независимость затрудняет попытки оживить старые системы c “Лиспом сверху донизу”. Ни одна “Lisp OS” не набрала заметного влияния после заката Symbolics и LMI.
Еще одним из последствий этих вторичных и третичных эффектов является то, что даже если Лисп самый выразительный язык из когда либо созданных, настолько что теоретически невозможно придумать более выразительный, все равно есть вещи, которые лисперы могут узнать из других языков. Парни из Smalltalk научили всех, включая Лисп хакеров, паре трюков в объектно-ориентированном программировании. Язык программирования Clean и связка Mozart/Oz сами по себе содержат несколько сюрпризов.
“Проклятие Лиспа” не противоречит максиме Станислава Датковского: работодатели больше предпочтитают взаимозаменяемых сотрудников продуктивным. Слишком похоже на правду. Трудно пробить алчность управленческого класса. Тем не менее, последние строки его эссе спорны. А именно:
Что касается мира “свободного ПО”, то он рьяно противопоставлет себя промышленным догмам на словах, но не на практике. Никакая концепция, отвергнутая адом опенспейсов, не нашла настоящей поддержки любителей.
В сноске он предлагает Linux в качестве примера нежелания следовать разным идеям. Конечно, он прав, когда речь идет об операционных системах (верхний комментарий, правда, невероятно тупой). Он не прав, когда речь идет о языках программирования. Лисп влиял на Python и Ruby. Многие их фанаты уважают Лисп и их интерес подтолкнул его ренессанс. С некоторой степенью справедливости, JavaScript описывали как “Scheme в маске С”, хотя он вышел из ада опенспейсов.
Тем не менее, невзирая на свое влияние как в корпоративном мире, так и в мире опенсорца, Лисп все еще получает только малую долю умов разрабочиков, которые были привлечены современной порослью продвинутых скриптовых языков. Не может узость мышления MBA быть единственным объяснением. Все лучше объяснимо “Проклятием Лиспа”.
Свободные среды разработки, доступные для Лисп еще более выразительный пример Проклятия.
Стыдно об этом писать, но придется. Забудьте о Лисп-Машине, у нас даже нет среды разработки, которую средний программист на Smalltalk считает естественной (“Я всегда считал что Лисп превосходный язык, а Smalltalk превосходное окружение.” — Рамон Леон). Без тысячедолларовых трат на коммерческое ПО все Лисп хакеры все еще привязаны к Emacs.
Джеймс Гослинг, автор первого Emacs под Unix, правильно отметил, что Emacs практически не изменился за 20 лет. Это происходит из-за того, что разработчики Emacs’а все еще надстраивают код поверх фундамента, который был заложен во времена, когда Emacs был проектом аспиранта MIT AI Lab, иными словами, когда разработка Emacs’а была неявно профинансирована государственным долгом. Слешдоттер может возразить, что Emacs достаточно функциональный и способен на тоже самое, что и любая другая среда разработки, только лучше. Те, кто пользовался Лисп-Машинами, считают иначе.
Итак, почему бы Лисп хакерам не поставить парней со Smalltalk на место? Почему бы им не создать свободную среду разработки, которая напомнила бы об утерянной славе LispM, даже если они не могут воспроизветсти LispM?
“Проклятие Лиспа” — препятствие, которое этому мешает. Потребовалось бы сотрудничество большого количества программистов на Лиспе. Еще раз, медленнее: большому количеству людей которые стали программистами на Лиспе, потребуется сотрудничать друг с другом. Им еще потребуется договариваться друг с другом об архитектуре, которая не была дана изначально. Так же у них не будет внешнего управления в виде венчурного капиталиста или иного корпоративного начальника, который бы держал их в узде.
В каждом проекте есть трения между участниками, разногласия, конфликты по поводу стиля и философии. Эти социальные проблемы нивелируются тем фактом, что без этого нельзя будет завершить ни один крупный проект. “Мы должны держаться вместе, иначе нас, без сомнения, перевешают по одиночке.” Но выразительность Лиспа значительно ослабляет эту противодействующую силу; любой может начать свой собственный проект. Следовательно, любой хакер может решить, что беспокойство того не стоит. Так что они либо выйдут из проекта, либо не присоединятся, чтобы начать. Это — “Проклятие Лиспа”.
Любой даже может нахачить Emacs и получить что-то достаточно хорошее. Поэтому, “Проклятие Лиспа” — союзник Хуже–Лучше.
Выразительная сила Лиспа имеет свои недостатки. Бесплатный сыр — только в мышеловке.