# Гвидо ван Россум: Python как ДНК современных технологий

Источник: https://www.youtube.com/watch?v=-DVyjdw4t9I
Канал: Lex Fridman
Опубликовано: 26.11.2022

---

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

## 📖 Философия кода: Почему читаемость важнее инструкций
[[JUMP:00:00]]

Программирование часто представляют как сугубо технический процесс общения с «железом», но для создателя Python **Гвидо ван Россума (Guido van Rossum)** это прежде всего социальное взаимодействие. В разговоре с **Лексом Фридманом (Lex Fridman)** он подчеркивает, что хотя компьютер и нуждается в предельно точных инструкциях, современные программы пишутся людьми и для людей [6:16]. Чтобы объяснить суть программирования человеку, далекому от технологий — например, рыбаку на лодке посреди океана — Гвидо использует метафору кулинарного рецепта: это последовательность шагов, которая должна привести к понятному результату, будь то приготовление сэндвича или работа мобильного приложения [4:00].

### Код как социальный контракт: Наследие PEP 8
[[JUMP:05:50]]

Одной из фундаментальных идей Python является принцип «читаемость имеет значение» (readability counts). Гвидо объясняет, что разработка ПО — это не работа «сумасшедшего ученого», запертого в лаборатории, а командная деятельность [6:58]. Даже если программист работает один, через год он станет «другим человеком» по отношению к своему старому коду и может не вспомнить логику собственных решений [10:08].

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

*   **Компьютер**, который выполняет инструкции буквально и не терпит двусмысленности;
*   **Другие программисты** (включая автора в будущем), которым нужно быстро понять логику процесса [8:32].

Именно поэтому в Python такое внимание уделяется стилю. Стандарт PEP 8 — это не просто набор правил, а способ сделать структуру программы очевидной при первом же взгляде [6:03]. В других языках, таких как C++ или Java, отступы также важны для культуры разработки, но там они являются лишь рекомендацией, в то время как в Python они стали частью синтаксиса [15:02].

### Магия отступов: От мониторов 80-х до философии Python
[[JUMP:10:36]]

Визуальная структура кода в Python — его главная отличительная черта. Гвидо сравнивает это с многоуровневыми списками в сложных бизнес-документах: если не делать отступы, вы не поймете, где заканчивается один логический блок и начинается другой [12:37]. И наоборот: если отступ будет слишком большим, на странице не останется места для самого текста.

Выбор стандарта в четыре пробела не был случайным. Это компромисс, продиктованный историей и эргономикой:

1.  **Наследие 80-х:** Типичная ширина экрана в те годы ограничивала возможности форматирования [13:18].
2.  **Читаемость:** Два пробела (как в стиле Google для C++) могут быть слишком незаметны для быстрого сканирования глазами [13:43].
3.  **Избегание «лесенки»:** Классические восемь пробелов (Unix-стандарт) слишком быстро сдвигают код к правому краю экрана [14:10].

На вопрос Лекса о том, не стоило ли использовать фигурные скобки, как в C или Rust, Гвидо отвечает однозначно: в контексте Python это создало бы лишний «шум» [16:20]. Отсутствие скобок и точек с запятой освобождает синтаксис от визуального мусора и упрощает жизнь новичкам [19:11]. Начинающему программисту и так нужно освоить массу концепций — от переменных до рекурсии, — и ошибки в расстановке точек с запятой только отвлекают от сути алгоритмов [20:31]. 

Хотя Гвидо признает, что Python в этом плане — «белая ворона» среди мейнстримных языков, он уверен, что визуальная чистота помогает лучше фокусироваться на логике [17:02]. О других аспектах производительности языка, таких как ускорение в версии 3.11, речь пойдет позже, но фундамент Python всегда остается неизменным — это ясность структуры [0:41].

### Символ доллара и наследие старых систем
[[JUMP:21:37]]

Обсуждая причуды разных языков программирования, Лекс Фридман затронул тему использования знака доллара (`$`) перед именами переменных в PHP и Perl, что часто раздражает современных разработчиков [21:24]. Гвидо объяснил, что это не эстетический выбор, а техническое решение, уходящее корнями в эпоху создания Shell (командной оболочки Unix) [21:52].

Проблема первых интерпретаторов заключалась в сложности парсинга (анализа) текста. В самых ранних скриптах не было понятия параметров; скрипт был просто набором строк, где первое слово — название программы, а остальные — аргументы (обычно имена файлов) [22:06]. Когда возникла необходимость вводить переменные, инженеры столкнулись с дилеммой: как отличить переменную `x` от файла с названием `x`? [23:40]

Решение было продиктовано ограничениями памяти компьютеров 50-х и 60-х годов:

*   **Упрощение парсера:** Интерпретатор должен был быть крошечным. Знак доллара служил сигналом: «видя этот символ, переключись в режим чтения имени переменной» [24:46].
*   **Однозначность:** Это позволяло легко смешивать фиксированный текст и динамические данные в одной строке без создания сложных правил разбора [25:12].

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

## 🐞 Экономика ошибок и психология выбора языка

[[JUMP:25:12]]

Современные программные системы обладают поразительной устойчивостью, которая во многом напоминает биологические механизмы. Ранее в разговоре Гвидо и Лекс затронули тему сходства кода с ДНК, отметив, что в обеих системах полно странных «костылей» и пережитков прошлого, которые сохраняются десятилетиями [26:19]. Гвидо ван Россум (Guido van Rossum) подчеркивает, что даже в очень хорошо протестированном коде, который на практике работает без сбоев, скрывается огромное количество ошибок [27:11]. Эта устойчивость поддерживается на нескольких уровнях: от механизмов самокоррекции внутри софта до самого пользователя, который интуитивно знает, что при возникновении странностей нужно просто «перезагрузить страницу» или «нажать кнопку еще раз» [27:38].

