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

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

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

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

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

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

Влияние языка на мышление и концепция «исполняемого английского» 5:13

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

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

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

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

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

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

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

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

Массивы (Arrays): Библиотека numeric (предшественник NumPy), созданная Джимом Хагунином (Jim Hugunin) в 1995 году, заполнила этот пробел .
Комплексные числа: Для инженера-электрика отсутствие встроенных комплексных чисел — это катастрофа, так как они критически важны для преобразований Фурье (FFT) .
Broadcasting (трансляция): Возможность выполнять операции над целыми массивами без написания явных циклов .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Кроссплатформенное решение: одинаковая работа на Windows, macOS и Linux .
Языковая независимость: Conda умеет управлять не только Python-кодом, но и библиотеками на C, C++ и Fortran, от которых критически зависит SciPy .
Ориентация на пользователя: в отличие от Pip, который долгое время был инструментом скорее для разработчиков, Conda создавалась для учёных, которым нужно просто набрать conda install и получить работающий инструмент .

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

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

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

Трэвис приводит в пример OpenCV и TensorFlow , называя установку последнего через Pip «плохой идеей» для серьёзных задач, так как это часто приводит к созданию хрупких сред, которые невозможно обновить. Conda решает проблему бинарной совместимости на системном уровне, фактически выполняя роль зонтичного менеджера для разных языков программирования .

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Многомерность таланта и найм через open source 2:58:13

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

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

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

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

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

Смирение как фундамент обучения 3:00:50

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

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

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

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

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

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

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

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