# Код, объединяющий нации: история создателя NumPy и SciPy

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

---

«Нации, которые пишут код вместе, не воюют друг с другом», — убежден создатель NumPy и SciPy Трэвис Олифант, положивший начало современной экосистеме Python для работы с данными. Ради спасения разрозненного научного сообщества он совершил программный подвиг и пожертвовал академической карьерой, а позже создал Anaconda, чтобы раз и навсегда решить проблему распределения сложного софта. Это история о том, как идеализм программиста, подкрепленный классической экономической теорией, трансформировал мировую IT-индустрию и заложил фундамент для бума искусственного интеллекта.

## 💻 От первых циклов на Atari до философии «исполняемого английского»

[[JUMP:01:07]]

Путь Трэвиса Олифанта в программировании начался в четвёртом классе с простого цикла в BASIC на компьютере Atari 400 (или 800 — точно вспомнить спустя десятилетия уже трудно) [01:20]. Это было время «операторов GOTO», которые позже стали считаться признаком плохого тона. Первый важный урок Трэвис усвоил именно тогда: в программировании существуют принципы и правила «красивого кода» [01:46]. Настоящее осознание этих принципов пришло к нему позже, в старших классах, во время курса AP Computer Science на языке Pascal [02:00]. До этого он много программировал на калькуляторах TI, но именно Pascal открыл ему глаза на системную инженерию программного обеспечения.

Любовь к коду закрепилась в возрасте десяти лет, когда отец Трэвиса купил компьютер Timex Sinclair [02:26]. Хотя отца больше интересовали электронные таблицы, Трэвис настоял на покупке модуля расширения памяти для программирования на BASIC. Позже появился TI-99/4A с его спрайтами, графикой и возможностью создавать музыку [02:52]. Хранение программ в те времена было физическим процессом: приходилось использовать кассетный магнитофон, и Трэвис до сих пор помнит специфический звук превращения цифровых битов в аудиофайлы [03:28].

Для Олифанта компьютер никогда не был просто игрушкой. Его всегда тянуло к математике, и программирование стало для него «прикладным решением задач» [04:20]. Он отмечает, что многие дети не любят математику, потому что на ранних этапах она сводится к запоминанию (например, таблицы умножения), но для него, обладающего хорошей краткосрочной памятью, это стало дверью в мир логических головоломок [04:08]. Со временем Трэвис пришёл к выводу, что язык — будь то человеческий или компьютерный — напрямую определяет границы мышления. 

### Влияние языка на мышление и концепция «исполняемого английского»
[[JUMP:05:13]]

Обсуждая лингвистику, Трэвис Олифант и Лекс Фридман сходятся на мысли, что язык не просто передаёт информацию, но и направляет разум по определённым траекториям [07:35]. Трэвис, свободно владеющий испанским, вспоминает момент, когда он начал видеть сны на этом языке — это изменило его восприятие мира [05:13]. Этот же феномен он переносит и на программирование: некоторые языки ограничивают вас, другие — расширяют горизонты.

Когда Трэвис впервые столкнулся с Python в 1997 году, будучи аспирантом в клинике Мэйо (Mayo Clinic), он искал инструмент для обработки данных МРТ и ультразвука [09:35]. До этого он использовал:

*   Matlab для инженерных расчётов;
*   Perl для скриптов;
*   Fortran в связке со скриптовыми инструментами на системах VAX/VMS [10:01].

Python привлёк его тем, что позволял думать на языке задачи, а не на языке реализации. Трэвис называет это «исполняемым английским» (executable English) [21:31]. В отличие от Perl, который он активно использовал в 1995 году, код на Python оставался понятным даже спустя год после написания [13:54]. Это стало решающим фактором: Трэвису был нужен инструмент, который не требовал бы от учёного становиться «профессиональным программистом» ради решения физических задач [17:11]. Python позволял задействовать языковой центр мозга, отвечающий за английскую речь, что делало синтаксис прозрачным и интуитивным [16:33].

### Философия Python: читаемость против краткости Perl
[[JUMP:09:09]]

В 1990-х годах в культуре программирования доминировал подход, при котором компактность кода считалась признаком мастерства. Perl был королём этого подхода: чем меньше символов занимала программа, тем больше гордился собой автор [16:05]. Однако Трэвис обнаружил, что такая «красота» оборачивается нечитаемостью. Python предложил альтернативу: чистоту визуального поля.

Одним из самых спорных решений Гвидо ван Россума (создателя Python) было использование отступов вместо фигурных скобок для выделения блоков кода [14:34]. Трэвис признаёт, что это создавало определённые технические сложности — например, при копировании кода в терминал или из-за смешивания табуляции и пробелов [15:12]. Но отсутствие «лишних символов» позволило взгляду фокусироваться на логике, а не на синтаксическом шуме [15:39].

Для научной работы Олифанту требовались специфические абстракции, которых в базовом Python изначально не было:

1.  **Массивы (Arrays):** Библиотека `numeric` (предшественник NumPy), созданная Джимом Хагунином (Jim Hugunin) в 1995 году, заполнила этот пробел [10:26]. 
2.  **Комплексные числа:** Для инженера-электрика отсутствие встроенных комплексных чисел — это катастрофа, так как они критически важны для преобразований Фурье (FFT) [11:43].
3.  **Broadcasting (трансляция):** Возможность выполнять операции над целыми массивами без написания явных циклов [22:48].

Трэвис отмечает, что Python стал идеальным «клеем» благодаря своей расширяемости на языке C [25:12]. В 1998 году он написал свой первый модуль расширения на C для чтения медицинских файлов формата DICOM [24:45]. Это сочетание высокоуровневого языка для размышлений и возможности спуститься на уровень железа через C-расширения стало фундаментом, на котором позже вырастут SciPy и NumPy. 

