Работа Андерса Хейлсберга сформировала то, как миллионы разработчиков пишут код. Даже если вы не узнаёте его имя, вы, скорее всего, сталкивались с его работами: он создатель 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 request'ы, компромиссы обсуждались публично, а приоритеты определялись с учётом отзывов сообщества.
Это сделало процесс принятия решений прозрачным. Разработчики могли видеть не только результат, но и причины выбора.
Эффективные open source проекты делают больше, чем просто публикуют код. Они делают видимым процесс принятия решений — чтобы участники понимали приоритеты и компромиссы.
5. Отказ от JavaScript как языка реализации был необходим
Долгое время TypeScript был самодостаточным: компилятор был написан на TypeScript и выполнялся как JavaScript. Это упрощало эксперименты и позволяло создавать мощные инструменты в браузере.
Но со временем ограничения стали очевидны: JavaScript однопоточен, не имеет общей памяти для параллелизма, а его объектная модель гибкая, но дорогая.
Команда достигла точки, где дальнейшая оптимизация уже не помогала. Нужна была другая модель выполнения.
Решением стал перенос компилятора на Go.
Это не было переписыванием с нуля. Целью было сохранить поведение полностью — включая особенности и крайние случаи. Rust, несмотря на популярность, потребовал бы серьёзного пересмотра архитектуры. Go же позволил сохранить поведение благодаря сборке мусора и структурной схожести.
Результат — значительный рост производительности за счёт нативного исполнения и параллелизма. При этом пользователям не пришлось переучиваться.
Иногда наиболее ответственное решение — не самое амбициозное, а то, которое сохраняет поведение, минимизирует изменения и устраняет фундаментальные ограничения.
6. В эпоху ИИ важнее опора, а не генерация
Хейлсберг скептически относится к идее «AI‑first» языков. Модели лучше всего работают с языками, на которых обучены — такими как JavaScript, Python и TypeScript.
Но ИИ меняет инструменты разработки.
Раньше IDE предполагала, что разработчик пишет код, а инструменты помогают. Теперь всё чаще ИИ генерирует код, а разработчик проверяет его.
В этом мире ценность инструментов — не в креативности, а в точности. Они должны предоставлять точную семантическую информацию, чтобы ИИ мог задавать правильные вопросы и получать надёжные ответы.
Риск не в том, что ИИ пишет плохой код, а в том, что он пишет правдоподобный, но недостаточно обоснованный код.
Для разработчиков это меняет фокус: важны не инструменты, генерирующие больше кода, а те, что правильно его ограничивают. Сильные системы типов, надёжный рефакторинг и точные модели становятся «ограждениями». Они обеспечивают структуру, которая позволяет эффективно анализировать, проверять и корректировать результаты ИИ, а не слепо доверять им.
7. Почему открытое сотрудничество критически важно
Несмотря на сложности финансирования и поддержки, Хейлсберг оптимистично смотрит на открытое сотрудничество. Одна из причин — институциональная память.
Годы обсуждений, решений и компромиссов остаются доступными и доступными для поиска.
«У нас есть 12 лет истории проекта. Если кто‑то помнит обсуждение, мы обычно можем его найти. Контекст не исчезает в почте или закрытых системах.»
Эта прозрачность влияет на развитие систем. Дискуссии, отклонённые идеи и компромиссы остаются доступными даже спустя годы. Для новых участников проекта этот контекст часто так же важен, как и сам код.
Выводы
Повторяющийся паттерн через десятилетия
За четыре десятилетия разработки языков одни и те же идеи повторяются:
Быстрая обратная связь важнее элегантности
Системы должны учитывать несовершенный код от множества людей
Совместимость поведения важнее архитектурной чистоты
Прозрачные компромиссы создают доверие
Это фундаментальные решения, которые определяют, сможет ли инструмент(ЯП) адаптироваться по мере роста его аудитории. Более того, они закрепляют инновации, гарантируя, что новые идеи смогут укорениться, не нарушая то, что уже работает. Именно они позволяют инновациям приживаться, не ломая уже работающие системы. Для тех, кто создаёт инструменты «на долгую дистанцию», эти основы так же важны, как и любые "прорывные" функции. И, возможно, это главный урок из всех.
readme
Если нашли ошибку, то используйте ctrl+enter или напишите в лс. Спасибо.
