Привет, Хабр! Вашему вниманию представляется перевод статьи "The Origins of Python" за авторством Ламберта Меертенса - соавтора языка ABC и коллеги Гвидо ван Россума.

В своей статье Меертенс вспоминает как зарождалось программирование, своё участие в разработке языка ABC, знакомство с молодым Гвидо ван Россумом и зарождение языка Python.

Перевод предоставил Макс, авторов YouTube-канала PyLounge. Поехали!

В воскресенье, 21 июня 1970 года, в офисном здании на Грейт-Портланд-стрит в Лондоне ожил телетайп. Под заголовком "Счастливые семьи" печатная машинка выдала последовательность английских предложений, таких как "Собака сидит на ребенке" и "Дядя Тед играет с сестрой". Программа "Счастливые семьи", которая выдала такой результат, была написана в те же выходные человеком без опыта программирования, участником семинара, организованного Обществом компьютерных искусств и предлагавшего курс "non-numerical programming".

Почти пятьдесят лет спустя, 26 октября 2019 года, в Стамбуле, глаза молодой женщины загорелись, когда ей удалось запустить свою самую первую программу. Она участвовала в семинаре, организованном Django Girls, международной некоммерческой организацией, целью которой является расширение прав и возможностей женщин посредством бесплатных однодневных воркшопов по программированию.

На семинаре в Лондоне в 1970 году использовался язык программирования TELCOMP, простой неструктурированный язык, похожий на BASIC - не BASIC, как сейчас, а неструктурированный BASIC, как тогда. Языком программирования на воркшопе в Стамбуле в 2019 году был Python, язык программирования, разработанный Гвидо ван Россумом, который стал дико популярным, неуклонно набирая популярность с момента незаметного релиза в 1991 году. Как бы ни были далеки друг от друга эти события, как во времени, так и в географии, их связывает дуга истории.

Давным-давно

Чтобы полностью объяснить связь между этими двумя событиями, я должен сначала вернуться на сцену программирования конца 1960-х годов. Действующие лица – это Лео Геуртс, тогда ещё программист, и я, младший научный сотрудник, оба работали в Математическом центре в Амстердаме, известном в то время как MЦ (MC), но позже переименованном в Центр математики и информатики (Centrum Wiskunde & Informatica, CWI). MЦ предоставил нам значительную свободу выбора тем для исследований, которые, в общем-то, были связаны с изучением границ того, что можно заставить делать компьютеры. В течение некоторого времени мы изучали возможности использования компьютеров в искусстве и музыке - не в качестве дорогого спирографа или музыкальной шкатулки, а в качестве верного слуги, создающего произведения по алгоритмическим правилам нашего собственного изобретения, которые, как мы надеялись, воплощают творческие принципы. Мы вступили в Общество компьютерного искусства, когда оно было основано в 1968 году, и стали его активными членами, а также работали преподавателями или наставниками на обучающих семинарах, например, на том мероприятии 1970 года в Лондоне. Настольных персональных компьютеров тогда еще не существовало, и вообще очень немногие видели компьютер вживую. Участники воркшопа - художники, композиторы и архитекторы - не знали языков программирования; за два дня мы должны были обучить их языку программирования и принципам программирования.

Обычным методом выполнения программ в те дни была пакетная обработка (batch processing). Программисты сдавали свои программы в виде пачки перфокарт или рулона перфоленты на стойку вычислительного центра и - при условии, что в программе не было фатальной ошибки - могли рассчитывать получить результат работы своего кода через пару часов или на следующий день. Такая схема не подошла бы для курсов, рассчитанных на два дня. Но TELCOMP был тем, что в те дни называли "разговорным языком"; в сегодняшней терминологии мы бы сказали, что "выполнение было интерактивным". Телетайп служил терминалом, подключенным к мэйнфрейму с операционной системой разделения времени, от компании Time Sharing, Ltd. Набрав программу в виде пронумерованной последовательности шагов, пользователь мог подать команду DO, чтобы запустить программу и получить результат выполнения немедленно.

Изучение языка было простым. В репертуаре TELCOMP было всего пятнадцать команд и два типа данных: числа и массивы чисел. Но его использование для преобразования задумки в код стало узким местом при разработке. Все команды и типы были реализованы на очень низком уровне, что отличалось от идеи той простоты, которую они хотели воплотить в жизнь. Они не предлагали подходящих средств для правильного структурирования и организации кода. Даже самые простые проекты быстро превращались в так называемый "спагетти-код”.