### Плотность багов и цена исправления
[[JUMP:28:43]]

Одной из самых интригующих тем обсуждения стала статистика ошибок на тысячу строк кода (KLOC). Гвидо вспоминает исследования 80-х и 90-х годов, которые показывали удивительное единообразие: независимо от языка программирования, компании или стиля разработки, в зрелом ПО сохраняется примерно одна значимая ошибка на тысячу строк [29:59].

Однако Лекс Фридман (Lex Fridman) приводит современные данные аналитических компаний, которые выглядят куда более тревожно:

*   В процессе написания кода среднестатистический разработчик допускает около 70 ошибок на 1000 строк [30:26].
*   Около 15 ошибок на 1000 строк в итоге попадают к конечному пользователю [30:39].
*   Исправление одной ошибки занимает в 30 раз больше времени, чем написание строки кода [30:52].
*   До 75% времени разработчика уходит на отладку и поиск багов [30:52].

В масштабах экономики США это выливается в колоссальные 113 миллиардов долларов ежегодных затрат на идентификацию и исправление программных дефектов [31:07]. Гвидо ван Россум (Guido van Rossum) скептически относится к заявлениям маркетинговых отделов, предлагающих «серебряную пулю» для решения этой проблемы, считая, что такова природа процесса: разработка софта крайне итеративна [32:25]. Невозможно составить идеальный план на год вперед, потому что сами детали этого плана — это тоже своего рода «программа», в которой неизбежно будут логические ошибки [32:56].

### Анатомия ошибок: от опечаток до «финко»
[[JUMP:33:08]]

Разговор об ошибках неизбежно переходит к самому процессу ввода текста. Гвидо признается, что он «плохой машинист»: он так и не освоил десятипальцевый метод и в свои первые студенческие годы набивал код на перфокартах двумя пальцами [33:36]. Наблюдая за работой программистов, можно заметить, как часто используется клавиша Backspace: иногда люди стирают по 20–40 символов, чтобы исправить одну опечатку в начале длинного слова, тратя на это три-четыре попытки [34:33].

Гвидо разделяет ошибки на две категории:

1.  **Опечатки (Typos):** чисто механические ошибки ввода.
2.  **«Финко» (Thinkos):** ошибки мышления, когда разработчик, например, забывает инициализировать переменную или использует не ту переменную, которая была нужна по логике программы [35:12].

Интересно, что в Python многие «финко» (например, использование неинициализированной переменной) отлавливаются на ранних стадиях, в то время как в других языках они могут долго оставаться незамеченными [35:26]. Лекс добавляет, что даже физическая эргономика влияет на процесс: он использует клавиатуру Kinesis, где Backspace находится под большим пальцем, чтобы минимизировать нагрузку на мизинец и ускорить процесс коррекции опечаток [36:05].

### Технологические тупики и сохранение концепций
[[JUMP:38:20]]

Обсуждая выбор инструментов — от классического Emacs, к которому привык Лекс (ранее в интервью упоминалась эволюция редакторов), до современных IDE — собеседники задаются вопросом: как отличить технологию, определяющую будущее, от временного увлечения?

Лекс вспоминает свой опыт с Flash и ActionScript, а также с Java-апплетами [39:15]. С позиции сегодняшнего дня время, потраченное на изучение ActionScript, может показаться потерянным, так как навык больше не востребован. Однако Гвидо ван Россум (Guido van Rossum) предлагает смотреть на это иначе: технологии умирают, но концепции сохраняются [39:43]. Идея реактивных веб-страниц, анимаций и интерактивности, которую продвигал Flash, никуда не исчезла — она просто переродилась в JavaScript-эквиваленты [40:36]. «Не было бы реактивных самолетов без пропеллерных», — резюмирует создатель Python [41:01].

### Психология «выбора лагеря»
[[JUMP:42:23]]

Для молодого программиста крайне важно пробовать «глупые вещи» и отклоняться от общепринятых путей. В девяти случаях из десяти это научит вас, почему все остальные делают иначе, но в одном случае вы откроете нечто лучшее [42:49]. Однако с возрастом, появлением семьи и детей, разработчики становятся более консервативными и склонными к минимизации рисков [43:15].

Выбор основного языка программирования часто определяет траекторию всей жизни. Лекс описывает свой «болезненный прыжок» из мира C++ в мир Python [45:17]. Будучи хардкорным пользователем C++, он видел в нем инструмент для любой задачи, включая скриптинг. Переход в Python для задач машинного обучения (подробнее о причинах доминирования Python в ML пойдет речь в следующих главах) стал для него экзистенциальным кризисом — ощущением, будто бросаешь любимого человека [46:12]. 

Гвидо отмечает, что C++ продолжает развиваться и внедрять инновации, но за ними невероятно сложно следить, если ты не являешься частью «хардкорного» сообщества [46:50]. В конечном итоге выбор сводится к эмпирическому вопросу: «В каком языке я более продуктивен и от какой жизни я получаю больше удовольствия?» [47:33].

В вопросах выбора бэкенда — будь то PHP (на котором до сих пор держится большая часть веба), Node.js или Python — Гвидо советует не переусердствовать с анализом [49:16]. Не стоит пытаться рассчитать в Excel, какой язык принесет вам на X миллионов долларов больше за всю жизнь. Важно принять, что не каждый выбор будет идеальным, и всегда иметь в голове «план Б», не зацикливаясь на перфекционизме [50:08].

