Николай Чашников: еще больше об IntelliJ IDEA

JetBrains

Игорь Савчук, dev.by

Это окончание первой части нашего разговора с разработчиком IntelliJ IDEA, кандидатом физико-математических наук Николаем Чашниковым об интеллектуальной IDE — IntelliJ IDEA от компании JetBrains.

Сегодня мы поговорим о необычных случаях в части технической поддержки этого продукта, обсудим, чем плохи Java, Groovy и Scala, и почему компания JetBrains решила создать свой собственный язык Kotlin.

В первой части мы много хвалили IntelliJ IDEA, говорили о сильных сторонах этого известного продукта, но у любого технического решения есть какие-то свои слабые стороны. IntelliJ IDEA — это достаточно большая программа, и в такой большой системе неизбежно нарастает сложность, а значит, появляются ошибки. Можно выделить эти слабые места в IntelliJ IDEA с вашей точки зрения?

Разумеется, в IntelliJ IDEA есть множество ошибок, на данный момент в нашем bug tracker записаны более одиннадцати тысяч известных «багов». Но это всё частные ошибки в нашем коде, и мы их по мере сил исправляем. Принципиальная же слабость IntelliJ IDEA относительно Eclipse вызвана тем, что Eclipse является стандартной платформой. Компании, разрабатывающие языки или фреймворки, часто сами пишут для Eclipse плагины, добавляющие поддержку их технологий. Интеграцию же этих технологий с IntelliJ IDEA нам приходится писать самим. Но наши ресурсы ограничены, к примеру, в команде IntelliJ IDEA сейчас около 40 человек, и естественно, что мы не можем поддержать все существующие технологии самостоятельно. Стремление продвигать IntelliJ IDEA как платформу для сторонних разработок было одной из причин, по которой мы в 2009 году выделили часть IDE (Community Edition) в виде проекта с открытым исходным кодом. И сейчас некоторые производители технологий уже начинают писать плагины для IntelliJ IDEA сами, но, конечно, до Eclipse в этом отношении нам ещё очень далеко.

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

Есть ли какая-то специфика в написании «программистами программ для других программистов»? Наверное, программисты – это самая требовательная аудитория из всех пользователей любых программ? Может вспомните пару странных или веселых случаев за время вашей поддержки IntelliJ IDEA? Вашего самого необычного клиента?

Да, программисты, конечно, требовательные клиенты. Но, с другой стороны, они могут более качественно, чем другие пользователи, сформулировать свои претензии. У меня был случай, когда пользователь не только описал свою проблему, но и указал, в каком конкретно классе ошибка и в чём она состоит, и добавил, что в своей копии IntelliJ IDEA он её исправил. И это при том, что у него не было доступа к исходному коду!

Ещё была интересная история с некой Анной из США 73-х (!) лет. Она работала программистом ещё в 1960 году, а в 2011 году, после долгого перерыва, решила освоить Ruby, купила наш продукт и стала активно писать в техническую поддержку. Отвечать на её вопросы было непросто, многие вещи в современном программировании трудно объяснить человеку, привыкшему к перфокартам.

В первой части нашего интервью вы рассказывали, что «недостатки самого языка Java стали ограничивать наши возможности, а имеющиеся альтернативы — Groovy и Scala — нам не подошли, поэтому мы начали разрабатывать свой собственный язык программирования Kotlin». Можно немного пояснить нашим читателям, с чем эти недостатки и ограничения упомянутых языков связаны? Какие были проблемы в Java, что заставило появиться Groovy? И что в итоге было не так в них обоих настолько, что вы решили предпринять настолько затратный проект, как создание собственного языка программирования?

Нужно признать, что Java — очень многословный язык, в нём требуется писать много кода для реализации простых вещей. Обработка коллекций при помощи циклов, а не в функциональном стиле, необходимость писать getter и setter-методы для свойств класса и многое-многое другое — всё это отвлекает программиста от собственно решения стоящей перед ним задачи. И, хотя IntelliJ IDEA во многих случаях помогает избежать этой рутинной работы, генерируя какую-то часть кода автоматически, все равно эти проблемы лучше решать на уровне самого языка. 8-я версия Java улучшит эту ситуацию, но некоторые вещи, например, неудобство использования generic-типов, даже в будущих версиях Java вряд ли будут решены из-за необходимости поддерживать обратную совместимость.