Конечно, мы знали, что существуют гораздо лучшие языки, такие как ALGOL 60. Полноценный ALGOL 60 был, возможно, более сложным, чем это было необходимо для данной конкретной цели, но мы могли бы преподавать его упрощенный диалект. Мы не использовали ALGOL 60, потому что он не был разработан как подходящий для общего использования.

Дизайн и простота языка программирования

За исключением нескольких языков программирования, которые были намеренно созданы в качестве шутки, например, INTERCAL, разработчик языка не будет делать язык трудным для изучения или использования. Простота изучения и простота использования являются очень желательными атрибутами любого языка программирования. Тем не менее, я часто чувствовал, что этому аспекту проектирования языка не всегда уделяется должное внимание. И то, что может показаться легким для разработчика языка, не обязательно будет легким для изучающего этот язык.

Прежде всего, язык программирования - это инструмент для выражения алгоритмических идей в форме, понятной для выполнения автоматической машиной. Проектирование функционального инструмента - это не наука; оно включает в себя поиск баланса между потенциально противоречивыми конструкторскими задачами. Язык программирования общего назначения - это тоже набор инструментов, состоящий из частей, которые должны плавно сочетаться друг с другом, чтобы работать вместе разнообразными способами, подобно тому, как можно бесконечно комбинировать части набора Meccano. Для всех языков, кроме самых простых, разработчику языка необходимо принять сотни решений. Разумный выбор из всех возможностей требует осознания проектируемого дизайна и готовности исследовать его, а также способности определять компромиссы и рассматривать альтернативы. Здесь философия дизайна может стать руководством для дизайнера. Она может быть изложена в виде ряда правил проектирования, которые не могут быть жесткими и незыблемыми, но все же должны отражать цели разработчика.

Простота инструмента имеет два различных аспекта: простота изучения его функций и простота его использования после осознания этих функций. Задача программиста - воплотить идею в код. Этот процесс будет значительно проще, если элементы языка программирования ориентированы на задачу и соответствуют концепциям, которые программист держит в голове. На первый взгляд может показаться, что эти два аспекта противоречат друг другу. Действительно, минималистский язык, хотя и прост в изучении, может усложнить задачу программиста. Мало того, что требуется больше строк кода, так еще и написание корректного кода становится все сложнее по мере увеличения размера программы. И наоборот, если попытаться сделать что-то похожее на швейцарский нож и включить в него все мыслимые и немыслимые функции, получится сложный язык, который будет трудно изучить, но, несомненно, легко использовать. Или не будет? Возможно, не будет.

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

Проект ABC

В течение нескольких лет, проведенных на семинарах по программированию для художников, в основном в Великобритании и Нидерландах, мы с Геуртсом все больше разочаровывались в недостатках доступных нам языков. "Почему нет языка, - задавались мы вопросом, - который сочетал бы в себе лучшее из двух миров: мощь и простую элегантность ALGOL 60 со скромным размером и пригодностью для повседневного использования BASIC и TELCOMP?". Наше разочарование послужило толчком к старту проекта по разработке такого языка в 1975. Я наблюдал за процессом разработки ALGOL 68, задуманного как амбициозный преемник ALGOL 60, а также был свидетелем его ревизии между 1970 и 1974 годами. В обоих случаях очевидные улучшения не были включены, потому что они были предложены "слишком поздно", поэтому я знал, что будет разумно предусмотреть несколько итераций в процессе разработки. Мы также решили не выбирать название для нового языка до того, как будем довольны результатом. Для обозначения языка мы выбрали имя переменной B для неинициализированной строковой переменной, которая служила в качестве временной, пока процесс проектирования не был завершен. Буква "B" была выбрана потому, что это первая буква слова "новичок" (biginner), и потому, что проект должен был стать языком для обучения программированию абсолютных новичков. В соответствии с математической традицией для имен переменных, мы выделили ее курсивом. В первом приближении, версии B0, мы еще не задумывались; это был скорее эксперимент, чтобы посмотреть, что нам нравится, а что нет. В конце концов, эта версия была закончена и опубликована в течение года. Несмотря на то, что конечные результаты сильно отличаются, некоторые вещи оставались неизменными на протяжении всех итераций. Команда PUT 1, 2 IN A, B присваивала значение 1 переменной с именем A и значение 2 переменной с именем B. Команда PUT A, B IN B, A меняет местами содержимое этих двух переменных. В большинстве других языков такая замена требует трех шагов с использованием третьей, вспомогательной переменной: (1) PUT A IN X; (2) PUT B IN A; и (3) PUT X IN B. В более поздних итерациях, когда устройства ввода-вывода стали допускать смешанное использование верхнего и нижнего регистра, команда превратилась в PUT a, b IN b, a, но сама структура команды для присвоения и сопутствующего присвоения нескольких значений осталась неизменной. Еще более поразительным является использование отступов. Хотя в программах, написанных на АЛГОЛ 60 или его потомках, таких как Паскаль, было принято использовать отступы в качестве типографской особенности оформления для уточнения группировки команд, это был совершенно необязательный выбор внешнего вида, сделанный исключительно для удобства читателя. В статье П. Дж. Плаугера под названием "Сигнал и шум в языках программирования" мы нашли радикальную (тогда) идею: "Пусть компилятор читает тот же сигнал, что и мы, люди, и пусть отступы управляют группировкой" - предложение, которому мы последовали с энтузиазмом. Отступы, указывающие на принадлежность набора команд друг другу, впоследствии стали обязательными в программах B0, и этот выбор в дизайне языка сохранялся на протяжении всех итераций.

