Работа Андерса Хейлсберга определила подход к программированию миллионов разработчиков. Независимо от того, знакомо ли вам его имя, вы, скорее всего, сталкивались с его наследием: он является создателем Turbo Pascal и Delphi, главным архитектором C# и разработчиком TypeScript.
Мы встретились с Хейлсбергом, чтобы поговорить о его блестящей карьере и о том, каково это — наблюдать, как его инновации выдерживают испытания реальным миром. В ходе длительной беседы Хейлсберг размышляет о том, как выглядит проектирование языков после того, как угасает первоначальный энтузиазм, когда появляются ограничения производительности, когда открытый исходный код становится неизбежным, и о том, как искусственный интеллект может повлиять на исходную функцию инструмента.
В результате вырисовывается набор шаблонов для создания систем, способных выдержать испытание масштабированием. Вот что мы узнали.
1. Быстрая обратная связь важнее почти всего остального
Ранний опыт Хейлсберга формировался в условиях жёстких ограничений. В эпоху машин с 64 КБ памяти не было места абстракциям, которые не оправдывали себя.
«Вы могли держать всё в голове», — вспоминает он.
Когда вы набирали код, вам хотелось сразу его запустить.
— Андерс Хейлсберг
Влияние Turbo Pascal было связано не столько с самим языком Pascal, сколько с сокращением цикла обратной связи: редактирование, компиляция, запуск, ошибка, повтор — без обращения к диску и ожидания инструментов. Такой цикл позволял разработчикам экономить время и внимание.
Та же идея возникает десятилетия спустя в TypeScript, хотя и в иной форме. Сам язык — лишь часть истории. Значительная часть ценности TypeScript заключается в его инструментарии: инкрементальной проверке, быстром получении частичных результатов и языковых службах, которые быстро реагируют даже на больших кодовых базах
Вывод здесь вполне практический и разработчики могут напрямую применять его при выборе инструментов - быстрая обратная связь меняет поведение. Когда ошибки проявляются быстро, разработчики чаще экспериментируют, увереннее проводят рефакторинг и находят проблемы ближе к моменту их возникновения. Когда же обратная связь медленная, команды компенсируют это соглашениями, обходными решениями и усложнёнными процессами.
Независимо от того, выбираете ли вы язык, фреймворк или внутренние инструменты, скорость обратной связи имеет значение. Инструменты, сокращающие дистанцию между написанием кода и пониманием его последствий, завоёвывают доверие. Те же, что добавляют задержку — даже если они мощные — часто отходят на второй план.
2. Масштабирование ПО означает отказ от личных предпочтений
Когда Хейлсберг перешёл от индивидуальной работы к руководству командами (особенно во времена Delphi), самым сложным оказалось не техническое изменение, а необходимость отказаться от личных предпочтений.
«Нужно принять, что вещи делаются не так, как вы бы предпочли. Исправление этого всё равно не изменит поведение.»
— Андерс Хейлсберг
Этот подход применим далеко за пределами разработки языков. Любая система, которая должна масштабироваться между командами, требует перехода от личных предпочтений к общим. Цель перестаёт быть «кодом, который вы бы написали», и становится «кодом, который многие могут понять, поддерживать и развивать».
C# появился не как идеальная концепция «с чистого листа», а как результат противоречивых требований. Разработчикам Visual Basic была нужна простота, разработчикам C++ — мощность, а Windows требовала прагматизма. В результате получилась не теоретически идеальная система, а язык, которым люди могут эффективно пользоваться.
Языки программирования становятся успешными не потому, что они идеально спроектированы, а потому что они учитывают реальные способы работы команд.
3. Почему TypeScript расширил JavaScript, а не заменил его
TypeScript появился потому, что JavaScript добился успеха в масштабе, который немногие языки могут достичь. Поскольку браузеры стали настоящей кроссплатформенной средой выполнения, команды начали разрабатывать приложения, значительно превышающие уровень поддержки динамической типизации.
Первые попытки справиться с этой задачей часто были довольно радикальными. Некоторые команды компилировали другие языки в JavaScript просто для того, чтобы получить доступ к инструментам статического анализа и рефакторинга.
Этот подход никогда не устраивал Хейлсберга.
Сказать разработчикам покинуть экосистему, в которую они уже погружены, было нереалистично. Создание совершенно нового языка в 2012 году потребовало бы не только компилятора, но и многолетних инвестиций в редакторы, отладчики, инструменты рефакторинга и принятие сообществом.
Вместо этого TypeScript выбрал другой путь — расширил JavaScript, унаследовав его недостатки, одновременно упрощая разработку на крупномасштабных проектах.
Это решение не было идеологическим, а было практическим. TypeScript добился успеха, потому что работал в рамках ограничений, с которыми уже сталкивались разработчики, а не заставлял их отказываться от существующих инструментов, библиотек и ментальных моделей.
В итоге, главный урок заключается в стремлении к компромиссу. Усовершенствования, которые учитывают существующие рабочие процессы, имеют тенденцию распространяться, в то время как улучшения, требующие полной замены, редко находят поддержку. На практике значительный прогресс часто достигается за счет повышения возможностей систем, от которых вы уже зависите, вместо попыток начать с чистого листа.
4. Видимость — ключ к успеху open source
TypeScript не сразу стал популярным. Первые релизы формально были с открытым исходным кодом, но разработка по‑прежнему велась в основном за закрытыми дверями.
Ситуация изменилась в 2014 году, когда проект перешёл на GitHub и процесс разработки стал открытым. Предложения по функциям поступали через pull requests, компромиссы обсуждались открыто, а приоритеты задач определялись на основе отзывов сообщества.
Этот сдвиг сделал процесс принятия решений прозрачным. Разработчики могли видеть не только то, что было выпущено, но и почему были приняты те или иные решения, а другие — нет. Для команды это также изменило подход к приоритезации работы. Вместо того чтобы гадать, что важнее всего, они могли напрямую смотреть на проблемы, которые волновали разработчиков.
Эффективные open source проекты делают больше, чем просто публикуют код. Они делают видимым процесс принятия решений — чтобы участники понимали приоритеты и компромиссы.
5. Отказ от JavaScript как языка реализации был необходим
В течение многих лет TypeScript был самодостаточным. Компилятор был написан на TypeScript и работал как JavaScript. Это обеспечивало мощные инструменты для работы в браузере и упрощало эксперименты.
Однако со временем стали очевидны ограничения. JavaScript является однопоточным, не имеет параллельного выполнения с разделяемой памятью, его объектная модель гибкая, но ресурсоемкая. По мере роста проектов на TypeScript компилятор оставлял большую часть доступных вычислительных ресурсов неиспользованными.
Команда достигла точки, когда дальнейшей оптимизации было недостаточно. Им потребовалась другая модель выполнения.
Спорным решением стало портирование компилятора на Go.
Это не было переписыванием. Целью была семантическая точность. Новый компилятор должен был вести себя точно так же, как старый, включая особенности и граничные случаи. Rust, несмотря на свою популярность, потребовал бы значительной переработки из-за ограничений владения и повсеместного использования циклических структур данных. Сборка мусора Go и структурное сходство позволили сохранить поведение, одновременно повысив производительность и параллельность.
В результате значительно повысилась производительность, как при нативном выполнении, так и при параллельном. Что еще важнее, сообществу не пришлось заново изучать поведение компилятора.
Иногда наиболее ответственный выбор — это не самый амбициозный, а тот, который сохраняет поведение, минимизирует сбои и снимает жесткое ограничение, которое невозможно преодолеть никакими постепенными оптимизациями.
6. В эпоху ИИ важнее опора, а не генерация
Хейлберг скептически относится к идее языков программирования, ориентированных в первую очередь на ИИ. Модели лучше всего справляются с языками, с которыми они уже широко сталкивались, что, естественно, благоприятствует таким массовым экосистемам, как JavaScript, Python и TypeScript.
Однако ИИ действительно меняет ситуацию, когда речь заходит об инструментах.
Традиционная модель IDE предполагала, что разработчик пишет код и использует инструменты для помощи в процессе работы. Все чаще эта взаимосвязь меняется на противоположную. Системы ИИ генерируют код. Разработчики контролируют и исправляют. Детерминированные инструменты, такие как тайпчекеры и механизмы рефакторинга, служат защитными барьерами, предотвращающими незаметные ошибки. Ценность таких инструментов заключается в точности и ограничениях, они должны предоставлять точную семантическую информацию, чтобы системы ИИ могли задавать осмысленные вопросы и получать надежные ответы.
Риск заключается не в том, что системы ИИ будут генерировать плохой код, а в том, что они будут генерировать правдоподобный, но не учитывающий всех нюансов кодовой базы проекта.
Для разработчиков это меняет направление внимания. В итоге самыми ценными инструментами в рабочем процессе с поддержкой ИИ являются те, которые правильно его ограничивают. Сильные системы типов, надежные инструменты рефакторинга и точные семантические модели становятся незаменимыми ограничителями. Они обеспечивают структуру, которая позволяет эффективно проверять, валидировать и исправлять результаты работы системам ИИ, а не слепо доверять им.
7. Почему открытое сотрудничество критически важно
Несмотря на проблемы с финансированием и обслуживанием, Хейлсберг сохраняет оптимизм в отношении открытого сотрудничества. Одна из причин — институциональная память. Многолетние дискуссии, решения и компромиссы остаются доступными для поиска и просмотра.
Эта история не теряется в частных цепочках писем или внутренних системах. Она остается доступной для всех, кто хочет понять, как и почему развивалась система.
Несмотря на проблемы с финансированием и обслуживанием, Хейлсберг сохраняет оптимизм в отношении открытого сотрудничества. И одна из главных причин — институциональная память.
«В нашем проекте зафиксировано 12 лет истории, — объясняет он. — Если кто-то помнит, что обсуждение имело место, мы обычно можем его найти. Контекст не исчезает в электронной почте или частных системах».
Эта доступность меняет то, как развиваются системы. Дискуссии по поводу дизайна, отвергнутые идеи и компромиссы остаются доступными еще долго после того, как отдельные решения приняты. Для разработчиков, присоединяющихся к проекту позже, этот общий контекст часто имеет такое же значение, как и сам код.
Выводы
Модель, повторяющаяся на протяжении десятилетий
За четыре десятилетия разработки языков программирования постоянно возникают одни и те же темы:
Быстрая обратная связь важнее элегантности
Системы должны учитывать неидеальный код, написанный многими людьми
Совместимость по поведению часто важнее архитектурной чистоты
Видимые компромиссы укрепляют доверие
Это не второстепенные вопросы. Это фундаментальные решения, которые определяют, сможет ли инструмент адаптироваться по мере роста его аудитории. Более того, они служат основой для инноваций, обеспечивая возможность внедрения новых идей без нарушения того, что уже работает.
Для тех, кто создает инструменты, которым они хотят видеть долговечность, эти основополагающие принципы важны не меньше, чем любые революционные функции. И это, возможно, самый важный урок из всех.
readme
Если нашли ошибку, то используйте ctrl+enter или напишите в лс. Спасибо.