Код на Groovy обычно короче кода на Java, и мы до сих пор используем Groovy в некоторых частях проекта, но стараемся постепенно от него избавиться. Дело в том, что в Groovy используется динамическая типизация. Это приводит к тому, что меньшее количество ошибок отлавливается на стадии компиляции, уменьшается скорость работы программы. Кроме того, для Groovy невозможно реализовать надёжную поддержку в IDE. К примеру, если в Java-коде вызывается метод, то можно определить, к какому классу этот метод принадлежит, в Groovy же это не всегда возможно.

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

Именно поэтому мы в итоге и решили создать свой язык — Kotlin — со статической типизацией, в котором нет многих проблем Java, но который не слишком перегружен возможностями, чтобы можно было написать для него быстрый компилятор и хорошую поддержку в IDE. Это не столь уж затратный проект: при текущих масштабах компании мы можем позволить себе выделить команду из 10 человек для работы над языком Kotlin, надеясь, что в перспективе этот язык облегчит труд остальных разработчиков.

И, разумеется, создание своего языка не означает, что мы прекратим развивать поддержку Groovy и Scala в нашей IDE.

Я знаю, что Kotlin имеет множество различных синтаксических сладостей, что позволяет делать довольно интересные вещи. Можно рассказать обо всём этом? Что нового важного есть в недавнем его релизе M5? На каких условиях распространяется код Kotlin?

Чтобы рассказать сразу обо всём, потребуется отдельная большая статья. Я уже описал причины, толкнувшие нас на создание своего языка, и цели, которые мы при этом преследуем. Исходный код компилятора и плагина для IntelliJ IDEA доступен под лицензией Apache 2. Подробнее про язык можно прочитать на его сайте и там же можно даже попробовать писать на Kotlin программы прямо в браузере.Для затравки приведу пример функции на Kotlin, которая берёт из переданных ей строчек те, которые начинаются с буквы «A», приводит их к верхнему регистру и печатает в консоль:


fun printNames (names : List) {
names filter {it.startsWith("A")} map {it.toUpperCase()} forEach {print(it)}
}


В качестве проверки зрелости и серьёзности этой технологии, разрешите сразу поинтересоваться, в каких собственных проектах вы уже используете Kotlin (принцип dogfooding)?

Наше расширение для браузера Google Chrome, используемое для связи с IntelliJ IDEA, написано на Kotlin и скомпилировано в JavaScript. В ближайшие месяцы мы планируем начать писать на Kotlin тесты в проекте IntelliJ IDEA, а потом и код самого продукта.

Хорошо, давайте немного сменим тему. JetBrains успешная и инновационная продуктовая компания, Вы только что сказали, что динамично растёте и расширяетесь, интересно было бы узнать, как вы ищете кадры? Какая у вас система найма, какие специфические требования? Какая, по вашей оценке, вообще сейчас ситуация с кадрами на российском рынке?

К нам на работу попадают разными способами. Кто-то откликается на наши вакансии на HeadHunter, кто-то приходит по рекомендации уже работающих у нас знакомых, кого-то мы находим сами. У нас тесные связи с Академическим университетом и с математико-механическим факультетом СПбГУ, многие пришли к нам на работу, будучи ещё студентами. Я сам, например, начал работать в JetBrains после второго курса. Максим Шафиров, который руководил тогда проектом IntelliJ IDEA, а сейчас является одним из директоров компании, преподавал практику программирования у моих однокурсников, от них я и услышал в первый раз о JetBrains.

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

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

У меня есть личный вопрос – когда много работаешь над одним и тем же продуктом, это не надоедает? Как развиваться, как бороться с монотонностью повседневного программирования?

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

Традиционный заключительный вопрос: какие планы на будущее, что «вкусного» собираетесь сделать в новой IntelliJ IDEA, чем порадовать и удивить своих поклонников? Кстати, предстоит 13-й релиз, в связи с этим, ваши программисты не суеверны?

Про конкретные планы на 13-ю версию говорить пока рано, работа над ней ещё не началась. В ближайшее время мы собираемся выпустить версию 12.1, которая по большей части посвящена исправлению ошибок. Из новой функциональности можно выделить улучшенную поддержку для JavaFX 2. Подробнее почитать про изменения и скачать предварительные версии можно в нашем блоге.Число 13 нас не беспокоит, наоборот, связанные с ним ассоциации можно будет обыграть, чтобы сделать интересный splash screen – картинку, показываемую во время старта IDE.

Впервые опубликовано на портале dev.by.