У нас не было четкой философии проектирования; она естественным образом выросла из ведущих принципов в процессе разработки. Чтобы помочь нашим предполагаемым пользователям, абсолютным новичкам, мы стремились скрыть низкоуровневые детали реализации и вместо этого предоставить мощные высокоуровневые функции, ориентированные на выполнение задач. Одной из вещей, которые мы ценили больше всего, была согласованность, как единообразие в представлении конструкций языка - "синтаксис" - так и отсутствие причуд в их значениях - "семантика". Большинство программистов не понимают всех аспектов своего любимого языка, и нельзя обоснованно ожидать, что новичок быстро освоит новый язык. В некотором смысле изучение нового языка программирования похоже на изучение нового естественного языка; неровности и исключения являются камнем преткновения на пути к мастерству. Естественный способ обучения - учиться на примерах, а затем экстраполировать эти примеры на общие правила. Малыш может сказать, например, "Собака укусила его", неправильно применив обычное правило образования прошедшего времени к неправильному глаголу. Хотя такая последовательность и может показаться возможной для созданного языка, на практике это будет встречается редко.

(здесь имеется ввиду особенность построения фразы “The dog bited him”, что неправильно, но в целом приемлемо, хотя встретить такое построение можно очень редко)

Большинство языков или их реализаций страдали от ограничений и исключений, которые были неудобными и произвольными по своей природе. Это делает язык более трудным для изучения и более сложным для использования. По мере того, как мы продвигались в разработке нашего нового языка, мы увидели закономерности в принятых нами проектных решениях. Мы попытались уловить каждую закономерность и сформулировать ее в виде правила проектирования - такой подход поможет улучшить согласованность. Некоторые из этих правил были определены ранее другими людьми, например, в статье Плаугера.

Требование синтаксического единообразия было закреплено в правиле единообразия, выраженном Плаугером в виде сентенции: "Похожие вещи должны быть сказаны похожим образом". Смежное, более семантическое правило дизайна, было названо Правилом справедливых ожиданий. Существует свойство человеческого зрительного восприятия, известное как "Принцип Хорошего продолжения" (закон прегнантности), которое отражает один из принципов гештальт-психологии. Когда объект виден лишь частично, человеческая зрительная система экстраполирует форму видимой части, чтобы сформировать представление о том, что скрыто. Чтобы сделать форму целостной, невидимая часть выводится из контекста. Например, когда непрозрачный диск закрывает угол прямоугольника, человек склонен предполагать, что стороны прямоугольника продолжаются под ним, и что прямоугольник является целым. Когда объект, закрывающий обзор, удаляется, наблюдатель может обнаружить, что его обманули: на самом деле другой объект не был целым. Но это уже сюрприз, которым пользуются фокусники. Мы хотели избавить наших учеников от подобных сюрпризов. Правило "Справедливых ожиданий" гласило, что если справедливо, основываясь на экстраполяции аналогичных конструкций, ожидать от пользователя, что некоторая мыслимая конструкция будет действительной и иметь определенное значение, то конструкция будет действительной и иметь это значение. Чем более точно конструкция следует этому правилу, тем справедливее становится ожидание пользователя, что это правило будет соблюдено и в следующем случае. По сути, такой подход оказывает самоподдерживающую силу на развитие языка. Еще одним требованием дизайна является правило "Экономии инструментов" (Economy-of-Tools Rule): разные инструменты должны выполнять действительно разные функции. Если оказывается, что отдельные функции концептуально пересекаются, эти инструменты должны быть объединены. Применение этого правила привело к заполнению большего количества пробелов в общей функциональности языка, чтобы соответствовать правилу "Cправедливых ожиданий".