Олифант подчеркивает, что такие абстракции, как N-мерные массивы, меняют то, как учёный смотрит на данные. Вместо того чтобы думать об отдельных числах, вы начинаете мыслить объектами в N-мерном пространстве [19:46]. Хотя ранее это было реализовано в языке APL (60-е годы) и в Matlab, именно Python сделал эти концепции доступными для широкого сообщества, не навязывая авторитарных структур и сложных синтаксических глифов [08:56].

## 🛠️ От наследия Fortran к экономике созидания
[[JUMP:25:25]]

### Архитектура SciPy: Обуздание Fortran и магия компиляции
[[JUMP:25:25]]

В конце 1990-х годов Трэвис Олифант столкнулся с классической проблемой исследователя: необходимостью писать сложный код на C для обработки данных МРТ, что постоянно отвлекало его от основной научной задачи. «Это как вставлять новый картридж в мозг, — вспоминает он, — теперь я должен думать об указателях и управлении памятью вместо физики процесса» [25:38]. Python предлагал избавление от этой ментальной нагрузки, но ему не хватало вычислительной мощности.

Решение пришло через Netlib — онлайн-репозиторий сотен подпрограмм на Fortran, написанных ещё в 60-х, 70-х и 80-х годах. Несмотря на почтенный возраст, эти библиотеки (такие как QUADPACK для интеграции и ODEPACK для решения дифференциальных уравнений) оставались золотым стандартом численных методов. Трэвис Олифант начал строить «мосты» между высокоуровневым Python и этими эффективными Fortran-рутинами [26:43]. 

Этот процесс начался в 1998 году с написания расширений для Python, которые Трэвис поначалу выпускал как отдельные модули. Постепенно они объединились в пакет `multi-pack`. Однако в те времена дистрибуция софта была «диким западом»: релиз представлял собой обычный tar-архив с исходным кодом, выложенный на примитивной веб-странице [27:36]. Переломный момент наступил в 1999 году, когда старшеклассник Роберт Керн (Robert Kern) создал для этих наработок установщик под Windows [32:58]. Появление бинарного инсталлера привело к взрывному росту числа пользователей, так как ученым больше не нужно было возиться с компиляцией сложного кода.

Официальное рождение бренда SciPy произошло в 2001 году в Остине, штат Техас. Трэвис Олифант объединил усилия с Эриком Джонсом (Eric Jones) и Трэвисом Воттом (Travis Vaught), основателями компании Enthought [35:09]. Они решили собрать разрозненные модули Олифанта и наработки других энтузиастов (таких как Пиру Петерсон из Эстонии) в единую библиотеку. В то время SciPy задумывался не просто как библиотека, а как целая среда для исследований и разработок, которая должна была включать даже средства построения графиков [36:14].

### Социальная динамика и «круг эмпатии» в open source
[[JUMP:31:03]]

Работа над SciPy открыла для Олифанта иную сторону интеллектуального труда, резко контрастирующую с академической средой. В науке публикация статьи часто сопровождается жесткой конкуренцией и желанием коллег «подловить» автора на ошибке [31:53]. В мире открытого ПО Трэвис обнаружил атмосферу сотрудничества, которая его «опьянила»: люди со всего мира начали присылать исправления и улучшения [31:41].

Лекс Фридман отмечает, что такой подход требует особого «круга эмпатии» — способности разработчика думать о том, как сделать инструмент максимально доступным для людей, не являющихся программистами. Олифант сравнивает этот процесс с «покупкой в один клик» на Amazon: любая точка трения (необходимость компилировать код, сложная настройка) отсеивает пользователей [30:50]. Именно поэтому создание бинарных установщиков стало для SciPy критическим фактором успеха.

Однако масштабирование проекта принесло и новые вызовы. Олифант признает, что при достижении определенного масштаба в open source-сообществах наступает предел кооперации. «Слишком много поваров на кухне» приводит к политическим спорам и трудностям в достижении консенсуса, что делает управление продуктом в открытой среде гораздо сложнее, чем в закрытой корпорации [36:39].

### Дилемма создателя: Капитализм и уроки австрийской школы
[[JUMP:40:31]]

Параллельно с техническим развитием SciPy, Трэвис Олифант проходил через личную трансформацию. К моменту окончания аспирантуры в 2000 году у него уже было трое детей (сейчас их шестеро), и вопрос выживания семьи стоял крайне остро [40:44]. Столкнувшись с философией Ричарда Столлмана, который на вопрос о заработке в open source однажды ответил «просто будь как я и не заводи детей», Олифант понял, что этот путь ему не подходит [41:09]. 

Это побудило его к глубокому изучению экономики. Трэвис Олифант, будучи лучшим учеником в школе и отличником в университете, с удивлением обнаружил, что современная система образования оставляет студентов «экономически невежественными» [41:47]. В поисках ответов он погрузился в чтение трудов Адама Смита и представителей австрийской школы экономики, в частности Людвига фон Мизеса.

Ключевым открытием для него стала работа Мизеса 1920 года об экономическом расчете [43:20]. Олифант осознал важность ценовых сигналов как механизма передачи информации в обществе:

*   Без частной собственности и обмена невозможно сформировать цены [43:45].
*   Без цен бюрократы не могут эффективно распределять ресурсы.
*   Деньги — это не просто бумажки, а важнейший инструмент коммуникации внутри продуктивного сообщества [44:10].

Эти знания изменили его отношение к разработке ПО. Трэвис Олифант пришел к выводу, что для устойчивого развития технологий недостаточно быть просто хакером — необходимо быть предпринимателем. Несмотря на то, что он не разбогател напрямую на использовании SciPy миллионами людей, изучение экономики позволило ему смотреть на мир без горечи [45:14]. Вместо того чтобы жалеть о «недополученной выгоде», он сосредоточился на создании новых бизнес-моделей, которые позволили бы открытому ПО сосуществовать с рыночной экономикой.

