Пять лет на Kotlin

Пять лет назад мир языков программирования пополнился языком Kotlin для платформ JVM, Android и JavaScript, сочетающим элементы объектно-ориентированной и функциональной парадигм. Андрей Бреслав, руководитель команды Kotlin в компании JetBrains, рассказывает о текущей версии и планах будущего развития языка, символически названного в честь острова, на котором размещается город Кронштадт, а также о современных тенденциях в области программирования.

Зачем сегодня нужны новые языки и что произошло за пять лет с момента первого объявления Kotlin?

Представление о том, как лучше всего писать программы, постоянно меняется, в частности, потому что меняются сами программы и внешние требования к ним: возникают новые задачи, новые устройства, новые технологии разработки. Число программистов и программных продуктов растет, и важно повышать продуктивность разработчиков, поэтому развиваются все средства разработки: от систем контроля версий до языков программирования. Однако сами языки развиваются относительно медленно, поскольку добавление новых возможностей в «старый» язык — технически очень сложная задача. Очень трудно сделать так, чтобы ничего не испортить: однажды выпущенная в релиз версия языка должна поддерживаться многие годы, иначе код, написанный пользователями, внезапно перестанет работать. Иногда оказывается, что проще разработать полностью новый язык и учесть в нем сразу комплекс идей, чем менять или добавлять что-то в старый. Так и случилось с Kotlin — в 2010 году мы в компании JetBrains поняли, что для увеличения продуктивности нам не хватает современного языка программирования, причем было ясно, что те же проблемы испытывают и другие разработчики.

Основными требованиями к новому языку были следующие. Статическая типизация: мы предпочитаем раннее обнаружение ошибок, к тому же для статически типизированных языков возможна качественная инструментальная поддержка — автодополнение, навигация, дополнительные проверки, рефакторинги и т. д. В динамически типизированных языках такие функции не могут работать надежно. Для многих ситуаций очень важна совместимость: вряд ли кто-то готов переписать огромный проект полностью на новом языке — мы не готовы точно, поэтому необходимо было поддержать смешанные проекты, чтобы можно было постепенно добавлять код на новом языке к коду на Java. И наконец, важным «философским» требованием к языку является демократичность: мы считаем, что все разработчики должны иметь доступ ко всем возможностям языка. Хотелось избежать ситуации, возникающей в слишком мощных языках вроде C++ и Scala, когда заметную часть возможностей в «обычных» проектах использовать не рекомендуется.

За пять лет с момента объявления о Kotlin в мире языков программирования произошло многое. Если в 2010 году единственным нашим «конкурентом» был язык Scala, то теперь появился Ceylon, в Groovy 2.0 добавили статическую типизацию, а в Java 8 появились лямбда-выражения. Но, несмотря на это, Kotlin остается единственным языком на платформе Java, который удовлетворяет всем перечисленным требованиям.

В своих выступлениях вы часто сравниваете Kotlin с Java и Scala...

Задачей Kotlin было сделать следующий шаг вперед по сравнению с Java: мы повышаем уровень абстракции, чтобы получить более лаконичные программы, которые легче читать и поддерживать. Расширяются возможности повторного использования кода: многие вещи в Kotlin можно выразить в виде библиотек, а в Java нельзя (большой вклад здесь вносят, например, делегированные свойства). Кроме того, система типов Kotlin позволяет обнаруживать больше ошибок еще на стадии компиляции — например, «ошибки на миллион долларов», то есть разыменования нулевых ссылок (NullPointerException).

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

Исходный код Kotlin был открыт в феврале 2012 года. Зачем?

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

Что можно сказать о признании языка мировым сообществом?

Мы выпустили первую официальную версию только в феврале 2016 года, но тем не менее немало промышленных проектов уже используют Kotlin. Среди компаний, которые так или иначе применяют язык в своих разработках, можно назвать Google (часть компилятора Android DataBindings), Expedia (мобильное приложение), Square (SQLDelight compiler), Prezi (использование на сервере). В 2016 году около 40 тыс. программистов использовали Kotiln, а количество кода на нем в открытых репозиториях GitHub удваивается каждые несколько месяцев и уже перевалило за 2 млн строк. Ну и в самой JetBrains, конечно, интенсивно используют Kotlin как для новых продуктов, так и для развития старых, например IntelliJ IDEA.

Какие тенденции наблюдаются сегодня в мире языков программирования?

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

Что сегодня требуется от разработчика ПО?

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

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

Сегодня модно призывать к созданию национальных операционных систем, СУБД и так далее...

Мне такая постановка вопроса кажется некоторой подменой ценностей. Современные ОС и СУБД зачастую распространяются с открытым кодом и не создаются в какой-то стране — они разрабатываются во всем мире. Выпускать надо не «национальные», а востребованные и качественные программы. Если что-то разработано в России или на Мадагаскаре — оно от этого не становится лучше или хуже. Мне кажется, для программных продуктов важнее не географические характеристики. Другое дело, что надо вкладывать ресурсы в национальную индустрию разработки программного обеспечения, но нет смысла предписывать ей, какие именно продукты делать. Если кто-то сможет сделать ОС нового поколения, которая покорит мир, это прекрасно, но она покорит мир не тем, что она российская.