Почему Python?

Перевод статьи Эрика Рэймонда "Why Python?" (перевод не закончен).

Оригинал статьи

Мой первый взгляд на Python был случайным, и тогда мне не очень-то понравилось то, что я увидел. Это было в начале 1997, и книжка Марка Лутца "Программирование на Python" от O'Reilly & Associates только что вышла. Книжки O'Reilly время от времени оказываются у меня на пороге, выбранные среди новых изданий каким-то таинственным добродетелем, находящимся внутри организации, по случайному принципу, который я уже отчаялся понять.

Одной из них оказалась "Программирование на Python". Это заинтересовало меня, так как я коллекционирую компьютерные языки. Я знаю две с лишним дюжины языков общего назначения, пишу компиляторы и интерпретаторы ради забавы; также я самостоятельно разработал несколько языков специального назначения и правил разметки. Мой последний завершенный проект на момент написания этой статьи — это язык специального назначения под названием SNG для операций с PNG (Portable Network Graphics) изображениями. Интересующиеся читатели могут зайти на страничку SNG по адресу http://www.catb.org/~esr/sng/. Я также написал несколько реализаций необычных языков общего назначения на моей страничке Retrocomputing Museum, http://www.catb.org/retro/.

На тот момент я уже достаточно слышал о Python, чтобы знать, что это, как сейчас говорят, "скриптовый язык" - интерпретируемый язык со встроенным управлением памятью и хорошими возможностями для вызовов и работы с другими программами. Так что я "нырнул в Python", задавая себе единственный вопрос: что в нем есть такого, чего нет в Perl?

Perl это восьмисотфунтовая горилла среди современных скриптовых языков. Он во многом заменил шелл в качестве скриптового языка для многих системных администраторов благодаря его всеобъемлющему набору UNIX библиотек и системных вызовов, а также огромной коллекции модулей, созданных очень активным сообществом Perl. Он также часто рассматривается как CGI язык, стоящий за более чем 85% "живого" Интернета. Larry Wall, его создатель, по праву считается одним из важнейших лидеров сообщества Open Source и часто ставится на третье место (после Линуса Торвальдса и Ричарда Столлмана) в пантеоне хакерских полубогов.

В то время я использовал Perl для нескольких небольших проектов. Я считал его достаточно мощным, хотя синтаксис и некоторые другие аспекты казались нерегламентированными и "способными укусить", если использовать их неаккуратно. Мне казалось, что Python будет просто "еще одним холмом, на который предстоит взойти" при изучении скриптовых языков, так что во время чтения я, прежде всего, искал отличия от Perl.

Я сразу же споткнулся на этой странной особенности Python, которую все замечают: отступы имеют значение в синтаксисе языка. В языке отсутствует аналог конструкций со скобками, как в C или Perl; вместо этого группы выражений разделяются путем смены величины отступа. И, как и большинство хакеров, впервые столкнувшихся с этим, я отреагировал неприязнью.

Я достаточно стар, чтобы успеть попрограммировать на FORTRAN в 1970. Большинство хакеров не застали эти времена, но каким-то образом в нас живет память о том, какими ужасными были эти старые языки с фиксированными полями. Действительно, термин "свободный формат", который использовался для описания нового стиля синтаксиса в Pascal и C, уже почти забыт; на протяжении десятилетий все языки разрабатываются именно так. Ну или почти все. Нельзя осуждать человека за то, что его реакция на эту особенность Python похожа на ту, которая бывает, если случайно наступить в огромную дымящуюся динозавровую какашку.

Именно это я и ощутил. Я прошелся по остальному описанию языка без особого интереса. Я не мог сказать ничего хорошего о Python, кроме, пожалуй, того, что синтаксис выглядел чище чем в Perl, и были неплохие возможности для создания базовых GUI-элементов, таких как кнопки и меню.

Я поставил книжку на полку, отметив для себя, что надо будет когда-нибудь сделать GUI-приложение на Python, просто чтобы убедится, что я действительно понял язык. Но я не верил в то, что увиденное мною может эффективно сравниться с Perl.

Оставшаяся часть 1997 года была насыщенной событиями; среди прочего это был год, когда я написал и опубликовал первоначальную версию "The Cathedral and the Bazaar". Но я нашел время, чтобы написать несколько программ на Perl, две из которых имели значительный размер и были достаточно сложными. Одна из них, keeper, это помощник, который до сих пор используется для регистрации поступлений в архив программного обеспечения Metalab. Он генерирует веб-страницу, которую вы можете увидеть по адресу http://metalab.unc.edu/pub/Linux/!INDEX.html. Другая, anthologize, использовалась для автоматической генерации PostScript для шестого издания Linux из архива HOWTO проекта документации Linux. Обе программы доступны на Metalab.

Создание этих программ делало меня все менее удовлетворенным Perl. Большой размер проекта преумножал недостатки Perl, делая их серьезной проблемой. Синтаксис, который выглядел слегка странноватым в пару сотен строк, начинал казаться непроходимой стеной колючек на тысяче строк. "Несколько способов сделать одно и то же" придавало выразительность при малых масштабах, но значительно усложняло поддержку единого стиля в большом проекте.

Вместе эти проблемы значительно усложняли чтение и понимание кода на Perl уже через несколько дней после его написания. Оказалось, что я трачу больше времени на борьбу с артефактами языка, чем на решение проблем, непосредственно связянных с приложением. Но самое плохое было в том, что получившийся код выглядел уродливым, а это имеет значение! Уродливые программы — как уродливые подвесные мосты. Кажется, что они более склонны к тому, чтобы рухнуть, чем симпатичные, потому что люди (особенно инженеры) считают красоту тесно связанной с нашей способностью понимать и оперировать чем-то сложным. Язык, который усложняет написание красивого кода, усложняет написание хорошего кода.

В середине 1997 года я начал поиски более элегантного скриптового языка.

Разумеется, я и не думал о возвращении к C. Давно прошли те времена, когда имела значение возможность самостоятельно управлять памятью, если не считать те немногие узкоспециализированные области, такие как разработка ядра, научные вычисления и трехмерная графика, где абсолютно необходимо получить максимальную скорость и полный контроль над использованием памяти, потому что необходимо выжать максимум из аппаратного обеспечения.

Для большинства ситуаций глупо было бы смиряться с утомительной отладкой при переполнении буфера, проблемах с псевдонимами указателей, утечках памяти malloc/free и другими подобными неприятностями, учитывая возможности современных машин. Лучше отдать несколько циклов и несколько килобайт памяти в распоряжение менеджера памяти скриптового языка и сэкономить намного более ценное человеческое время. Действительно, преимущества такой стратегии и послужили причиной огромного распространения Perl с середины девяностых.

Я баловался с Tcl, но только лишь для того, чтобы обнаружить, что он масштабируется еще хуже, чем Perl. Будучи старым LISP'ером, я также рассматривал современные диалекты LISP и Scheme, но, как это обычно было с LISP, большая часть умного дизайна становилась почти бесполезной из-за скудной или вообще отсутствующей документации, неполного доступа к возможностям POSIX/UNIX, и маленького и при этом очень разрозненного сообщества разработчиков. Популярность Perl не была случайностью: большинство его конкурентов либо были еще менее пригодны для больших проектов, либо не были настолько полезными, насколько их должен был сделать теоретически превосходный дизайн.