### Философия проектирования: Инструменты как строительные блоки
[[JUMP:47:39]]

В основе SciPy лежали четкие архитектурные принципы: предоставлять ученым и инженерам функции, о реализации которых им не нужно задумываться. Олифант стремился к «правильной длине именования»: в отличие от Fortran, где имена ограничивались шестью символами, или некоторых современных языков с избыточно длинными названиями, SciPy должен был быть интуитивно понятным [48:07].

Важнейшим элементом стала документация. Для научных библиотек она должна быть многоуровневой: краткий заголовок функции дает интуитивное понимание, а глубокое описание раскрывает все математические нюансы и опции [48:32].

Этот опыт проектирования инструментов Трэвис перенес и в свою преподавательскую деятельность в Университете Бригама Янга (BYU), где он вел курсы по цифровой обработке сигналов и электромагнетизму [49:36]. Он с иронией вспоминает свои отзывы на «Rate My Professor»: студенты часто жаловались на слишком высокий уровень абстракции. «У меня была проблема с калибровкой, — признается Олифант. — Я слишком уважал студентов и ошибочно полагал, что они уже знают столько же, сколько и я» [50:02]. Эта же вера в потенциал пользователя вела его и при создании SciPy — инструмента, созданного ученым для ученых.

## 🛠️ Миссия по спасению сообщества: рождение NumPy и разрыв с академией
[[JUMP:50:15]]

Создание SciPy, о котором шла речь ранее, было лишь началом пути. К середине 2000-х годов сообщество Python-программистов, занимавшихся научными вычислениями, оказалось на грани катастрофического раскола. Трэвис Олифант (Travis Oliphant) вспоминает этот период не просто как технический вызов, а как экзистенциальный кризис для всей экосистемы, который потребовал от него личных жертв и принятия роли «миротворца» от программирования.

### Объединение Numeric и Numarray: остановить раскол
[[JUMP:50:53]]

Проблема заключалась в существовании двух конкурирующих библиотек для работы с массивами. Исторически существовал пакет Numeric, но команда из Института космического телескопа «Хаббл» (Hubble Space Telescope), возглавляемая Перри Гринфилдом, создала альтернативу — Numarray [51:31]. Им требовались возможности, которых не было в Numeric: поддержка очень больших массивов, расширенные типы данных и более гибкое индексирование.

К 2005 году ситуация стала критической. Библиотеки не были совместимы: данные нельзя было передавать из одной в другую без копирования в памяти [53:26]. Это означало, что если один исследователь писал код для обработки изображений на Numarray, а другой — для линейной алгебры на Numeric, их инструменты не могли работать вместе.

> «Меня это ужасно раздражало. Я видел, что мы перестали сотрудничать, мы начали переделывать работу друг за другом в этом совсем ещё молодом сообществе», — объясняет Трэвис [53:40].

Трэвис Олифант (Travis Oliphant) принял решение, которое Лекс Фридман (Lex Fridman) позже назовёт «героическим актом лидерства» [56:13]. В 2005 году, воспользовавшись паузой в учебном расписании, Трэвис в одиночку начал писать NumPy — библиотеку, которая должна была объединить лучшее из обоих миров. Его главной целью было обеспечить обратную совместимость, чтобы примирить враждующие лагеря [1:01:15]. 

Основные инновации, которые он привнёс в NumPy за те интенсивные четыре месяца разработки:

*   Создание объекта **dtype**, описывающего структуру данных в памяти [59:48].
*   Реализация продвинутого индексирования (маски и косвенная адресация) [1:00:00].
*   Унификация механизма широковещания (broadcasting) для математических операций [1:00:00].

Успех пришёл в 2006 году, когда Джон Хантер, создатель Matplotlib, объявил, что его библиотека переходит на NumPy как на единственную зависимость. Для Трэвиса это стало моментом триумфа: сообщество снова стало единым [1:06:00].

### Конфликт с академической средой и цена успеха
[[JUMP:1:06:50]]

За создание фундаментального инструмента современной науки Трэвису пришлось заплатить своей академической карьерой. В 2004 году, будучи на пути к получению пожизненного профессорства (tenure) в Университете Бригама Янга, он получил первый тревожный сигнал от коллег. Ему прямо сказали: «Ты тратишь слишком много времени на этот open source. Пиши больше статей и грантов» [53:52].

Трэвис столкнулся с фундаментальным непониманием роли программного обеспечения в науке. Университетская иерархия того времени не считала написание кода за «настоящую» научную деятельность. В глазах комиссии разработка NumPy была чем-то вроде написания учебника или методического пособия — похвально, но не заслуживает повышения [54:05].

Это привело к следующим последствиям:

1.  **Поляризация кафедры:** Трэвис стал «спорной фигурой». У него были как ярые сторонники, понимавшие масштаб его вклада, так и противники, считавшие его работу недостаточно академичной [1:07:29].
2.  **Отказ в tenure:** В 2007 году комиссия предложила ему «прийти через два года и попробовать снова». Это было вежливой формой отказа [1:07:41].
3.  **Уход в бизнес:** Разочаровавшись в бюрократии, Трэвис покинул академию и переехал в Остин, штат Техас, чтобы заняться предпринимательством [1:08:59].

Несмотря на риск (у Трэвиса на тот момент было уже пятеро детей), он чувствовал ответственность перед сообществом. Его вера в то, что создание общего блага важнее личного финансового счёта или титула, стала определяющей в его жизненной философии [57:47].

### «Guide to NumPy» и поиск новых моделей финансирования
[[JUMP:1:10:57]]