## 🚀 Революция 3.11: Как «ленивый» интерпретатор стал быстрым

[[JUMP:53:37]]

Одним из самых ожидаемых событий в мире программирования стал выход Python 3.11 — версии, обещающей значительный прирост производительности. В беседе с Лексом Фридманом (Lex Fridman) Гвидо ван Россум (Guido van Rossum) подчеркивает, что этот скачок не был случайностью, а стал результатом глубокой переработки внутренних механизмов CPython [53:37]. Хотя ранее в разговоре они касались субъективности выбора инструментов, когда речь заходит о 3.11, цифры говорят сами за себя.

### Путь к Python 3.11: От простоты к производительности
[[JUMP:54:20]]

Гвидо признает, что изначально CPython создавался не как гоночный болид, а как максимально понятный и полезный инструмент. В начале пути он не рассчитывал на мировой успех и славу, поэтому первый прототип языка был написан всего за три месяца [55:11]. Это заставило его «срезать углы» и заимствовать идеи везде, где это было возможно. Код писался максимально просто: во многих случаях алгоритм просто пересчитывал всё заново при каждом новом вводе, чтобы сохранить математическую стройность и легкость отладки [56:19].

Однако со временем требования к производительности возросли. Гвидо ван Россум (Guido van Rossum) объясняет эволюцию оптимизации на примере поиска простых чисел:

1. Самый простой способ — проверять делимость числа $n$ на все числа от 2 до $n-1$ [58:14].
2. Оптимизация первого уровня — остановиться на квадратном корне из $n$.
3. Более сложный уровень — проверять только нечетные числа или только ранее найденные простые числа [59:21].

В программировании работает тот же принцип: чем производительнее алгоритм, тем он сложнее. В 3.11 команда разработчиков Microsoft и сообщество CPython сосредоточились на «низковисящих фруктах» — участках кода, которые оставались нетронутыми десятилетиями из-за стремления к простоте [1:03:00].

### Анатомия CPython: Компилятор, байт-код и «рецепт рецептов»
[[JUMP:1:01:52]]

Для понимания ускорения 3.11 важно различать, как именно Python исполняет код. Гвидо ван Россум (Guido van Rossum) описывает интерпретатор как «рецепт для понимания других рецептов» [1:02:05]. Вместо того чтобы сразу печь торт (выполнять задачу), интерпретатор читает текст программы и решает, как именно его запустить.

Несмотря на репутацию интерпретируемого языка, в Python всегда присутствовал компилятор. Он превращает человекочитаемый код не в машинные инструкции, а в байт-код — инструкции для воображаемого компьютера, называемого виртуальной машиной Python [1:03:43]. В версии 3.11 разработчики почти не трогали сам компилятор, так как программа компилируется один раз, а исполняется тысячи. Весь упор был сделан на ускорение работы самого интерпретатора, который этот байт-код «переваривает» [1:04:10]. Примечательно, что команда достигла успеха, не прибегая к созданию полноценного JIT-компилятора (Just-In-Time), характерного для мира Java [1:04:37].

### Адаптивная специализация: Искусство предугадывания типов
[[JUMP:1:05:47]]

Ключевым техническим новшеством Python 3.11 стала концепция «адаптивного специализирующего интерпретатора» (Adaptive Specializing Interpreter). В обычном режиме Python крайне осторожен. Если в коде стоит знак `+`, интерпретатор не знает, что именно вы складываете: два целых числа, две строки, два списка или пользовательские объекты [1:06:39]. Это требует огромного количества проверок:

*   Нужно найти тип объекта (указатель на память).
*   Проверить, поддерживает ли тип операцию сложения.
*   Найти соответствующую функцию в списке методов типа.
*   Убедиться, что второй аргумент совместим [1:11:51].

Всё это — «указатели на указатели», которые замедляют работу. Гвидо объясняет, что адаптивность заключается в наблюдении за кодом в реальном времени. Если конкретная строка кода (например, `a + b`) при первых десяти запусках всегда складывала два целых числа (`int`), интерпретатор делает «ставку» [1:12:43].

Он временно заменяет общую инструкцию сложения на специализированную — «сложение целых чисел». Эта версия работает гораздо быстрее, так как она заранее предполагает типы данных и выполняет операцию почти напрямую [1:13:10]. Гвидо называет это «ложью во благо»: интерпретатор верит в стабильность типов, но всегда оставляет механизм отката (fallback). Если внезапно в эту строку попадет строка вместо числа, интерпретатор признает ошибку, потратит несколько циклов на возврат к общей логике и снова станет «осторожным» [1:14:32]. Статистически в реальных программах типы в одних и тех же строках меняются редко, что и дает Python 3.11 его впечатляющее ускорение [1:14:46].

## 🛠️ Статическая типизация и эволюция MyPy
[[JUMP:1:18:41]]

Одним из самых значимых изменений в экосистеме Python за последние годы стало появление аннотаций типов, закреплённых в PEP 484. Гвидо ван Россум (Guido van Rossum) отмечает, что этот механизм является опциональным, но приобрел колоссальную популярность, особенно в крупных компаниях с гигантскими кодовыми базами [1:18:53]. По своей сути аннотации — это «подъязык» внутри Python, позволяющий программисту явно указать, что переменная является целым числом, а функция возвращает список строк.

