Читать книгу Код. Культура, скомпилированная в байты - - Страница 12

Когда программист объявляет переменную, он делает утверждение о мире. «Эта переменная – целое число» – это не просто техническая аннотация. Это обещание. Это контракт. Это способ сказать компилятору, машине и другим программистам: вот что здесь будет лежать, вот как с этим можно обращаться, вот чего от этого можно ждать.

Языки программирования радикально расходятся в том, когда и как требовать это обещание. И за этим расхождением – глубокие философские различия.

Статически типизированные языки требуют обещаний заранее. Программа не скомпилируется, пока типы не согласованы. Компилятор проверяет контракты до того, как хотя бы строчка кода будет выполнена. Это Си, Java, Go, Rust, Haskell – языки, которые верят, что ошибки нужно ловить как можно раньше. Чем раньше найдена ошибка, тем дешевле её исправить. Ошибка на этапе компиляции стоит минуты. Ошибка в продакшене стоит часы, дни, репутацию.

Динамически типизированные языки откладывают проверку. Тип переменной определяется в момент выполнения, по значению, которое она содержит. Это Python, Ruby, JavaScript, Perl, Lisp – языки, которые верят в гибкость, в способность программиста понимать свой код. Зачем заставлять программиста объяснять очевидное? Зачем писать int x = 5, когда и так понятно, что 5 – целое число?

За этим техническим различием – два разных мировоззрения. Два разных ответа на вопрос о природе программ и природе ошибок.

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

Динамическая типизация исходит из предположения, что мир изменчив, непредсказуем, не укладывается в заранее заданные схемы. Данные приходят в разных формах. Структуры эволюционируют. Жёсткие контракты сковывают. Программист лучше понимает свой код, чем любой статический анализатор. Гибкость важнее гарантий. Тесты важнее типов. Работающий код важнее формально корректного.

История типизации – это история поиска баланса между этими полюсами.

Робин Милнер, работая в Эдинбургском университете с 1973 года, искал золотую середину. Он разрабатывал ML – метаязык для системы доказательства теорем LCF. Ему нужен был язык, который был бы надёжен, как статически типизированные языки, но удобен, как динамические. Результатом стала система вывода типов, которая позже получила название Хиндли-Милнера (по имени Милнера и логика Роджера Хиндли, который независимо пришёл к похожим результатам).

Идея была элегантна: компилятор сам определяет типы выражений, анализируя, как они используются. Программисту не нужно писать аннотации – но программа всё равно статически типизирована. Если вы пишете функцию, которая складывает два аргумента, компилятор выведет, что аргументы должны быть числами. Если вы потом попробуете передать ей строку – ошибка компиляции. Но вам не пришлось объявлять типы явно.

Это был революционный компромисс. ML и его потомки – Haskell, OCaml, F# – предлагали статические гарантии без синтаксического бремени. Программист писал код почти как на динамическом языке, наслаждаясь лёгкостью и скоростью. Но компилятор выводил типы и проверял их согласованность, обеспечивая надёжность статической типизации. Лучшее из двух миров.

Современные языки всё чаще выбирают эту модель. Go выводит типы локальных переменных: достаточно написать x:= 5, и компилятор поймёт, что x – целое число. Kotlin делает то же самое, добавляя более мощную систему типов с null safety. Rust сочетает вывод типов с одной из самых строгих систем проверок в индустрии – его borrow checker отслеживает владение и время жизни значений, предотвращая целые классы ошибок памяти.

Swift, созданный Apple в 2014 году, тоже использует вывод типов. Как и Scala, сочетающая объектно-ориентированное и функциональное программирование. Вывод типов стал мейнстримом – не потому, что программисты ленивы, а потому, что он позволяет писать выразительный код без потери безопасности.

Но самое интересное развитие последних лет – постепенная типизация, gradual typing. Это подход, который признаёт: иногда нужна гибкость динамики, иногда – гарантии статики. Почему бы не иметь и то, и другое?

TypeScript добавляет типы к JavaScript, но делает их опциональными. Можно начать с полностью динамического кода – он будет работать. Потом постепенно добавлять аннотации: сначала для публичных API, потом для внутренних функций, потом везде. Строгость нарастает по мере готовности кодовой базы и команды. Это не компромисс – это путь миграции.

MyPy делает то же для Python. Sorbet – для Ruby. Hack, созданный Facebook1, добавил постепенную типизацию к PHP. Dart начинал с опциональных типов, хотя позже перешёл к обязательным. Постепенная типизация оказалась не академическим экспериментом, а практическим инструментом для огромных кодовых баз, которые нельзя переписать за один день.

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

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

Когда работаешь со статическим языком, начинаешь думать типами. Сначала проектируешь структуры данных, потом пишешь функции. Типы становятся документацией: сигнатура функции говорит, что она принимает и что возвращает. IDE использует типы для автодополнения, рефакторинга, навигации по коду. Рефакторинг становится безопасным – компилятор укажет на все места, которые нужно изменить. Типы становятся языком общения между частями системы и между членами команды.

Когда работаешь с динамическим языком, думаешь значениями. Что здесь лежит прямо сейчас? Как это преобразовать? Тесты заменяют статическую проверку. Duck typing – «если что-то ходит как утка и крякает как утка, это утка» – позволяет писать обобщённый код без формального описания интерфейсов. Не важно, какого типа объект. Важно, что он умеет делать. Это другой способ думать о программах – более гибкий, более ситуативный, более близкий к тому, как работает реальный мир.

Ни один подход не лучше другого. Они отвечают на разные вопросы, решают разные проблемы, подходят для разных ситуаций.

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

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

Важно понимать: выбор типизации в языке – это не техническое решение. Это философское решение о том, как должна выглядеть надёжная программа. Проверенная статически до запуска? Или протестированная динамически в процессе работы? Описанная типами заранее? Или раскрывающаяся в поведении?

Каждый ответ имеет свою логику. Каждый создаёт свою культуру программирования.