Поскольку университеты отказывались финансировать разработку NumPy, Трэвису пришлось искать альтернативные способы поддержки своих студентов. Он решил применить подход «документально-ориентированной разработки». Чтобы систематизировать знания и собрать средства, он написал книгу «Guide to NumPy» [1:12:14].

Модель продажи была экспериментальной для того времени:

*   Он продавал книгу самостоятельно через PayPal по цене, которую определял рынок [1:14:27].
*   Трэвис пообещал, что как только книга соберёт 250 000 долларов (или пройдёт 5 лет), он сделает её текст бесплатным и открытым [1:13:47].
*   За три года ему удалось заработать около 90 000 долларов, продав 30 000 копий. Этих денег хватило, чтобы оплатить обучение его аспиранта [1:14:27].

Этот эпизод не только помог NumPy выжить, но и позже неожиданно принёс плоды в бизнесе. Директор проекта в DARPA Крис Уайт вспомнил имя Трэвиса именно благодаря этой книге, что годы спустя помогло проекту Anaconda получить государственное финансирование [1:14:01]. Уход из университета открыл Трэвису глаза на то, что капитализм и прибыль могут быть «механизмом координации ресурсов», который позволяет создавать магию в масштабах, недоступных отдельным лабораториям [1:11:09].

## 🌀 Архитектурные грехи NumPy и «платоническая форма» массивов
[[JUMP:1:17:54]]

В 2012 году Трэвис Олифант опубликовал прощальное письмо в почтовой рассылке NumPy, объявив о своём уходе из активной разработки проекта. Оглядываясь назад, создатель библиотеки признаёт, что несмотря на колоссальный успех, архитектура NumPy несёт в себе следы поспешных решений и технического долга. Одной из главных «ошибок» Олифант называет систему типов. В NumPy используются так называемые скаляры массивов (array scalars) — это объекты Python, которые заменяют отсутствующие в стандартном языке типы данных (например, 16-битные целые числа или 32-битные числа с плавающей запятой) [1:18:57]. 

Проблема заключалась в том, что Трэвис проектировал эту систему во времена Python 1, не до конца осознав мощь нововведений Python 2. В более поздних версиях Гвидо ван Россум внедрил мета-объекты, позволяющие пользовательским классам становиться полноценными типами системы. «Я создал систему типов в эпоху Python 1, где каждый d-тип — это экземпляр одного и того же типа, вместо того чтобы сделать новые d-типы настоящими типами Python с метаданными», — объясняет Олифант [1:20:28]. Это привело к излишней громоздкости: сегодня создание новых типов (например, кватернионов или специфических форматов для ИИ) остаётся неоправданно сложной задачей [1:20:55].

Ещё одним серьёзным сожалением является отсутствие ранней нативной поддержки графических процессоров (GPU). Сегодня разработчикам приходится скачивать сторонние библиотеки вроде CuPy, чтобы работать с массивами на видеокартах, хотя фундаментальных причин, почему это не могло быть частью ядра NumPy, не существует [1:21:48]. Олифант отмечает, что NumPy стал своего рода «платонической формой» многомерных массивов, которую позже пытались имитировать создатели TensorFlow и PyTorch [1:22:14]. Однако из-за того, что эти гиганты пришли в мир Python слишком поздно, возникла фрагментация сообщества, которую Трэвис сейчас пытается исправить через инициативу Data-APIs.org — попытку унифицировать интерфейсы различных библиотек массивов [1:23:07].

### Противостояние корпораций и хакеров: уроки TensorFlow
[[JUMP:1:24:23]]

Анализируя развитие индустрии, Трэвис Олифант вспоминает, как Google и Facebook (ныне Meta) адаптировали свои инструменты под нужды Python-сообщества. Изначально TensorFlow создавался как библиотека на C++, и её первый интерфейс для Python был, по словам Трэвиса, «ужасным» [1:25:13]. На одной из конференций он даже прямо заявил представителю Google, что такую архитектуру API больше никогда не стоит показывать публике [1:25:25]. Ситуация исправилась только с интеграцией Keras.

В этом контексте Олифант выделяет две разные философии управления проектами:

*   **Google (TensorFlow):** Ориентирован на крупных корпоративных клиентов. Вклад сторонних разработчиков в ядро затруднён, а фокус смещён на нужды внутреннего производства компании [1:26:16].
*   **Facebook (PyTorch):** Оказался более открытым к предложениям сообщества и структуре, созданной исследователями (FAIR), что позволило библиотеке быстрее завоевать симпатии «хакеров» [1:25:52].

Трэвис подчеркивает, что всегда старается «быть на стороне людей» [1:26:43]. По его мнению, если лелеять сообщество хакеров и энтузиастов, в долгосрочной перспективе это приведет к правильным техническим решениям, которые в итоге сделают счастливыми и корпорации. Однако баланс хрупок: излишняя забота о хакерах при отсутствии финансирования может привести к гибели проекта, что сам Олифант не раз ощущал на себе, пытаясь найти средства на поддержку NumPy в ранние годы [1:27:10].

### Гвидо ван Россум: Диктатор, слушатель и великий переход на Python 3
[[JUMP:1:28:42]]

Отношения Трэвиса Олифанта с создателем Python Гвидо ван Россумом всегда строились на взаимном уважении, хотя они и не были близкими друзьями. Трэвис вспоминает их знаковую встречу за ланчем в Сан-Маттео в 2005 году, где он пытался убедить Гвидо включить NumPy в состав стандартной библиотеки Python 3 [1:29:49]. Идея не была реализована полностью, но Олифанту удалось внедрить в ядро C-Python объект `memoryview`, который заложил фундамент для эффективной работы с памятью в языке [1:30:53].