Важно понимать, что на текущий момент эти аннотации не используются интерпретатором для ускорения кода — ранее в разговоре Гвидо и Лекс Фридман (Lex Fridman) уже касались темы оптимизации CPython, но типизация здесь стоит особняком. Сейчас это скорее инструмент для разработчика [1:19:48]. Проверкой занимается стороннее ПО — статический тайп-чекер, который анализирует исходный код без его выполнения. Гвидо объясняет, что интерпретатор игнорирует аннотации по нескольким причинам:

*   Многие программисты вообще не используют типы.
*   В аннотациях иногда встречается «ложь», когда код на практике нарушает заявленные типы, но продолжает работать благодаря динамической природе языка [1:20:28].
*   Принудительное исполнение типов сломало бы огромное количество существующих программ, которые слишком динамичны по своей структуре [1:20:41].

Тем не менее, Гвидо не исключает будущего, где через несколько релизов аннотации станут подсказками для генерации специализированных машинных инструкций (например, для сложения целых чисел) с возможностью отката к универсальному методу, если данные в рантайме окажутся иного типа [1:21:20].

### История MyPy: от независимого диалекта к стандарту
[[JUMP:1:23:53]]

Проект MyPy, ставший прародителем современной типизации в Python, начался с инициативы финского разработчика Юкки Лехтосало (Jukka Lehtosalo). Гвидо вспоминает, что изначально MyPy задумывался как отдельный вариант языка, и Юкка даже использовал синтаксис, несовместимый с Python — например, угловые скобки для дженериков, как в Java или C++ [1:25:15].

В 2013 году на конференции по Python Гвидо и Юкка встретились и пришли к компромиссу: они разработали синтаксис аннотаций, который не требовал изменений в самом ядре Python, позволяя MyPy работать как внешнему инструменту [1:25:03]. До этого MyPy фактически был препроцессором: он проверял типы, удалял аннотации и превращал код в чистый Python. Однако такая модель плохо вписывалась в стандартные рабочие процессы разработчиков, поэтому было решено интегрировать синтаксис аннотаций непосредственно в язык, даже если сам интерпретатор их игнорирует [1:26:24].

Гвидо проводит параллель с миром JavaScript и TypeScript. Хотя TypeScript является транспилятором, его успех доказал ценность строгости [1:29:12]. Он рекомендует использовать TypeScript именно из-за того, что типизация помогает «держать голову в порядке» и упрощает редактирование кода, предотвращая массу глупых ошибок [1:29:26]. В Python ситуация схожая: аннотации типов стали мостом между гибкостью динамического языка и надежностью статического анализа.

### Корпоративная «гонка вооружений» тайп-чекеров
[[JUMP:1:34:00]]

Успех MyPy привел к тому, что крупнейшие технологические компании осознали ценность статической проверки типов для Python, но вместо того, чтобы просто вкладываться в MyPy, они начали создавать свои инструменты, адаптированные под внутренние нужды. 

Гвидо выделяет три ключевых игрока в этой области:

1.  **Facebook (Meta):** Они создали **Pyre**. Разработчики Facebook использовали свой опыт создания HHVM (эффективного компилятора для PHP) и написали Pyre на языке OCaml [1:34:50]. Этот язык считается одним из лучших для написания статических анализаторов.
2.  **Google:** Разработали инструмент **Pytype**. Особенность Google заключается в их гигантском монорепозитории, и Pytype был оптимизирован для работы в этой специфической среде [1:35:42]. В отличие от Pyre, он написан на самом Python.
3.  **Microsoft:** Их проект называется **Pyright** (Гвидо шутит, что автозамена часто исправляет его на «pyrite» — пирит) [1:40:13]. Microsoft надеется, что их инструмент станет лидером в этой гонке.

Интересно, что эти компании не просто проверяют типы, но и используют возможности интроспекции Python. Поскольку аннотации доступны в рантайме через метаданные функций, сторонние библиотеки могут использовать их для валидации данных «на лету», хотя это и замедляет выполнение программы [1:23:09].

### Линтеры и борьба с «грязным» кодом
[[JUMP:1:36:11]]

Гвидо разделяет понятия статического тайп-чекера и линтера. Линтер — это более широкий инструмент, который ищет вероятные ошибки, не нарушающие спецификацию языка, но подозрительные с точки зрения логики [1:36:52]. Например, линтер укажет на переменную, которая была определена, но ни разу не использовалась — для компилятора это валидный код, но для программиста это часто признак опечатки или забытого фрагмента [1:37:19].

Кроме того, линтеры часто выступают в роли «полиции стиля», проверяя соответствие кода стандарту PEP 8 [1:38:11]:

*   Начинаются ли имена классов с заглавной буквы?
*   Используется ли правильная схема именования переменных?
*   Не слишком ли длинные строки кода?

Хотя сам Гвидо признается, что иногда его раздражают жалобы линтера на регистр букв, он подчеркивает их важность для командной работы [1:38:37]. Тайп-чекеры же гораздо более дотошны: они не смотрят на стиль, но будут методично указывать на каждую попытку передать строку туда, где ожидается целое число [1:39:19]. В конечном итоге, использование этих инструментов в Python — это способ получить преимущества больших стабильных программных систем, сохраняя при этом ту «красивую путаницу» и скорость разработки, за которую Python так ценят.

## 🛠️ От Emacs до VS Code: инструментарий и философия многозадачности
[[JUMP:1:45:05]]

