(Эта статья основана на докладе, прочитанном на симпозиуме разработчиков Franz в 2001 году.)
Летом 1995 года мы с моим другом Робертом Моррисом основали стартап под названием Viaweb. Наш план состоял в том, чтобы написать программное обеспечение, которое позволило бы конечным пользователям создавать интернет-магазины. Новым в этом ПО на тот момент было то, что оно работало на нашем сервере, используя обычные веб-страницы в качестве интерфейса.
Конечно, многим в то время могла прийти в голову такая же идея, но, насколько мне известно, Viaweb был первым веб-приложением. Нам эта идея показалась настолько новаторской, что мы назвали компанию в ее честь: Viaweb, потому что наш софт работал через веб (via the Web), а не на настольном компьютере пользователя.
Еще одна необычная черта этого софта заключалась в том, что он был написан в основном на языке программирования Lisp. Это было одно из первых крупных приложений для конечных пользователей, написанных на Lisp, который до тех пор использовался главным образом в университетах и исследовательских лабораториях. [1]
Секретное оружие
Эрик Рэймонд написал эссе «Как стать хакером», где помимо прочего рассказывает начинающим хакерам, какие языки им следует изучать. Он советует начать с Python и Java, так как их легко освоить. Серьезному хакеру также стоит выучить C, чтобы копаться в Unix, и Perl для системного администрирования и cgi-скриптов. Наконец, по-настоящему серьезному хакеру следует подумать об изучении Lisp:
Lisp стоит изучить ради того глубокого чувства просветления, которое вы испытаете, когда наконец постигнете его суть; этот опыт сделает вас лучшим программистом до конца ваших дней, даже если вы никогда больше не будете активно использовать сам Lisp.
Это тот же довод, который обычно приводят в пользу изучения латыни. Она не поможет вам найти работу, разве что профессором классической филологии, но она разовьет ваш ум и сделает вас лучшим автором на тех языках, которыми вы действительно хотите пользоваться, например на английском.
Но постойте. Эта метафора заходит слишком далеко. Латынь не поможет вам найти работу просто потому, что на ней никто не говорит. Если вы напишете что-то на латыни, вас никто не поймет. Но Lisp — это компьютерный язык, а компьютеры говорят на любом языке, на каком вы, программист, им прикажете.
Итак, если Lisp делает вас лучшим программистом, как он утверждает, почему бы вам не захотеть его использовать? Если бы художнику предложили кисть, которая сделает его лучшим живописцем, мне кажется, он захотел бы писать ею все свои картины, не так ли? Я вовсе не пытаюсь подшутить над Эриком Рэймондом. В целом его совет хорош. То, что он говорит о Lisp, — это общепринятая точка зрения. Но в этой общепринятой точке зрения кроется противоречие: Lisp сделает вас лучшим программистом, и все же вы не станете его использовать.
Почему нет? В конце концов, языки программирования — это всего лишь инструменты. Если Lisp действительно позволяет создавать лучшие программы, вам следует его использовать. А если нет, то кому он нужен?
Это не просто теоретический вопрос. Программное обеспечение — чрезвычайно конкурентный бизнес, склонный к естественным монополиям. Компания, которая пишет софт быстрее и качественнее, при прочих равных условиях вытеснит своих конкурентов с рынка. И когда вы создаете стартап, вы ощущаете это особенно остро. В стартапах обычно действует принцип «все или ничего». Вы либо богатеете, либо остаетесь ни с чем. В стартапе, если вы сделаете ставку не на ту технологию, конкуренты вас уничтожат.
И мы с Робертом отлично знали Lisp и не видели причин не довериться нашей интуиции и не выбрать Lisp. Мы знали, что все остальные пишут свой софт на C++ или Perl. Но мы также понимали, что это ничего не значит. Если бы вы выбирали технологии по такому принципу, вы бы сидели на Windows. Выбирая технологию, нужно игнорировать то, что делают другие, и смотреть только на то, что сработает наилучшим образом.
Это особенно справедливо для стартапов. В крупной компании вы можете делать то же самое, что делают все остальные крупные компании. Но стартап не может делать то же самое, что делают все остальные стартапы. Мне кажется, многие этого не понимают, даже работая в стартапах.
Средняя крупная компания растет примерно на десять процентов в год. Поэтому, если вы управляете крупной компанией и делаете все так, как делает средняя крупная компания, вы можете рассчитывать на результаты на уровне средней крупной компании — то есть расти примерно на десять процентов в год.
То же самое произойдет, разумеется, и если вы управляете стартапом. Если вы делаете все так, как делает средний стартап, вам следует ожидать средних результатов. Проблема в том, что средний результат здесь означает банкротство. Выживаемость стартапов намного ниже пятидесяти процентов. Поэтому, если вы управляете стартапом, вам лучше делать что-то необычное. Если нет, у вас проблемы.
Тогда, в 1995 году, мы понимали кое-что, чего, по-моему, не понимали наши конкуренты, и мало кто понимает даже сейчас: когда вы пишете софт, который должен работать только на ваших собственных серверах, вы можете использовать любой язык, какой захотите. Когда вы пишете софт для настольных систем, существует сильное тяготение к написанию приложений на том же языке, на котором написана операционная система. Десять лет назад писать приложения означало писать приложения на C. Но с программным обеспечением на базе Веба, особенно когда у вас есть исходный код как языка, так и операционной системы, вы можете использовать абсолютно любой язык.
Однако эта новая свобода — палка о двух концах. Теперь, когда вы можете использовать любой язык, вам приходится думать о том, какой именно выбрать. Компании, которые пытаются делать вид, будто ничего не изменилось, рискуют обнаружить, что их конкуренты так не думают.
Если можно использовать любой язык, какой вы выберете? Мы выбрали Lisp. С одной стороны, было очевидно, что на этом рынке важна скорость разработки. Мы все начинали с нуля, поэтому компания, способная реализовать новые функции раньше конкурентов, получала огромное преимущество. Мы знали, что Lisp — действительно отличный язык для быстрого написания программ, а серверные приложения усиливают эффект быстрой разработки, потому что вы можете развертывать софт в ту же минуту, когда он готов.
Если другие компании не хотели использовать Lisp, тем лучше. Это могло дать нам технологическое преимущество, а нам была нужна любая помощь, какую только можно получить. Когда мы запускали Viaweb, у нас не было никакого опыта в бизнесе. Мы ничего не смыслили ни в маркетинге, ни в найме людей, ни в привлечении инвестиций, ни в поиске клиентов. Ни у кого из нас никогда не было даже того, что можно назвать настоящей работой. Единственное, в чем мы были хороши, — это в написании софта. Мы надеялись, что это нас спасет. Любое преимущество, которое мы могли получить по программной части, мы были готовы использовать.
Так что можно сказать, что использование Lisp было экспериментом. Наша гипотеза заключалась в том, что если мы напишем наш софт на Lisp, мы сможем внедрять функции быстрее конкурентов, а также делать в наших программах вещи, на которые они не способны. А поскольку Lisp настолько высокоуровневый, нам не понадобится большая команда разработчиков, и наши расходы будут ниже. Если это окажется правдой, мы сможем предложить лучший продукт за меньшие деньги и при этом оставаться в прибыли. В итоге мы получим всех пользователей, конкуренты не получат никого и со временем обанкротятся. Во всяком случае, именно на это мы надеялись.
Каковы же были результаты этого эксперимента? Как ни странно, это сработало. Со временем у нас появилось множество конкурентов, порядка двадцати-тридцати, но ни одна из их программ не могла сравниться с нашей. У нас был онлайн-конструктор магазинов с интерфейсом wysiwyg, который работал на сервере, но ощущался как настольное приложение. У конкурентов были cgi-скрипты. И по функционалу мы всегда опережали их на голову. Порой отчаявшиеся конкуренты пытались вводить возможности, которых не было у нас. Но благодаря Lisp наш цикл разработки был настолько быстр, что иногда мы могли повторить новую функцию через день или два после того, как конкурент объявлял о ней в пресс-релизе. К тому времени, когда журналисты, освещавшие пресс-релиз, добирались до нас с расспросами, эта новая функция уже была и у нас.
Конкурентам, должно быть, казалось, что у нас есть какое-то тайное оружие — будто мы перехватываем и расшифровываем их трафик «Энигмы» или что-то в этом роде. На самом деле у нас действительно было тайное оружие, но оно было проще, чем они думали. Никто не сливал нам информацию об их новых функциях. Просто мы были способны разрабатывать софт быстрее, чем кто-либо считал возможным.
Когда мне было лет девять, мне случайно попалась книга Фредерика Форсайта «День Шакала». Главный герой — наемный убийца, нанятый для ликвидации президента Франции. Киллеру нужно пройти мимо полиции, чтобы подняться в квартиру, откуда открывается вид на маршрут президента. Он проходит прямо перед ними, замаскировавшись под старика на костылях, и у них не возникает никаких подозрений.
Наше секретное оружие было устроено похоже. Мы написали наш софт на странном языке из сферы ИИ, с причудливым синтаксисом, переполненным скобками. Годами меня раздражало, когда Lisp описывали подобным образом. Но теперь это сыграло нам на руку. В бизнесе нет ничего более ценного, чем техническое преимущество, которого ваши конкуренты не понимают. В бизнесе, как и на войне, внезапность стоит не меньше, чем сила.
И поэтому, мне даже немного неловко это признавать, пока мы работали над Viaweb, я никогда публично ничего не говорил о Lisp. Мы никогда не упоминали его для прессы, и если бы вы поискали слово Lisp на нашем сайте, то нашли бы только названия двух книг в моей биографии. Это было не случайно. Стартап должен давать своим конкурентам как можно меньше информации. Если они не знали, на каком языке написан наш софт, или им было все равно, я хотел, чтобы так оно и оставалось.[2]
Людьми, которые лучше всего понимали нашу технологию, были клиенты. Им тоже было плевать, на каком языке написан Viaweb, но они замечали, что он работает исключительно хорошо. Он позволял им создавать отличные интернет-магазины буквально за считанные минуты. И благодаря этому, главным образом по «сарафанному радио», у нас становилось все больше и больше пользователей. К концу 1996 года у нас было около 70 работающих магазинов. В конце 1997 года — уже 500. Шесть месяцев спустя, когда Yahoo купила нас, у нас было 1070 пользователей. Сегодня, под именем Yahoo Store, этот софт продолжает доминировать на своем рынке. Это одна из наиболее прибыльных частей Yahoo, а магазины, построенные с его помощью, составляют основу Yahoo Shopping. Я ушел из Yahoo в 1999 году, поэтому не знаю точно, сколько у них пользователей сейчас, но, по последним данным, их было около 20 000.
Парадокс Блаба
Чем же так хорош Lisp? И если Lisp так хорош, почему им не пользуются все? Эти вопросы звучат как риторические, но на самом деле на них есть прямые ответы. Lisp так хорош не из-за какого-то магического свойства, видимого лишь посвященным, а потому, что это просто самый мощный из доступных языков. А причина, по которой им пользуются не все, заключается в том, что языки программирования — это не просто технологии, но и образ мыслей, а ничто не меняется медленнее привычек ума. Разумеется, оба эти ответа требуют пояснений.
Я начну с шокирующе спорного утверждения: языки программирования различаются по своей мощи.
Мало кто станет спорить хотя бы с тем, что языки высокого уровня мощнее машинного языка. Большинство современных программистов согласятся, что в обычных условиях писать на машинном языке не стоит. Вместо этого следует программировать на языке высокого уровня, доверив компилятору перевод в машинный язык за вас. Эта идея сейчас заложена даже в «железо»: начиная с 1980-х годов наборы инструкций проектируются в расчете на компиляторы, а не на живых программистов.
Все знают, что писать всю программу вручную на машинном языке — ошибка. Менее очевиден более общий принцип: если у вас есть выбор из нескольких языков, то, при прочих равных условиях, писать на чем-либо, кроме самого мощного из них, — ошибка. [3]
У этого правила есть множество исключений. Если вы пишете программу, которая должна очень тесно взаимодействовать с кодом, написанным на определенном языке, возможно, имеет смысл написать новую программу на том же языке. Если вы пишете программу, которая должна выполнять лишь что-то очень простое, вроде численных расчетов или побитовых манипуляций, вы вполне можете использовать менее абстрактный язык, особенно если он окажется немного быстрее. А если вы пишете короткую одноразовую программку, вам может быть выгоднее просто взять язык с наиболее подходящими для этой задачи библиотечными функциями. Но в целом, для прикладного софта вам нужен самый мощный (и приемлемо эффективный) язык из тех, что вы можете получить, а выбор чего-то другого — ошибка ровно того же свойства (хотя, возможно, и в меньшей степени), что и программирование на машинном языке.
Понятно, что машинный язык — это очень низкий уровень. Но, по крайней мере в силу некоего общественного соглашения, языки высокого уровня часто воспринимаются как равноценные. Это не так. С технической точки зрения термин «язык высокого уровня» не означает ничего определенного. Нет четкой разделительной линии, по одну сторону которой стояли бы машинные языки, а по другую — все языки высокого уровня. Языки располагаются вдоль континуума [4] абстрактности: от самых мощных в самом верху и до машинных языков, которые сами по себе различаются по выразительности.
Возьмем Cobol. Cobol — это язык высокого уровня в том смысле, что он компилируется в машинный код. Станет ли кто-нибудь всерьез утверждать, что Cobol эквивалентен по мощи, скажем, Python? Он, вероятно, ближе к машинному языку, чем Python.
Или как насчет Perl 4? Между Perl 4 и Perl 5 в язык были добавлены лексические замыкания. Большинство перл-хакеров согласятся, что Perl 5 мощнее Perl 4. Но признав это, вы признаете, что один язык высокого уровня может быть мощнее другого. И отсюда неизбежно следует, что за исключением особых случаев вы должны использовать самый мощный язык, какой только можете получить.
Однако этой идее редко следуют до конца. Достигнув определенного возраста, программисты редко меняют языки по собственной воле. К какому бы языку люди ни привыкли, они склонны считать его вполне достаточным.
Программисты очень привязываются к своим любимым языкам, и я не хочу никого обидеть, поэтому для иллюстрации этой мысли я воспользуюсь гипотетическим языком под названием Блаб (Blub). Блаб находится ровно посередине шкалы абстрактности. Это не самый мощный язык, но он мощнее Cobol или машинного языка.
И действительно, наш гипотетический программист на Блабе не стал бы использовать ни тот, ни другой. Само собой, он не станет программировать на машинном языке. Для этого и существуют компиляторы. Что касается Cobol, он вообще не понимает, как на нем можно что-то сделать. Там ведь нет даже x (подставьте любую функцию Блаба на свой выбор).
Пока наш гипотетический программист на Блабе смотрит вниз по шкале мощности, он понимает, что смотрит вниз. Языки, уступающие Блабу в мощи, очевидно слабее, потому что в них отсутствуют те или иные привычные ему возможности. Но когда наш программист на Блабе смотрит в противоположном направлении, вверх по шкале мощности, он не осознает, что смотрит вверх. То, что он видит, кажется ему просто какими-то странными языками. Вероятно, он считает их примерно равными Блабу по силе, но перегруженными всякими непонятными наворотами. Блаба ему вполне хватает, потому что он мыслит на Блабе.
Однако когда мы переходим на точку зрения программиста, использующего любой из языков, стоящих выше по шкале мощности, мы обнаруживаем, что он, в свою очередь, смотрит на Блаб сверху вниз. Как вообще можно что-то толковое написать на Блабе? Там ведь нет даже y.
По индукции, единственные программисты, способные увидеть все различия в мощи языков, — это те, кто понимает самый мощный из них. (Вероятно, именно это имел в виду Эрик Рэймонд, говоря о том, что Lisp делает вас лучшим программистом.) Мнениям остальных доверять нельзя из-за парадокса Блаба: они довольны тем языком, на котором им довелось писать, потому что он определяет сам способ их мышления о программах.
Я знаю это по собственному опыту, когда старшеклассником писал программы на Basic. Этот язык не поддерживал даже рекурсию. Сейчас трудно представить написание программ без использования рекурсии, но в то время мне ее не хватало. Я мыслил на Basic. И был в этом асом. Полноправным хозяином всего, что видел вокруг.
Пять языков, которые Эрик Рэймонд рекомендует хакерам, занимают разные точки на шкале мощности. Где именно они располагаются относительно друг друга — тема щекотливая. Я лишь скажу, что считаю Lisp стоящим на самой вершине. И в подтверждение этого утверждения я расскажу об одной вещи, которой мне не хватает, когда я смотрю на остальные четыре языка. Как вообще можно что-то на них писать, думаю я, без макросов? [5]
Во многих языках есть нечто под названием «макрос». Но макросы Lisp уникальны. И хотите верьте, хотите нет, но их работа напрямую связана со скобками. Создатели Lisp добавили все эти скобки в язык вовсе не для того, чтобы выделиться. Программисту на Блабе код на Lisp кажется странным. Но эти скобки там не просто так. Они являются внешним свидетельством фундаментального отличия Lisp от других языков.
Код на Lisp состоит из объектов данных Lisp. И не в том тривиальном смысле, что исходные файлы состоят из символов, а строки являются одним из поддерживаемых языком типов данных. Код Lisp после того, как его прочитал парсер, состоит из структур данных, по которым можно перемещаться.
Если вы понимаете, как устроены компиляторы, то на самом деле все дело не столько в странном синтаксисе Lisp, сколько в том, что у Lisp вообще нет синтаксиса. Вы пишете программы прямо в деревьях разбора, которые в других языках генерируются внутри компилятора при парсинге. Но эти деревья разбора полностью доступны вашим программам. Вы можете писать программы, которые манипулируют ими. В Lisp такие программы называются макросами. Это программы, которые пишут программы.
Программы, которые пишут программы? Зачем это вообще может понадобиться? Не так уж часто, если вы мыслите на Cobol. Постоянно, если вы мыслите на Lisp. Было бы очень удобно, если бы я мог привести здесь пример мощного макроса и сказать: «Вот! Каково, а?» Но если бы я это сделал, человеку, не знающему Lisp, это показалось бы просто абракадаброй; здесь недостаточно места, чтобы объяснить все, что нужно знать для понимания сути. В книге Ansi Common Lisp я старался двигаться вперед как можно быстрее, и даже при этом добрался до макросов только на 160-й странице.
Но думаю, я могу привести довод, который может показаться убедительным. Исходный код редактора Viaweb состоял из макросов примерно на 20–25%. Макросы писать сложнее, чем обычные функции Lisp, и использовать их без необходимости считается плохим стилем. Поэтому каждый макрос в том коде находился там потому, что без него было не обойтись. А это значит, что как минимум 20–25% кода в этой программе делали вещи, которые невозможно легко реализовать на каком-либо другом языке. Каким бы скептичным ни был программист на Блабе по отношению к моим утверждениям о таинственной силе Lisp, это должно пробудить в нем любопытство. Мы писали этот код не ради собственного развлечения. Мы были крошечным стартапом и выкладывались на полную мощность, чтобы создать технический барьер между нами и конкурентами.
Человек подозрительный мог бы задуматься, нет ли здесь какой-то взаимосвязи. Значительная часть нашего кода делала вещи, которые чрезвычайно трудно реализовать на других языках. Получившийся софт делал то, чего не мог софт наших конкурентов. Возможно, между этим была определенная связь. Советую вам потянуть за эту ниточку. За этим стариком, ковыляющим на костылях, может скрываться нечто большее, чем кажется на первый взгляд.
Айкидо для стартапов
Но я не рассчитываю убедить кого-либо (старше 25 лет) пойти и выучить Lisp. Цель этой статьи — не переубедить кого-то, а подбодрить тех, кто уже интересуется использованием Lisp, — людей, которые знают, что Lisp — мощный язык, но беспокоятся из-за того, что он не имеет широкого распространения. В конкурентной ситуации это лишь плюс. Мощь Lisp умножается на тот факт, что ваши конкуренты его не понимают.
Если вы подумываете об использовании Lisp в стартапе, вам не стоит переживать из-за того, что его мало кто понимает. Вам следует надеяться, что все так и останется. И скорее всего, так оно и будет. Природа языков программирования такова, что большинство людей вполне довольны тем, чем пользуются прямо сейчас. Компьютерное «железо» меняется намного быстрее, чем человеческие привычки, поэтому практика программирования обычно отстает от процессора на десять-двадцать лет. В таких местах, как MIT, программы на языках высокого уровня писали еще в начале 1960-х, однако многие компании продолжали писать код на машинном языке вплоть до 1980-х годов. Готов поспорить, многие продолжали бы писать на машинном языке до тех пор, пока процессор, подобно бармену, стремящемуся поскорее закрыть заведение и уйти домой, наконец не выставил их вон, перейдя на набор инструкций risc.
Обычно технологии меняются стремительно. Но языки программирования устроены иначе: они представляют собой не просто технологию, а язык, на котором думают программисты. Они наполовину технология, наполовину религия.[6] И потому медианный язык, то есть тот, на котором пишет среднестатистический программист, движется со скоростью айсберга. Сборка мусора, появившаяся в Lisp около 1960 года, сейчас повсеместно считается благом. Динамическая типизация — то же самое — становится все более популярной. Лексические замыкания, внедренные в Lisp в начале 1970-х, сейчас лишь едва-едва появились на радарах. Макросы, появившиеся в Lisp в середине 1960-х, до сих пор остаются terra incognita.
Очевидно, что медианный язык обладает колоссальной инерцией. Я не предлагаю вам бороться с этой мощной силой. Я предлагаю прямо противоположное: подобно мастеру айкидо, использовать ее против своих оппонентов.
Если вы работаете в крупной компании, провернуть это может быть непросто. Вам будет трудно убедить остроконечного босса позволить вам разрабатывать продукт на Lisp, когда он только что прочитал в газете, что какой-то другой язык вот-вот завоюет весь мир — точно так же, как Ada двадцать лет назад. Но если вы работаете в стартапе, где остроконечных боссов еще нет, вы можете, как и мы, обернуть парадокс Блаба в свою пользу: использовать технологию, за которой ваши конкуренты, намертво прикованные к медианному языку, никогда не смогут угнаться.
Если вам когда-нибудь доведется работать в стартапе, вот полезный совет, как оценивать конкурентов. Читайте их вакансии. Все остальное на их сайте может быть стоковыми фотографиями или их текстовым эквивалентом, но в вакансиях они обязаны четко указывать, кто им нужен, иначе они наймут не тех людей.
За те годы, что мы работали над Viaweb, я прочитал огромное количество описаний вакансий. Казалось, что новый конкурент появлялся словно из ниоткуда каждый месяц или около того. Первым делом после проверки наличия у них работающего онлайн-демо я открывал список вакансий. Спустя пару лет такой практики я уже мог безошибочно определить, о каких компаниях стоит беспокоиться, а о каких — нет. Чем сильнее от описания вакансий веяло корпоративным «ИТ», тем менее опасной была компания. Самыми безобидными были те, кому требовался опыт работы с Oracle. О них можно было вообще не волноваться. Точно так же можно было спать спокойно, если они искали разработчиков на C++ или Java. Если же они искали программистов на Perl или Python, это уже слегка настораживало — это начинало напоминать компанию, где технической частью, по крайней мере, заправляют настоящие хакеры. А вот если бы я хоть раз увидел объявление о поиске хакеров на Lisp, я бы всерьез забеспокоился.
Примечания
[1] Вначале Viaweb состоял из двух частей: редактора, написанного на Lisp, с помощью которого пользователи создавали свои сайты, и системы обработки заказов, написанной на C. Первая версия была написана преимущественно на Lisp, поскольку система заказов была небольшой. Позже мы добавили еще два модуля: генератор изображений на C и интерфейс бэк-офиса, написанный в основном на Perl.
В январе 2003 года Yahoo выпустила новую версию редактора, написанную на C++ и Perl. Сложно сказать, перестал ли редактор быть написанным на Lisp, поскольку для его перевода на C++ им буквально пришлось написать интерпретатор Lisp: исходные файлы всех генерирующих страницы шаблонов, насколько мне известно, всё ещё представляют собой код на Lisp. (См. Десятое правило Гринспена.)
[2] Роберт Моррис говорит, что мне не нужно было делать из этого секрет, потому что даже если бы конкуренты узнали, что мы используем Lisp, они бы не поняли почему: «Если бы они были настолько умны, они бы уже программировали на Lisp».
[3] Все языки одинаково мощны в смысле тьюринг-полноты, но это не то значение слова, которое волнует программистов. (Никто не хочет программировать машину Тьюринга.) Та мощь, которая важна для программистов, возможно, не поддаётся формальному определению, но один из способов объяснить её — сказать, что она относится к возможностям, которые в менее мощном языке можно получить, только написав на нём интерпретатор более мощного языка. Если в языке A есть оператор для удаления пробелов из строк, а в языке B его нет, это вряд ли делает A более мощным, так как для реализации этого в B вы, вероятно, можете написать подпрограмму. Но если A поддерживает, скажем, рекурсию, а B нет, то это вряд ли получится исправить написанием библиотечных функций.
[4] Примечание для ботаников: или, возможно, решётка, сужающаяся кверху; здесь важна не форма, а идея о том, что существует хотя бы частичный порядок.
[5] Рассматривать макросы как отдельную фичу немного обманчиво. На практике их полезность значительно усиливается другими возможностями Lisp, такими как лексические замыкания и rest-параметры.
[6] В результате сравнения языков программирования либо принимают форму священных войн, либо представляют собой университетские учебники, настолько подчеркнуто нейтральные, что по сути являются трудами по антропологии. Люди, которые дорожат своим спокойствием или хотят получить бессрочный профессорский контракт, избегают этой темы. Но этот вопрос лишь наполовину религиозный; здесь есть что изучать, особенно если вы хотите разрабатывать новые языки.