Гвидо обладал редким качеством для лидера — он умел делегировать и доверять в областях, в которых не был экспертом. «В вопросах науки он просто уступал нам дорогу, хотя не всегда понимал, что именно мы делаем», — отмечает Трэвис [1:30:28]. Тем не менее, это доверие имело границы. Например, оператор матричного умножения (`@`) появился в Python на 10 лет позже, чем следовало, просто потому что сообществу потребовалось колоссальное время, чтобы доказать его необходимость Гвидо [1:30:41].

Обсуждая «трагический» уход Гвидо с поста «Пожизненного благородного диктатора» (BDFL) после споров вокруг оператора присваивания («моржового оператора»), Трэвис выражает сочувствие коллеге [1:32:27]. Давление лидерства, критика в соцсетях и приписывание дурных намерений — это то, с чем сталкивается любой создатель масштабного продукта. Олифант призывает аудиторию «предполагать добрые намерения, пока не доказано обратное», так как негативизм в открытом коде разрушает желание созидать [1:37:29].

Разговор коснулся и болезненного перехода с Python 2 на Python 3. По мнению Трэвиса, процесс затянулся на десятилетие, потому что в версиях 3.0 и 3.1 было «слишком много изменений без новых функций» [1:39:28]. Только с выходом версии 3.3, когда преимущества стали очевидными (включая тот самый матричный оператор в 3.5), инерция сообщества была преодолена. Это стало уроком для всей индустрии: невозможно заставить людей сменить инструмент, просто «исправив то, что не нравится создателю», не предложив пользователю реальную добавленную стоимость [1:39:16].

## 🌍 Код за мир и магия Numba: как ускорить Python до уровня C

[[JUMP:1:40:19]]

В мире высокопроизводительных вычислений часто возникает дилемма: удобство написания кода против скорости его выполнения. В разговоре с Лексом Фридманом Трэвис Олифант (Travis Oliphant) затрагивает этот конфликт, вспоминая любопытный случай с Андреем Карпати (Andrej Karpathy). Карпати, возглавляющий команду автопилота в Tesla, однажды заметил, что замена `np.sqrt` (извлечение квадратного корня в NumPy) на стандартную функцию `math.sqrt` или даже на возведение в степень `** 0.5` в обычном Python даёт значительный прирост производительности [1:41:38]. 

Трэвис объясняет этот парадокс внутренним устройством NumPy. Когда вы вызываете функцию NumPy для одиночного числа (скаляра), она проходит через ту же сложную «машинерию», что и массив из десяти тысяч элементов. Происходит приведение типов, проверка форм и широковещание (broadcasting), что создаёт накладные расходы [1:42:31]. Ранее в интервью они обсуждали, что NumPy создавался для работы с массивами, и именно там он раскрывает свою мощь. Для задач, где элементов меньше тысячи, чистый Python может оказаться быстрее [1:42:56]. Однако именно желание сохранить элегантный синтаксис Python, не жертвуя скоростью в циклах, привело Трэвиса к созданию Numba.

### Магия Numba: компиляция Python через LLVM
[[JUMP:1:56:54]]

Numba родилась из мечты о «компиляторе для синтаксиса Python». Трэвис Олифант (Travis Oliphant) осознал, что пользователям часто нужно написать обычный цикл `for`, но заставить его работать со скоростью компилируемого языка C. Традиционный совет в NumPy — «векторизуйте код», то есть избавляйтесь от циклов в пользу операций над массивами [1:47:32]. Но векторизация иногда требует огромных затрат памяти для создания промежуточных массивов.

Проект Numba, начатый в 2012 году в рамках Anaconda, предложил другой путь — Just-In-Time (JIT) компиляцию [1:58:50]. Трэвис вспоминает, как учился привлекать инвестиции от «друзей, семьи и дураков», чтобы воплотить эту амбициозную идею в жизнь [1:59:03]. Технически Numba работает так:

*   Она берет подмножество синтаксиса Python (в основном математику и циклы) и транслирует байт-код Python в промежуточное представление LLVM [1:59:42].
*   LLVM (Low Level Virtual Machine) — это мощный современный инструментарий компиляции, который Трэвис называет «плато для сотрудничества», где разработчики разных языков могут объединять усилия [2:03:36].
*   С помощью декоратора `@jit` программист просто помечает функцию, и Numba автоматически выводит типы переменных при первом запуске, создавая машинный код [2:02:06].

Хотя первые версии были «хрупкими» и поддерживали лишь малую часть языка, сегодня Numba позволяет достигать стократного и даже тысячекратного ускорения [1:48:05]. Особым достижением стал выпуск Numba Pro, который позволил компилировать код напрямую для графических процессоров (GPU) через CUDA уже в 2013 году [2:05:09]. Это открыло двери для масштабных вычислений в науке и бизнесе, за которые крупные компании были готовы платить.

### Дипломатия открытого кода: страны, которые пишут код вместе
[[JUMP:1:54:18]]

Помимо технических деталей, Трэвис Олифант (Travis Oliphant) делится глубоко личной философией о роли программирования в мировой политике. Обсуждая 20-летнюю годовщину событий 9/11, он размышляет о том, как триллионы долларов, потраченные на войны, могли бы преобразить систему образования или поддержку инструментов, на которых держится современный мир [1:54:02]. 

У Трэвиса есть мечта, основанная на старой поговорке о том, что торгующие друг с другом страны не воюют. Его версия звучит так: «Нации, которые пишут код вместе, не воюют друг с другом» [1:54:59]. Open source — это глобальное явление, не знающее границ. Трэвис вспоминает, как общался с учеными и программистами из Ирана и Пакистана, странами, с которыми у США сложные отношения на политическом уровне [1:55:37]. 

> «Это дает определенную степень гуманизации... Мемы, которые циркулируют в обществе, часто не отражают реальности того, кем являются люди на самом деле» [1:55:49].