Выбор инструментов для программиста — это не просто вопрос удобства, а глубоко личная история, часто определяющая продуктивность на десятилетия. Гвидо ван Россум (Guido van Rossum) прошел длинный путь от классических консольных редакторов до современных интегрированных сред разработки (IDE). Несмотря на то что ранее в обсуждении затрагивались вопросы статической типизации и MyPy, инструменты, которые мы используем для написания такого кода, заслуживают отдельного внимания.

### Эволюция рабочего пространства: от классики до VS Code
[[JUMP:1:45:05]]

Гвидо начал свой путь с редактора Vim (в те времена еще называвшегося VI) в начале 80-х годов [1:45:21]. Однако на протяжении почти тридцати лет — до самого недавнего времени — его основным инструментом оставался Emacs. Для создателя Python Emacs был подобен старому комфортному автомобилю Toyota: ты проехал на нем сотни тысяч миль и знаешь значение каждого шороха в двигателе [1:46:03].

Тем не менее, работа в крупных компаниях требовала более мощных средств навигации. В период с 2013 по 2018 год, работая в Dropbox над кодовой базой объемом в 5 миллионов строк, Гвидо периодически использовал PyCharm [1:46:43]. Он сравнивает PyCharm с управлением огромной фурой (18-колесным грузовиком): этот инструмент обладает невероятной мощью и специализацией, особенно когда речь идет об индексации гигантских репозиториев и поиске определений классов. Однако, как только возникала необходимость в быстром редактировании или переключении между файлами, Гвидо возвращался в привычный Emacs [1:47:08].

Перелом произошел после перехода в Microsoft, когда Гвидо начал использовать VS Code. Он называет VS Code «духовным преемником Emacs» [1:50:42]. Основное сходство заключается в архитектуре:

*   **Минимальное ядро:** Как и Emacs, VS Code имеет неизменяемую основу, которая занимается лишь базовыми вещами: отрисовкой пикселей и управлением памятью [1:51:24].
*   **Экосистема расширений:** В Emacs функциональность наращивалась через Lisp-пакеты; в VS Code — через мощную систему плагинов, которые могут переопределять почти любой аспект поведения редактора [1:52:16].
*   **Культура сообщества:** VS Code доминирует благодаря открытости и легкости создания новых инструментов, в то время как разработка расширений для специализированных IDE вроде PyCharm часто является сложным процессом с плохой документацией [1:55:01].

Лекс Фридман (Lex Fridman) отмечает, что переход на новые инструменты напоминает обучение слепой печати: в краткосрочной перспективе это замедляет, но в долгосрочной — кардинально меняет психологию и продуктивность работы [1:47:45].

### Параллелизм и конкурентность: искусство управления вниманием
[[JUMP:1:56:48]]

Переходя от инструментов написания кода к логике его исполнения, Гвидо ван Россум разъясняет фундаментальные различия между параллелизмом и конкурентностью — понятиями, которые часто путают даже опытные разработчики.

Для объяснения конкурентности Гвидо использует метафору рыбака [1:57:01]. Представьте человека в лодке с одной удочкой. Большая часть его времени уходит на ожидание поклевки. Если рыбак инвестирует в покупку еще трех удочек, он сможет обслуживать четыре снасти одновременно. Это значительно повышает его продуктивность, хотя физически он всё еще один человек. Это и есть конкурентность (concurrency): способность справляться с несколькими задачами сразу, переключая внимание в моменты ожидания.

Различия формулируются следующим образом:

1.  **Параллелизм (Parallelism):** Это физическая реальность. Наличие нескольких копий оборудования (процессоров), которые одновременно выполняют разные вычисления [1:58:21].
2.  **Конкурентность (Concurrency):** Это во многом абстракция или иллюзия. Компьютер создает видимость одновременной работы, выделяя понемногу времени каждой программе по очереди [1:58:47].

Гвидо подчеркивает, что разработка многопоточных систем сложна из-за ограничений человеческого мозга [1:59:26]. Мы легко можем идти и жевать жвачку одновременно, так как это автоматические действия. Но попробуйте сводить баланс в чековой книжке и одновременно смотреть детектив — вы либо ошибетесь в цифрах, либо пропустите ключевую улику [1:59:53].

В программировании это выливается в проблему общего состояния. Если две части кода одновременно обращаются к одной переменной «А», где в одном случае «А» — это количество рыбаков, а в другом — количество русалок, смешивание этих контекстов приведет к катастрофе [2:01:30]. Для решения этой проблемы используются примитивы синхронизации:

*   **Замки (Locks):** Гвидо сравнивает их с табличкой на двери духовки в ресторане: «Духовка занята» [2:02:41]. Пока один шеф-повар печет торт, другой не может войти, даже если духовка просто прогревается.
*   **Семафоры (Semaphores):** Это более сложная система, подходящая для кухни с несколькими духовками. Электронное табло показывает: «Свободно 5 духовок из 10» [2:03:33]. Если все заняты, вы встаете в очередь и ждете, пока кто-то освободит ресурс.

Эти концепции стали фундаментом для создания AsyncIO в Python [2:04:15]. Гвидо вспоминает, что в конце 90-х в стандартную библиотеку были добавлены первые модули для неблокирующего ввода-вывода, позволявшие серверам обрабатывать тысячи соединений одновременно, не создавая отдельный поток для каждого [2:04:58]. Развитие этой идеи привело к современной модели асинхронности, которая позволяет эффективно тратить время не на ожидание ответа от базы данных или сети, а на полезные вычисления.

## ⚡ Конкурентность и «узкое горлышко» Python: история AsyncIO и GIL
[[JUMP:2:05:51]]