В 1981 году, после двух итераций, мы почувствовали себя достаточно уверенно, чтобы опубликовать проект в виде проекта-предложения (Draft Proposal), после чего я быстро написал полноценную реализацию, которая должна была стать бросовым продуктом, чтобы мы могли собрать отзывы о преподавании языка начинающим.

В следующем году я принял одногодичный контракт в качестве приглашенного доцента на кафедре компьютерных наук в Курантовском институте математических наук , где Роберт Дьюар был активным участником, поддерживающим работу над языком B, и курировал некоторые студенческие проекты, в рамках которых была создана реализация B1. МЦ пригласил Стивена Пембертона - предполагалось, что он будет назначен на один год в качестве приглашенного научного сотрудника - стать руководителем разработки в этот промежуточный период. Пока я был в Нью-Йорке, команда разработки в Амстердаме была усилена новым сотрудником, Гвидо ван Россумом.

SETL и типы данных высоко уровня

Во время своего предыдущего визита в Нью-Йоркский университет я познакомился с SETL, языком программирования очень высокого уровня, который был разработан дальновидным эрудитом и автором нескольких фундаментальных книг по математике Джеком Шварцем. В некотором смысле SETL был почти полной противоположностью B, который тогда был в своей первой итерации B1. Основываясь на концепциях из математической теории множеств, целевой аудиторией SETL были математики. В отличие от этого, при разработке B мы не предполагали никаких знаний математики, кроме самых элементарных по арифметике и алгебре. Тем не менее, у этих двух языков было нечто общее на более глубоком уровне: философия проектирования, сосредоточенная на предоставлении программистам всего нескольких, но очень мощных инструментов. SETL воплотил в себе радикальный отход от настроений, которые до тех пор витали над разработкой языков высокого уровня, включая АЛГОЛ 68. Разработчики этих языков и их коллеги пришли из эпохи, когда инструкции процессора выполнялись не в микросекундах, а в миллисекундах. Вычисления, которые в начале 1980-х годов занимали час, в начале 1950-х годов заняли бы много недель. На протяжении десятилетий компьютерное время считалось несравненно более ценным, чем время программиста, и это наложило отпечаток на мышление целого поколения программистов и языки, которые они разрабатывали. Таким образом, конструкции языков программирования были разработаны так, чтобы иметь довольно простое отображение на аппаратные наборы инструкций компьютеров. Но, конечно, это отображение не было идеальным; некоторая потеря в скорости выполнения по сравнению с тщательно составленными программами, написанными непосредственно в машинном коде, была неизбежной. Диатрибы против пагубного влияния языков высокого уровня, отнимающих время компьютеров, были не редкостью даже в 1960-х годах. В основе разработки SETL лежала философия, согласно которой, по мере того как компьютеры становятся все быстрее и быстрее, человеческое время будет более ценным, чем компьютерное, и что эффективность набора инструментов, предоставляемых SETL, должна измеряться не скоростью вычислений, а их концептуальной мощью.

Написав несколько алгоритмов на SETL, я воочию убедился в его силе - силе, которая полностью проистекала из его высокоуровневых встроенных типов данных. Особенно мощными были множества (set) и карты (map), также известные как "ассоциативные массивы", содержащие данные, которые можно индексировать не только последовательными целыми числами, но и произвольными значениями. Программист мог ввести простую базу данных цитат с именем whosaid, в которой значение "Декарт" могло храниться в whosaid["cogito ergo sum"]. Эти высокоуровневые типы позволили выразить алгоритмы, требующие много шагов в B1, с помощью всего нескольких шагов в SETL. Явным нарушением правила справедливых ожиданий стало то, что в B1 в качестве индексов массивов допускались только целые числа. Это решение было продиктовано страхом: мы опасались, что слишком высокие требования сделают наш язык нереализуемым на небольших персональных компьютерах, которые только начинали появляться на рынке. Но Дьюар, в частности, убедил меня, что это означает, что мы проектируем для прошлого, а не для будущего. Это заставило нас заново разработать систему типов данных для нашего языка для начинающих. На этот раз мы использовали только критерии легкости обучения и простоты использования для отбора систем-кандидатов. Победитель оказался удивительно похож на систему типов данных SETL. Набор возможных систем типов данных для выбора был очень велик, и чтобы сделать процесс более управляемым, я написал программу для выбора конкурентоспособных (Парето-оптимальных) систем-кандидатов. Интересно, но совершенно случайно, что сама программа выбора была написана на SETL. Победителем стала система типов B2, которая осталась неизменной в финальной итерации, выпущенной в 1985 году под названием "ABC". Выражаясь символически, мы выполнили команду PUT "ABC" IN B. С момента начала проекта B прошло десять лет.