Лекс Фридман (Lex Fridman) соглашается, отмечая, что в США, России и Китае живут невероятные разработчики [1:56:15]. Если политики продолжают спорить, то на уровне инфраструктуры человечества — кода, библиотек и общих инструментов — сотрудничество создает слой безопасности. Противостояние в будущем, скорее всего, перейдет в киберпространство, и именно совместная работа над открытым софтом может предотвратить «горячие» военные конфликты, делая страны слишком взаимосвязанными, чтобы разрушать общий фундамент [1:56:28].

### Преодоление академических и финансовых барьеров
[[JUMP:1:52:16]]

Трэвис с горечью отмечает, что на протяжении многих лет ему никогда не платили за работу над NumPy — он занимался им в свободное время, отрывая ресурсы от других проектов [1:53:01]. В университетской среде создание инструментов часто не считается «настоящей наукой», что мешает молодым исследователям вносить вклад в open source. 

Сейчас через Quansight Labs Трэвис пытается исправить эту историческую несправедливость, создавая финансовые механизмы для оплаты труда мейнтейнеров NumPy и SciPy [1:53:20]. Это не просто вопрос денег, а вопрос правильного распределения ресурсов человечества. Он уверен, что можно быть состоятельным человеком и при этом сохранять верность идеалам открытого сообщества [1:54:46]. Инвестиции в людей, создающих фундамент цифрового мира, приносят экспоненциально больше пользы, чем любые военные бюджеты.

## 📦 Anaconda и Conda: решение проблемы «упаковки» в научном софте
[[JUMP:2:05:35]]

К 2012 году Трэвис Олифант осознал, что создание мощных библиотек вроде NumPy и SciPy — это лишь половина дела. Огромной проблемой оставалась их доставка конечному пользователю. В те годы установка научного стека Python на Windows или Mac могла превратиться в многодневное приключение с компиляцией бинарных файлов и разрешением конфликтов зависимостей. Для решения этой задачи была основана компания, ныне известная всему миру как Anaconda.

### История основания: от Continuum Analytics до экосистемы Anaconda
[[JUMP:2:06:29]]

Изначально компания называлась Continuum Analytics [2:06:42]. Трэвис Олифант и его сооснователь Питер Ванг (Peter Wang) ставили перед собой амбициозные цели: масштабировать аналитику (что позже вылилось в проект Dask), подружить данные с вебом через интерактивную визуализацию (проект Bokeh) и, самое главное, упростить дистрибуцию софта [2:06:54]. 

Трэвис описывает свою бизнес-стратегию того времени как «стратегию штанги» (barbell strategy) [2:07:32]. С одной стороны, он брал деньги у «друзей, семьи и дураков» (friends, family and fools), что накладывало огромную моральную ответственность — он не мог позволить себе прогореть, как это часто делают венчурные стартапы [2:07:20]. Чтобы гарантировать выживание, компания занималась консалтингом. С другой стороны, эта прибыль инвестировалась в рискованные и инновационные open-source проекты, которые могли дать колоссальный рост в будущем.

В недрах Continuum Analytics родились или получили развитие важнейшие инструменты:

*   **Conda** — кроссплатформенный менеджер пакетов;
*   **Dask** — для параллельных вычислений;
*   **Bokeh** — для интерактивной визуализации в браузере [2:08:37];
*   **Numba** — (ранее в разговоре Трэвис упоминал её как JIT-компилятор для Python);
*   **JupyterLab** — эволюция интерфейса для исследователей [2:08:24].

Одновременно с коммерческой структурой Трэвис участвовал в создании некоммерческого фонда **NumFOCUS** [2:11:01]. Он считал критически важным разделить корпоративные интересы и управление сообществом, чтобы научный стек Python оставался общественным достоянием.

### «Идите и исправьте это сами»: рождение Conda
[[JUMP:2:12:32]]

Ключевым моментом в истории стал разговор Трэвиса с Гвидо ван Россумом на встрече в Googleplex в 2012 году [2:13:12]. Трэвис пытался донести до создателя Python, что текущая система упаковки (packaging) в языке сломана и мешает научному сообществу. Ответ Гвидо был лаконичным: «Идите и исправьте это сами» [2:13:25]. Гвидо, будучи разработчиком языка, смотрел на проблему иначе и не считал дистрибуцию библиотек первоочередной задачей ядра Python [2:11:39].

Мотивация Трэвиса была подкреплена горьким опытом: разработчики NumPy боялись вносить изменения в библиотеку, потому что пользователи умоляли: «Не меняйте ничего, я неделю настраивал свою среду, если я обновлюсь, всё сломается!» [2:14:04]. Инструментарий для установки буквально тормозил развитие науки. 

Так появилась Conda. Её фундаментальное отличие заключалось в том, что она проектировалась как:

1.  **Кроссплатформенное решение:** одинаковая работа на Windows, macOS и Linux [2:14:44].
2.  **Языковая независимость:** Conda умеет управлять не только Python-кодом, но и библиотеками на C, C++ и Fortran, от которых критически зависит SciPy [2:15:21].
3.  **Ориентация на пользователя:** в отличие от Pip, который долгое время был инструментом скорее для разработчиков, Conda создавалась для учёных, которым нужно просто набрать `conda install` и получить работающий инструмент [2:12:32].

### Conda против Pip: битва за бинарные зависимости
[[JUMP:2:14:44]]

Лекс Фридман замечает, что в интернете на один туториал по Conda приходится сотня инструкций через Pip [2:18:06]. Трэвис признаёт это доминирование, но объясняет, почему для сложных систем Pip до сих пор является компромиссом.

Главная проблема Pip — это работа с бинарными зависимостями за пределами мира Python. Когда вы устанавливаете библиотеку вроде TensorFlow или OpenCV через Pip, вы часто полагаетесь на «колеса» (wheels) — предварительно собранные бинарные файлы. Однако Pip плохо справляется с ситуациями, когда этим библиотекам нужны специфические версии системных библиотек C++ [2:17:27]. В Conda же реализована концепция «вариантов» (variants): пакет может иметь разные сборки под разные оптимизации процессора или версии компиляторов, и менеджер пакетов корректно разрешит эти связи [2:19:24].