В начале 2010-х годов Гвидо ван Россум столкнулся с нарастающим запросом сообщества: стандартные модули `asyncore` и `asynchat` уже не справлялись с современными задачами сетевого программирования. Пользователи настойчиво просили добавить «хотя бы одну маленькую функцию» в существующие инструменты, но Гвидо понимал, что системе нужна фундаментальная переработка [2:06:43]. В итоге это вылилось в создание одного из самых масштабных предложений по улучшению Python (PEP), где Гвидо выступил в роли ведущего архитектора. 

### Архитектура AsyncIO: борьба с «кодом-спагетти»
[[JUMP:2:06:55]]

При проектировании библиотеки, ставшей известной как `AsyncIO`, Гвидо изучал опыт сторонних решений, существовавших на тот момент. Основная дискуссия развернулась вокруг двух парадигм обработки параллельного ввода-вывода (I/O) [2:08:01]. Первая — событийная модель на основе функций обратного вызова (callbacks), которая в то время доминировала в JavaScript. По мнению Гвидо, такой подход неизбежно приводил к созданию «кода-спагетти», который эстетически ему не нравился и был труден в поддержке [2:11:38]. 

Вторая парадигма — модель на основе задач (tasks) или сопрограмм (coroutines), где каждая задача обладает собственной логикой и состоянием. Гвидо выбрал именно этот путь, решив переиспользовать механизмы генераторов, уже существовавшие в языке [2:12:21]. В рамках этой модели поток выполнения не блокируется в ожидании сетевого пакета; вместо этого интерпретатор переключается на другие задачи, пока данные не будут готовы. Как отмечает ван Россум, этот подход оказался успешным и сегодня широко применяется в высокопроизводительных веб-клиентах и серверах [2:07:48].

### Происхождение и проклятие GIL
[[JUMP:2:13:00]]

Обсуждение AsyncIO неизбежно приводит к теме глобальной блокировки интерпретатора — знаменитого GIL (Global Interpreter Lock). Чтобы понять, зачем Python нужен этот механизм, Гвидо предлагает вернуться в начало 90-х. В те годы многопоточность была новой «игрушкой» операционных систем, таких как SunOS и Windows [2:13:39]. Когда в Python добавляли поддержку потоков, разработчики стремились сделать это быстро и безопасно. 

Создание потокобезопасного интерпретатора с нуля потребовало бы колоссального рефакторинга всего кода рантайма, так как объекты создавались в предположении, что с ними работает только один поток [2:16:28]. В итоге было принято компромиссное решение: разрешить создание системных потоков, но ограничить их выполнение одной глобальной блокировкой. Это работало идеально в эпоху одноядерных процессоров [2:16:41]. Однако по мере развития закона Мура производители чипов уперлись в физические пределы тактовой частоты и начали наращивать количество ядер. Именно тогда GIL превратился из удобного решения в «инфамную» проблему: пользователи обнаружили, что в Python дополнительные потоки не дают прироста скорости на многопроцессорных системах, так как все они по-прежнему выполняются по очереди на одном ядре [2:18:42].

### Будущее без блокировок: No-GIL и субинтерпретаторы
[[JUMP:2:18:42]]

Сегодня рассматривается несколько путей решения проблемы GIL. Наиболее вероятный сценарий для ближайших версий (начиная с 3.12) — внедрение механизма «субинтерпретаторов». В этой модели в рамках одного процесса запускаются полностью независимые интерпретаторы Python, каждый из которых имеет свой собственный GIL [2:19:06]. Это позволяет эффективно использовать все ядра процессора, хотя и усложняет коммуникацию между задачами, так как объекты нельзя просто разделять между потоками без риска возникновения ошибок конкурентности [2:20:13].

Параллельно существует проект «No-GIL» от Сэма Гросса (инженера из Meta), который разработал форк CPython без глобальной блокировки. Гвидо признает, что это интересная возможность, но выражает сомнение в целесообразности её слияния с основной веткой кода [2:21:48]. Отказ от GIL влечет за собой два серьезных последствия: 

*   Усложнение поддержки кода интерпретатора. 
*   Снижение производительности в однопоточном режиме (overhead), что затронет большинство существующих программ [2:21:07]. 

Ван Россум считает, что нынешнее состояние GIL — это своего рода «точка Златовласки» (идеальный баланс) для большинства пользователей, но признает, что не все в сообществе с ним согласны [2:22:17].

### Гипотетический Python 4.0 как способ «сбросить балласт»
[[JUMP:2:22:45]]

Хотя Гвидо шутливо замечает, что версия 4.0 может не появиться никогда (или это будет версия 3.999), он размышляет о том, что могло бы стать поводом для такого релиза. Память о болезненном переходе с Python 2 на Python 3 до сих пор жива в сообществе, и разработчики не хотят повторять тех ошибок [2:23:41]. 

Однако радикальное изменение архитектуры, такое как полное удаление GIL, могло бы стать веской причиной для смены мажорной версии. Проблема в том, что Python — это не только чистый код, но и огромная экосистема расширений на C, на которых держится весь мир Data Science и Machine Learning [2:27:00]. Даже если синтаксис языка останется прежним, удаление GIL сломает бинарную совместимость (ABI), и сотни тысяч библиотек придется перекомпилировать и, возможно, переписывать. Гвидо предполагает, что переход к Python 4.0 в таком случае должен занять годы: сначала No-GIL появится как опция при компиляции, чтобы разработчики расширений могли протестировать свои продукты, и лишь спустя долгое время этот режим станет стандартом [2:29:40].

## 🚀 Будущее Python 4.0 и триумф в машинном обучении