Конец и начало

В сентябре 1983 года я вернулся в Амстердам, в МЦ, который за время моего отсутствия был переименован и теперь стал CWI. Компьютерные науки, информатика по-голландски, играли важную роль в исследованиях, проводимых в МЦ на протяжении всего его существования; смена названия сделала это очевидным. Пембертон остался в команде в качестве третьего главного дизайнера языка ABC. На последней итерации разработки, ведущей от B2 к ABC, мы заново рассмотрели почти каждый аспект языка, чтобы понять, возможны ли дальнейшие улучшения, какими бы незначительными они ни были. Мы проводили еженедельные собрания команды, в которых участвовали все ее члены. Ван Россум регулярно предлагал изменения. Некоторые из его предложений были приняты, многие - нет, но все они были серьезно рассмотрены. При разработке языка программирования редко бывает так, что предлагаемое изменение имеет только преимущества; почти всегда оно имеет и преимущества, и недостатки. Взвешивание этих факторов друг с другом для вынесения вердикта может быть тонким делом. Во многих случаях предложение нарушало одно из правил проектирования, которые были несовершенной кодификацией общей философии проектирования.

В 1984 году проект получил в свои руки IBM PC, и менее чем через год мы сделали ABC, работающий на этой машине и готовый к распространению по всему миру.

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

TELCOMP:

1.01 DO PART 2 FOR I = 1:1:N-1

2.01 DO PART 3 FOR J = 1:1:N-1

3.01 DO PART 4 IF A[J] > A[J+1]

4.01 SET X = A[J]
4.02 SET A[J] = A[J+1]
4.03 SET A[J+1] = X

ABC:

FOR i IN {1..#a-1}:
  FOR j IN {1..#a-1}:
    IF a[j] > a[j+1]:
      PUT a[j+1], a[j] IN a[j], a[j+1]

Нумерация, предшествующая каждой команде TELCOMP, незаменима; она служит меткой для указания продолжения вычислений. В программе ABC ничего подобного не требуется. Программа TELCOMP состоит из четырех пронумерованных "частей", которые подобны подпрограммам, названным по номерам. Каждая часть состоит из одного или нескольких пронумерованных шагов. После завершения шагов каждой части, управление возвращается к продолжению шага, с которого была вызвана часть с помощью команды DO PART. Версия TELCOMP требует, чтобы значение переменной N было заранее равным длине массива A. После ввода этих команд пользователь все еще должен дать прямую команду DO PART 1, чтобы начать процесс сортировки, тогда как команда ABC может быть использована напрямую.

ABC не стал тем успехом, на который мы рассчитывали. Когда мы начинали проект, мы наивно полагали, что изучение первых принципов программирования станет лишь вопросом времени и войдет в стандартную школьную программу, для которой ABC будет идеально подходить. В некоторых школах учителя действительно проводили экспериментальные занятия по программированию с использованием ABC. Но когда в конце 1980-х годов "информатика" наконец-то вошла в программу голландских средних школ, оказалось, что она стала не более чем курс по использованию текстового процессора (WordPerfect) и электронных таблиц (Lotus 1-2-3), оба продукта теперь лишь воспоминание. Серьезным препятствием, с которым мы столкнулись, был поиск способа сообщить оставшейся целевой группе пользователей - непрофессиональных компьютерных любителей - о существовании языка. Интернета в том виде, в котором мы его знаем, еще не существовало. Его предшественник, ARPANET, был предназначен для академических и военных нужд. По какой-то причине директора CWI не одобрили идею разместить объявление в журнале Dr. Dobb's Journal, который в то время был ведущим журналом для компьютерных любителей. Единственное, что мы могли сделать, это разослать копии программного обеспечения на дискетах тем немногим счастливчикам, которые слышали о нашем проекте и связались с нами - всего несколько сотен человек. По своей мудрости и вопреки нашим желаниям, директора института настояли на том, чтобы на начальном экране отображалось сообщение "Copyright (c) Stichting Mathematisch Centrum, Amsterdam, 1985", активно отбивая у пользователей охоту давать копии своим друзьям. Кстати, это был тот самый год, когда Ричард Столлман опубликовал "Манифест GNU" в журнале Dr. Dobb's Journal, который стал призывом к движению за свободное программное обеспечение.

В 1988 году Гвидо ван Россум был назначен на проект Amoeba, совместный проект Свободного университета (Free university) и CWI, целью которого была разработка распределенной операционной системы. Однажды утром в январе 1990 года он пригласил меня на демонстрацию своего нового детища - языка под названием "Python", который он разработал в перерыве между Рождеством и Новым годом. Не помню, чтобы я сначала был в восторге; смысл этого нового языка в то время от меня ускользал. Только после того, как я заметил, что программисты, участвовавшие в проекте, стали восторженными пользователями Python, в частности Джек Янсен, ставший первым в мире программистом на Python после ван Россума, я начал обращать на него более пристальное внимание.

Python и секрет успеха

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

Имеет смысл рассматривать сферу языков программирования как экосистему, в которой языки занимают свои собственные ниши. Ниша FORTRAN - высокопроизводительное научное программирование, включающее тяжелые численные вычисления; ниша COBOL - администрирование, основанное на файлах записей данных. Язык C предназначен для системного программирования, первоначально он был разработан специально для операционной системы Unix. Как не существует транспортного средства общего назначения, так не существует и универсального языка программирования общего назначения; для конкретной узкоспециализированной области применения всегда можно разработать язык, приспособленный и лучше отвечающий специфическим потребностям этой области.

В рамках проекта Amoeba возникла необходимость соединить независимо разработанные части программного обеспечения. В то время операционные системы, такие как Unix, поставлялись с программой, называемой "оболочкой" (shell), для выдачи прямых инструкций операционной системе. Они включали в себя инструкции, необходимые для связи приложений, например, передачу вывода одного из них на вход другого. Последовательность shell-команд, известная как "скрипт" (сценарий), могла быть сохранена в файле, имя которого затем могло быть использовано в качестве новой shell-команды. Это была отдельный вид программирования, но shell-языки, какими они были в то время, не были предназначены для программирования, и их использование для этой цели могло быть крайне неудобным. Хуже того, не было прямого способа взаимодействия с процессами Amoeba; заглушки кода приходилось писать на C. Хотя переход на C мог показаться лучшим выходом, он также заставил бы программиста ввязаться в неудобный цикл "редактирования-сохранения-компиляции-исполнения-отладки". Возникла явная потребность в хорошо продуманном "языке сценариев", который позволял бы взаимодействовать с внешними процессами. Python был первоначально разработан как высокоуровневый язык сценариев для проекта Amoeba. ABC был совершенно непригоден для этой цели; он жил в собственном мире, ограждая своих пользователей от внешнего мира. Python был специально разработан для взаимодействия с этим внешним миром. Единственным другим претендентом в нише скриптовых языков высокого уровня в то время была ранняя версия Perl, но она не была должным образом документирована, и дальнейшая поддержка языка не могла быть гарантирована. Кроме того, хотя Perl и делал то, что должен был делать, он представлял собой эклектичную смесь функций, взятых из других языков, которые были интегрированы без особого внимания к целостности и соглаосванию.

Несмотря на радикально иную область применения, Гвидо ван Россума вдохновила философия проектирования и правила разработки проекта ABC. Позднее философия дизайна Python будет несколько поэтично описана Тимом Питерсом, одним из его первых евангелистов, в тексте, известном сегодня как "Дзен Python". Многие из его афоризмов перекликаются с философией дизайна ABC: "Ошибки никогда не должны проходить молча" и "Перед лицом двусмысленности откажитесь от искушения угадать" соответствуют правилу проектирования, которое мы назвали правилом "Логических ошибок". Аналогично, правило "Справедливых ожиданий" отражено в утверждении: "Особые случаи не настолько особенны, чтобы нарушать правила"; а "Должен быть один - и желательно только один - очевидный способ сделать это" воплощает дух правила "Экономии инструментов". Как и в случае с ABC, пользователи Python могли набрать некоторый код и сразу же запустить его; язык имел лаконичный и понятный синтаксис, высокоуровневые типы данных, а объявления переменных не требовались. Это настолько упростило рабочий процесс, что первые его пользователи, системные программисты, также начали использовать язык для решения многих задач, выходящих за рамки его первоначального предназначения. Несколько усовершенствованная версия с соответствующей документацией, описывающей, как установить систему под Unix, была выложена в Usenet в начале 1991 года как релиз с открытым исходным кодом, и ее подхватили программисты по всему миру.

Способность развиваться и адаптироваться к изменяющимся потребностям - это важный атрибут для долгосрочного выживания любого языка программирования. FORTRAN, впервые появившийся в 1957 году, и COBOL, датируемый 1960 годом, живы и сегодня, но претерпели значительную эволюцию. Точно так же и Python, который сейчас доступен в версии 3, уже не является Python 1990 года, но все же сумел сохранить свои сильные стороны, включая согласованность, отсутствие ненужных ограничений и экономичность инструментов. Мощные типы данных играют центральную роль в Python, как и в ABC, а до этого в SETL.

Следующие примеры кода показывают две версии алгоритма пузырьковой сортировки, на этот раз выраженные на языках ABC и Python.

ABC:

FOR i IN {1..#a-1}:
  FOR j IN {1..#a-1}:
    IF a[j] > a[j+1]:
      PUT a[j+1], a[j] IN a[j], a[j+1]

Python:

for i in range(len(a)-1):
  for j in range(len(a)-1):
    if a[j] > a[j+1]:
      a[j], a[j+1] = a[j+1], a[j]

Синтаксическое сходство между этими языками очевидно. Другое сходство заключается в том, что ни в одном из языков нет требования включать объявления переменных, используемых в программе - это бремя снимается, но ценой безопасности типов. Почти во всех языках программирования код для алгоритма пузырьковой сортировки будет работать только для одного типа элементов, например, чисел. Если, например, строки текста тоже нужно отсортировать, придется написать еще один кусок кода. В Python, как и в ABC, приведенный выше код можно использовать для любых типов элементов, для которых определен оператор сравнения >, например, для строк. В то время как многие языки программирования не вмещают десятизначные целые числа, ни ABC, ни Python не накладывают верхнюю границу на размер целого числа. Значение выражения (10^999 + 1) – 10^999 в точности равно 1, но пошаговая оценка требует вычитания двух чисел, которые, если записать их в десятичной системе счисления, содержат по тысяче цифр. В большинстве языков программа выйдет из строя или выдаст 0 вместо 1. И Python, и ABC выдают правильное значение. Это не просто свойство реализаций; оно предписано спецификацией языка.

Никакой краткий обзор возможностей Python, какими бы привлекательными они ни были, не может дать оценку общему дизайну языка - его нельзя оценивать, рассматривая его компоненты по отдельности. Лучшим показателем качества Python является разумный выбор, который был сделан в отношении того, какие функции включать, а какие не включать. Его реальная сила может быть измерена тем, насколько хорошо эти компоненты могут быть объединены для решения задач программистов.

Рост популярности Python, начиная с его появления тридцать лет назад в качестве усилия одного человека, пролетевшего под радаром, был феноменальным, но не метеоритным. Напротив, это был долгий, медленный и неуклонный рост. Простота изучения Python дала ему конкурентное преимущество в период, когда постоянно требовалось больше программистов. Его чистый синтаксис и семантика позволяют легче поддерживать кодовую базу, написанную на Python, чем на других языках - важный момент, учитывая, что стоимость поддержки программного обеспечения превосходит стоимость создания новых программ. Его растущая популярность также обусловлена наличием обширных библиотек - коллекций модулей, предлагающих функциональность, специфичную для конкретной области, разработанных и поддерживаемых сообществом Python в духе открытого и свободного программного обеспечения и легко доступных через поисковый Python Package Index (PyPI). Независимо от того, хочет ли начинающая компания быстро разработать веб-сайт или приложение для искусственного интеллекта, библиотеки Python могут дать хороший задел для старта. Существуют модули для астрономии, криптографии, науки о данных, финансовых услуг, геномики, мультимедиа и многих других областей. Дизайн Python делает использование библиотек и модулей простым - область, в которой дизайн ABC был недостатком. Python также упрощает создание новых библиотек и тем самым побуждает пользователей вносить новые разработанные библиотеки приложений в общий репозиторий.

Почти по любому показателю Python входит в тройку самых популярных языков программирования во всем мире, а часто и возглавляет этот список. Какими бы ни были внутренние качества Python, феноменальный успех языка невозможно объяснить без учета роли, которую сыграл его непритязательный создатель и ведущий дизайнер Гвидо ван Россум. Действуя при поддержке и согласии сообщества Python, ван Россум должен был лично "подписывать" все изменения в языке, что привело к присвоению ему шутливого титула "пожизненного доброжелательного диктатора". На протяжении всего развития Python твердая направляющая рука ван Россума помогала сохранять целостность его дизайна.

Приквел и эпилог

Я впервые встретился с Гвидо ван Россумом в начале 1980-х годов, когда мы оба работали в группе по проектированию и разработке системы автоматизации управления членством в Pacifistisch Socialistische Partij, голландской политической партии, которая позже объединилась с несколькими другими небольшими партиями и образовала партию GroenLinks (Зеленые левые). За предыдущие несколько лет число членов партии удвоилось, и трое сотрудников, которые до этого момента выполняли всю административную работу вручную, были перегружены. К счастью, цены на мини-компьютеры стремительно падали, и партия решила приобрести один из них. Бюджет партии не позволял коммерческой компании по разработке программного обеспечения создать необходимую систему; вместо этого небольшая группа добровольцев начала разработку системы своими силами, используя COBOL в качестве языка реализации. Серьезным препятствием для разработки было неудобство редактора, поставляемого с мини-компьютером; он позволял пользователям видеть только одну строку кода за раз. Поскольку компьютер не мог работать в многозадачном режиме, компиляция, которая была невероятно медленной, и тестирование должны были ждать окончания сеанса редактирования. В результате прогресс мог быть достигнут лишь со скоростью улитки. Ван Россум, в то время студент университета, удивил остальных членов команды, неожиданно создав новый редактор, который был не только намного проще в использовании, но и эффективно использовал большую часть доступного пространства экрана. Он написал редактор на COBOL, языке, с которым познакомился только благодаря этому проекту. В то время проект ABC стремился расширить команду разработчиков, и, признавая его талант к программированию, я посоветовал ван Россуму подать заявление о приеме на работу. После окончания университета он начал свою профессиональную карьеру 1 ноября 1982 года в качестве члена команды языка B, которую он также удивил неожиданным появлением нового редактора - структурного редактора для ABC, полностью учитывающего его синтаксис.

Воркшоп в Стамбуле в 2019 году, упомянутый в начале этого очерка, был не единственным в своем роде. На самом деле, он был восьмым в продолжающейся серии таких воркшопов, которые были приостановлены пандемией COVID-19. В ходе этих однодневных семинаров участницы начинают с тривиальной однострочной программы, такой как print('Hello, Django Girls!'), и к концу дня учатся программировать свой собственный веб-сайт. Эти семинары Django Girls проводятся не только в Стамбуле, они проходят по всему миру. И Python преподается не только как первый язык на этих семинарах; он стал языком для вводных курсов по программированию. Сейчас Python занимает ту нишу, для которой был разработан ABC. Действительно, сейчас Python занимает множество ниш. Он стал действительно многопрофильным языком.

Успех любого начинания редко можно приписать какому-то одному фактору. Помимо вышеперечисленных факторов, свою роль играет и удача. Если ABC, возможно, слишком опередил свое время, то Python появился как раз в нужное время. Как бы там ни было, я считаю, что философия проектирования, которую мы разработали в процессе создания ABC, в той мере, в какой ей следовали и в Python, оказала, по крайней мере, некоторое положительное влияние.

Ламберт Меертенс научный сотрудник в институте Кестрела — некоммерческом исследовательском центре компьютерных наук при Стэнфордском исследовательском парке в Пало-Алто. В то время как его основная работа была выполнена в CWI, Амстердам, и в Институте Кестрел, он занимал профессорские должности в Нью-Йоркском университете, Делфтском технологическом университете и Утрехтском университете, а также был председателем рабочей группы IFIP 2.1 по алгоритмическим языкам и вычислениям с 1999 по 2009 год.

Оригинал статьи: https://inference-review.com/article/the-origins-of-python

Если будут замечены ошибки или неточности в переводе, буду благодарен за указание на них в лс или комментариях.