Трэвис приводит в пример OpenCV [2:18:44] и TensorFlow [2:17:39], называя установку последнего через Pip «плохой идеей» для серьёзных задач, так как это часто приводит к созданию хрупких сред, которые невозможно обновить. Conda решает проблему бинарной совместимости на системном уровне, фактически выполняя роль зонтичного менеджера для разных языков программирования [2:15:08].

Несмотря на технологическое преимущество в научном сегменте, Conda столкнулась с вызовами:

*   **SEO и документация:** Огромный массив пользовательского контента в сети продвигает Pip как стандарт по умолчанию [2:18:06].
*   **Конкуренция с Docker:** Часть проблем, которые решала Conda (изоляция сред), современные разработчики стали закрывать контейнеризацией [2:22:12].
*   **Закрытость компании:** Трэвис признаёт, что Anaconda Inc. следовало раньше сделать Conda более открытой для вклада сообщества, чтобы она не воспринималась как чисто корпоративный продукт [2:20:16].

Сегодня Трэвис рекомендует «гибридный подход»: создавать базовую среду и устанавливать тяжелые инфраструктурные пакеты через Conda, а специфические мелкие библиотеки Python — поверх через Pip [2:22:51]. Его мечтой остаётся внедрение в Pip функции делегирования: чтобы Pip мог «понимать», когда он работает внутри среды Conda или системы Red Hat (RPM), и отдавать установку системных зависимостей им [2:24:07].

## 🛠 Quansite и новая архитектура корпоративного софта
[[JUMP:2:30:41]]

Многолетний опыт Трэвиса Олифанта в индустрии — от создания NumPy до руководства Anaconda — привёл его к пониманию фундаментальной проблемы: разрыва между потребностями корпораций и устойчивостью open source проектов. Решением стала концепция Quansite — сложной экосистемы, которая объединяет консалтинг, венчурный фонд и исследовательскую лабораторию. Ранее в разговоре Трэвис уже упоминал о поисках устойчивых экономических моделей, но именно в структуре Quansite эта идея обрела законченную форму [2:31:06].

### Венчурный капитал на службе мейнтейнеров
[[JUMP:2:30:41]]

Сердцем новой стратегии Олифанта стал венчурный фонд Quansite Initiate. По его мнению, каждый современный венчурный фонд должен иметь при себе исследовательскую лабораторию открытого исходного кода [2:30:54]. Модель работает следующим образом: часть прибыли фонда (carried interest) напрямую направляется на финансирование лаборатории, где мейнтейнеры могут спокойно работать над критически важными инструментами, не заботясь о поиске грантов.

Эта структура позволяет использовать «органическую силу формирования команд», характерную для сообщества разработчиков, и превращать её в жизнеспособный бизнес [2:31:06]. Quansite выступает как гибрид:

*   **Консалтинг:** решение конкретных задач бизнеса с использованием открытого стека.
*   **Лаборатория (Quansite Labs):** поддержка фундаментальных библиотек, от которых зависит вся индустрия.
*   **Фонд:** инвестиции в стартапы на ранних стадиях, которые вырастают из этой экосистемы [2:31:31].

Трэвис подчеркивает, что это не просто благотворительность, а «повторяемый паттерн». Наличие собственной open source лаборатории дает фонду уникальные связи с сообществом и возможность первыми видеть перспективные технологии [2:31:18].

### OpenTeams: маркетплейс для «будущего корпоративного софта»
[[JUMP:2:32:22]]

Развитием идей Quansite стала платформа OpenTeams. Работая с компаниями из списка Fortune 100, такими как JPMorgan, Shell и ExxonMobil, Трэвис заметил, что корпоративный сектор часто покупает проприетарные продукты, которые затем приходится «сшивать» воедино с помощью дорогостоящих консультантов [2:32:49]. 

OpenTeams позиционируется как «трансмиссионный слой» между огромными корпорациями и сообществами открытого кода [2:34:49]. Вместо того чтобы нанимать всех разработчиков в штат (модель, которую Трэвис считает не всегда эффективной), компания создает сеть партнеров. OpenTeams берет на себя юридические и бюрократические аспекты работы с крупными заказчиками (procurement), гарантирует качество и передает выполнение задач конкретным экспертам и мейнтейнерам [2:33:29].

«OpenTeams — это будущее корпоративного софта», — утверждает Олифант [2:36:05]. Цель проекта — заменить громоздкие закрытые системы (такие как SAS или MATLAB) на гибкие решения на базе открытого кода, которые предприятия смогут кастомизировать под себя, не попадая в зависимость от одного вендора [2:34:49].

### Почему маркетологи «не понимают» хакеров
[[JUMP:2:37:09]]

Обсуждая покупку GitHub корпорацией Microsoft, Трэвис отмечает, что это был блестящий ход, основанный на понимании важности разработчиков [2:37:21]. Однако он критикует то, как большинство крупных компаний пытаются взаимодействовать с техническим сообществом. 

Традиционный маркетинг в IT часто выглядит фальшиво. Олифант приводит в пример компанию iRobot: их роботы великолепны, но их реклама выглядит слишком «корпоративно» и стерильно [2:44:25]. Для привлечения лучших талантов (хакеров) нужна аутентичность. Вместо того чтобы показывать «красивых людей с роботами», компаниям стоит демонстрировать «магию инженерии» и реальных людей, которые создают продукт [2:45:04].

Трэвис предлагает радикально пересмотреть маркетинговые бюджеты:

1.  **Инвестиции вместо рекламы:** Вместо того чтобы тратить миллионы на Google Ads, компания (например, Ford) могла бы выделить 100 миллионов долларов на развитие NumPy и ключевых библиотек Python [2:39:54]. Это мгновенно сделало бы их «крутыми» в глазах топовых разработчиков, которых они так отчаянно пытаются нанять для создания беспилотных систем [2:39:28].
2.  **Эффективный ROI:** Поддержка open source приносит гораздо больший возврат инвестиций в долгосрочной перспективе, так как создает «гало-эффект» вокруг бренда работодателя [2:46:08].
3.  **Прямая поддержка:** Олифант напоминает, что в 2012 году он участвовал в создании NumFocus именно для того, чтобы компаниям было проще направлять пожертвования в экосистему [2:40:34].

По мнению Трэвиса, маркетологи часто боятся таких шагов, потому что они не укладываются в привычные схемы, усвоенные в бизнес-школах [2:43:07]. Но в мире, где софт «пожирает мир», умение говорить на языке инженеров и искренне поддерживать инструменты, которые они используют, становится главным конкурентным преимуществом.

## 🌟 Философия созидания: от найма талантов до жизненных принципов

[[JUMP:2:55:40]]

Завершая масштабную беседу о технологиях и бизнесе, Трэвис Олифант и Лекс Фридман перешли к вопросам, которые определяют не архитектуру кода, а архитектуру человеческих отношений и личной эффективности. Переход Олифанта от чистого программирования к руководству крупными компаниями и сообществами (ранее в разговоре они касались создания Anaconda и Quansite) сформировал у него уникальный взгляд на то, как работают современные команды и что на самом деле делает разработчика «великим».

### Многомерность таланта и найм через open source

[[JUMP:2:58:13]]

Трэвис Олифант признается, что даже после десятилетий в индустрии он считает найм одной из самых сложных задач. По его мнению, стандартное интервью длиной в один-два часа практически бесполезно для оценки реального потенциала [2:58:39]. Резюме — это лишь парадная витрина, которая часто скрывает истинное положение дел [2:58:53]. 

Лучший совет по найму, который Олифант дает руководителям: создайте open source проект, посмотрите, кто вносит в него вклад, и нанимайте этих людей [2:58:13]. Это позволяет увидеть программиста в деле до того, как будут подписаны какие-либо бумаги. Однако Трэвис предостерегает от упрощенного подхода к оценке сотрудников. Он утверждает, что измерение способностей человека по одной шкале («лучший» или «худший») в корне ошибочно, так как талант — это многомерное пространство, которое невозможно линейно упорядочить [2:59:19].

В процессе управления командами Олифант заметил любопытную дихотомию между участниками open source сообщества и создателями коммерческих продуктов [2:59:58]:

*   **Контрибьюторы открытого кода** обладают огромным энтузиазмом и специфическим «аффектом» участия, но им часто не хватает навыков доведения продукта до рыночной готовности.
*   **Продуктоориентированные разработчики** умеют создавать законченные решения, но часто стоят в стороне от сообществ, лишь с любопытством наблюдая за ними [3:00:23].

Ключ к успеху, по мнению Трэвиса, лежит в объединении этих двух энергий и добавлении сильного проектного менеджмента, которого так часто не хватает в свободном ПО [3:00:37].

### Смирение как фундамент обучения

[[JUMP:3:00:50]]

Главным качеством, которое Трэвис ищет в людях, является «способность учиться тому, как учиться» [3:00:50]. Он убежден, что если программист считает, будто он уже знает всё, его ждет стагнация. Первым шагом к истинному обучению Олифант называет смирение (humility) перед лицом того колоссального объема знаний, который нам еще не доступен [3:01:04].

Трэвис вспоминает свой путь к докторской степени (PhD), который он начинал из чистой любви к науке. Однако академический опыт привел его к классическому парадоксу: чем больше он узнавал, тем яснее понимал, насколько ничтожна доля его знаний в масштабах мироздания [3:01:30]. Этот опыт научил его важному правилу продуктивности: нужно гораздо больше слушать, чем говорить [3:01:43]. Олифант с иронией замечает, что его жена иногда критикует его за то, что сейчас он слишком полон идей и должен давать другим больше пространства для высказывания [3:01:54].

### Жизненные ориентиры: любовь, семья и созидание

[[JUMP:3:02:11]]

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

Во-первых, он выделил важность эмоционального якоря: «Найдите людей, которых вы любите, и заботьтесь о них. Семья имеет огромное значение» [3:02:36]. Под семьей он подразумевает тех, кому человек готов себя посвятить, так как именно эти обязательства дают необходимую жизненную опору [3:02:50].

Во-вторых, Олифант призвал молодежь к терпению и открытости:

*   **Правило десяти лет:** Не стоит думать, что в старших классах или колледже вы уже всё поняли о мире. Дайте себе минимум 10 лет на размышления и смену перспектив [3:03:03].
*   **Созидание вместо разрушения:** Трэвис подчеркнул, что гораздо продуктивнее строить что-то новое, чтобы заменить старое, чем тратить силы на атаки и критику существующих систем [3:03:54]. Если вам не нравится, как что-то работает (будь то денежная политика или программный стек), создайте альтернативу, которая привлечет людей своей эффективностью [3:04:08].
*   **Любопытство важнее денег:** Олифант призывает следовать за своим искренним интересом, а не за финансовой выгодой [3:04:20].

Беседа завершилась на высокой ноте признания вклада Трэвиса Олифанта в развитие человечества. Лекс Фридман назвал его одним из самых влиятельных людей в мире инженерии, чья работа объединила миллионы ученых [3:04:32]. Последним штрихом разговора стала шутливая отсылка к «закону Ходжсона»: любое достаточно продвинутое приложение на Lisp в конечном итоге будет переписано на Python [3:05:12].