[[JUMP:2:31:16]]

### Призрак версии 4.0: Осторожность и уроки прошлого
[[JUMP:2:31:16]]

Обсуждая будущее языка, Гвидо ван Россум затрагивает тему, которая вызывает у сообщества одновременно интерес и легкую тревогу: возможность выхода Python 4.0. После крайне болезненного и затянувшегося на десятилетие перехода с Python 2 на Python 3, разработчики ядра стали крайне осторожны в вопросах мажорных обновлений. Гвидо отмечает, что цифра «4.0» в сознании многих стала символом радикальных изменений, ломающих обратную совместимость, чего команда сейчас старается избегать.

Однако потенциальный повод для смены основной версии существует. Гвидо предполагает, что Python 4.0 может стать реальностью, когда режим «без GIL» (Global Interpreter Lock) станет стандартом по умолчанию [2:31:44]. Это будет момент «торжественного перерезания ленточки», означающий, что новая архитектура API полностью готова и поддержка сторонних модулей расширения стала стабильной. Ранее в разговоре Лекс и Гвидо уже касались технических деталей ускорения интерпретатора и работы GIL, но именно официальный статус «no-GIL» может стать тем водоразделом, который оправдает новую цифру в названии.

Параллельно с этим в стандартной библиотеке происходит процесс, который Гвидо называет «весенней уборкой» [2:33:37]. 

*   Разработчики удаляют старые модули, созданные еще в начале 90-х.
*   Многие из них не обновлялись по существу десятилетиями, претерпевая лишь косметические правки стиля отступов [2:34:30]. 
*   Вместо того чтобы тянуть устаревший код в составе дистрибутива, команда стимулирует пользователей переходить на более динамично развивающиеся сторонние пакеты. 

### Почему Python победил в гонке за ИИ и Data Science
[[JUMP:2:34:44]]

Один из самых интересных феноменов в истории программирования — то, как Python, изначально задуманный как язык для автоматизации и обучения, стал доминирующим инструментом в глубоком обучении и науке о данных. Лекс Фридман задается вопросом: почему именно Python, а не Perl, Java или специализированный Matlab?

Гвидо сравнивает это с правилами дорожного движения: «Мы все ездим по правой стороне дороги, потому что так договорились для общей безопасности» [2:35:25]. В начале 2000-х казалось, что в биоинформатике победит Perl, так как работа с ДНК завязана на регулярных выражениях, в которых Perl традиционно силен [2:36:06]. Однако Python предложил нечто более важное — гибкость и удобство взаимодействия с низкоуровневым кодом.

Ключевым фактором стала потребность ученых в «вычислительном управлении» (computational steering) [2:37:02]. В таких организациях, как Ливерморская национальная лаборатория, десятилетиями использовались мощные библиотеки на Fortran и C++ для решения математических задач. Ученым нужен был высокоуровневый язык, чтобы связывать эти алгоритмы воедино, не погружаясь в дебри управления памятью. Python идеально подошел на роль этого «клея».

### От «пыльных колод» Fortran до Hubble Space Telescope
[[JUMP:2:38:24]]

Интересно, что сам Гвидо ван Россум при создании языка не планировал его использование для интенсивных вычислений с массивами чисел. Он считал массивы устаревшим типом данных, отдавая предпочтение объектам и строкам [2:39:02]. Однако расширяемость Python позволила сообществу создать сторонние пакеты для эффективной работы с многомерными массивами, что позже вылилось в создание NumPy и SciPy.

История успеха Python в науке ковалась в конкретных сообществах:

1.  **Специалисты Hubble Space Telescope:** В конце 90-х команда в Балтиморе стала одними из первых крупных фанатов Python, используя его для обработки данных с телескопа [2:39:39].
2.  **Обмен кодом:** Ученые, решающие разные задачи (от поиска галактик до анализа звезд), обнаружили, что могут использовать общие библиотеки для линейной алгебры, написанные на Python.
3.  **Интерфейс для ИИ:** Когда появились современные фреймворки вроде TensorFlow и PyTorch, Python уже был «родным» языком для целевой аудитории. Разработчики просто использовали его как наиболее привычный интерфейс для управления мощными вычислениями на C++ и GPU [2:41:21].

### Культура открытого кода против проприетарных гигантов
[[JUMP:2:42:16]]

Лекс Фридман отмечает, что в инженерной среде долгое время доминировал Matlab, но он проиграл Python в долгосрочной перспективе. Главная причина — закрытость системы. Matlab был дорогим проприетарным продуктом [2:42:28]. Даже если университеты могли себе его позволить, он не вписывался в зарождающуюся культуру GitHub и открытого обмена знаниями.

Python победил благодаря своей «эгалитарности» [2:43:20]. Чтобы внести вклад в экосистему Python, не нужно работать в огромной техкорпорации. Гвидо подчеркивает, что фонд PSF (Python Software Foundation) тратит большую часть средств не на саму разработку языка, а на развитие сообщества, поддержку конференций и создание инклюзивной среды [2:44:15]. Именно эта «виральность» и культура хакеров-энтузиастов сделала язык стандартом де-факто в ИИ. 

Позже в беседе Гвидо затронул тему своего ухода с поста BDFL и разницу в корпоративных культурах Microsoft, Google и Dropbox, но эти аспекты его биографии заслуживают отдельного детального рассмотрения.

## 🧬 Наследие, ИИ и биология кода
[[JUMP:2:56:04]]

### От «диктатора» к рядовому инженеру: рефлексия и корпоративные культуры
[[JUMP:2:56:17]]

Завершая многолетний путь в качестве «великодушного пожизненного диктатора» (BDFL) Python, Гвидо ван Россум пришел к важным выводам о природе лидерства и личного комфорта в индустрии. Ранее в разговоре он упоминал о стрессе, который сопровождал его на посту лидера сообщества, и теперь он открыто признает: его истинная страсть — быть «индивидуальным контрибьютором» (Individual Contributor), а не менеджером [2:59:14]. Гвидо разделяет программистов на две категории: тех, кто способен вырасти из создателя продукта в руководителя огромных команд, и тех, кто предпочитает оставаться у терминала.

Сравнивая свой опыт и культуру в технологических гигантах, Гвидо отмечает разные модели успеха:

*   **Dropbox:** Гвидо вспоминает основателя Дрю Хьюстона, который прошел путь от технического изобретателя до полноценного CEO, сохранив вовлеченность в продукт на протяжении многих лет [2:58:21]. Для многих это эталон, но Гвидо подчеркивает, что не каждый блестящий инженер обладает набором навыков для управления тысячью сотрудников [2:57:23].
*   **Microsoft и Google:** В крупных корпорациях Гвидо видит возможность для «внутреннего предпринимательства». По его мнению, талантливый разработчик может создать что-то значимое внутри гиганта, быстро подняться по карьерной лестнице или же, напротив, переключиться на изобретение новой «сумасшедшей штуки», когда проект разрастается и требует административного управления [2:57:49].

Сам создатель Python самокритично относит себя ко второй категории — людей, которые любят писать код (иногда с полудня до полуночи, семь дней в неделю), но чувствуют себя «ужасными менеджерами» [2:59:02]. Именно поэтому переход к новой системе управления языком (руководящему совету) и работа в Microsoft в роли инженера стали для него освобождением от бремени власти, мешавшей чистому творчеству.

### GitHub Copilot: нейросетевой «партнер по танцу»
[[JUMP:3:03:05]]

Обсуждая современные инструменты, Гвидо признается, что использует GitHub Copilot ежедневно. Несмотря на статус создателя языка, он не считает зазорным пользоваться подсказками ИИ. Гвидо называет Copilot своим «партнером по танцу», хотя и делает важную оговорку: нейросеть часто ошибается, но всё равно экономит массу времени [3:03:21].

Для ван Россума польза Copilot заключается в нескольких аспектах:

1.  **Скорость набора текста:** Гвидо в шутку называет себя «плохим машинистом». ИИ избавляет его от необходимости вводить повторяющиеся конструкции — достаточно написать «begin», и Copilot автоматически завершает строку с «end», правильно угадывая контекст [3:03:48].
2.  **Работа с API:** Вместо того чтобы судорожно искать в документации, называется ли метод `foo` или `bar`, и какую структуру имеет фабрика объектов, Гвидо полагается на подсказки ИИ, которые всплывают мгновенно [3:05:51].
3.  **Генерация шаблонов:** Иногда правильно названная функция позволяет ИИ сгенерировать 5–10 строк кода, в которых опытному программисту остается лишь поправить одно слово или логическую неточность [3:04:04].

Гвидо категорически не согласен с тем, что ИИ угрожает профессии программиста. Он сравнивает это с появлением Stack Overflow: инструменты автоматизации лишь забирают на себя «скучную часть» работы [3:05:10]. Творческий процесс — решение о том, *что именно* должен делать код — остается исключительно за человеком. Он советует новичкам не использовать ИИ для того, чего они еще не понимают, а применять его как продвинутого ассистента, напоминающего детали реализации [3:05:24].

### Философия абстракций: Python как «митохондрия» цифрового мира
[[JUMP:3:06:04]]

Взгляды Гвидо на будущее Python пропитаны биологическим детерминизмом. Он предполагает, что через 50 или 100 лет Python станет своего рода «legacy-языком», который превратится в базовую невидимую структуру, подобно митохондриям в биологических клетках [3:06:43]. Большинство людей не будут знать, как он устроен, но всё цифровое общество будет функционировать поверх этих слоев абстракции.

Гвидо проводит глубокую параллель между архитектурой компьютера и биологическими системами:

*   **Абстракция уровней:** Современные программисты редко сталкиваются с двоичной арифметикой [3:07:10]. Сам Гвидо в юности строил логические схемы из транзисторов и резисторов, понимая работу компьютера на уровне вентилей NAND [3:07:24]. Однако он признает, что сегодня можно быть успешным разработчиком, считая физический уровень «магией».
*   **Мозг как интерпретатор:** Человеческий мозг — это невероятно сложная параллельная система (например, при распознавании образов), которая на уровне сознания и речи «эмулирует» однопоточный, последовательный интерпретатор [3:11:30]. Мы думаем и говорим шаг за шагом, имитируя выполнение кода.
*   **ДНК как исходный код:** Гвидо называет ДНК кодом, который содержит не только информацию, но и инструкцию по сборке «железа» (организма) [3:11:43]. В отличие от покупки готового компьютера, в биологии мы имеем дело с «семенем», которое само выстраивает вычислительную систему.

Этот процесс бесконечного усложнения — от клетки к организму, от организма к цивилизации — напоминает Гвидо развитие программного обеспечения. Мы строим слои поверх слоев, и Python — лишь один из этих этапов. Завершая беседу, Гвидо философски замечает, что с точки зрения инопланетного наблюдателя вся жизнь на Земле (включая её код и технологии) может выглядеть как единый, самовоспроизводящийся организм [3:14:49].