D:\sideБлогIDE против текстовых редакторов; или не против?

⚠️ Обращайте внимание на даты.
Этот блог больше не ведётся с 17 января 2023, и на тот момент с написания этой страницы (25.05.2014) прошло 8 лет.

По большей части, здесь пойдёт речь об инструментах разработки. Каждому программисту необходим инструмент, в котором он может печатать программный код. И он заинтересован в том, чтобы это можно было делать быстрее. Чем он в этом случае воспользуется?

В конце концов, код это всего лишь текст, да? Не совсем. Это текст, у которого есть довольно сложная структура. Что эту структуру обычно выделяет? Средство сборки: транслятор, компилятор, интерпретатор. Но эти средства, как правило, можно дёргать из командной строки уже после написания кода. Нужно ли это редактору? Отображение структуры кода прямо в редактируемом файле? Да, определённо не лишняя черта — человек несовершенен, ему нужна помощь.

Мы не будем рассматривать этап, на котором человек ещё даже программировать не умеет. Потому что в этом случае он с хорошей вероятностью столкнётся не с текстовым кодом, или же редактор/IDE за него выберет кто-то другой.

Поэтому человек, когда берётся за язык, ищет то, что потребует от него наименьшего количества действий. Установил, запустил, создал проект, уже можно компилировать. Отлично! Разумеется, здесь речь идёт об IDE, интегрированных средах разработки. Как правило, они заточены под быстрое решение типичных задач на конкретных технологиях, причём получении при этом более-менее качественного кода. Вы сразу получите настроенную систему сборки вашего проекта. Далее фичи разнятся: какие-то IDE’шки умеют подсвечивать ошибки без компиляции (анализируют код своими алгоритмами), обеспечивают подсказки (вы поставили точку после объекта, среда покажет возможные варианты), помогает в форматировании (вы нажимаете Enter, среда сразу ставит такой же отступ, как на предыдущей строке). Красота, да? В них обычно есть хороший отладчик, тесно вшитый в среду, с набором горячих клавиш. Особо суровые IDE’шки могут продолжать работу программы с отредактированным после её запуска (!) кодом, чтобы внесённые изменения вступили в силу. Круто! Хотя иногда программу это ломает :) Для гарантии таким лучше не пользоваться.

К сожалению, такой набор фич есть не у всего и не для всего. У лидирующих IDE для C++, C# и Java это есть. И этим пользуются. И это считают обязательным, и имеют на то полное право. В конце концов, это удобно, это ускоряет работу, увеличивает производительность.

Есть ли недостатки у всех IDE, как разновидности ПО? Сложный вопрос. А сложный он потому, что грань, с которой начинаются IDE, не такая уж чёткая. У “сферической IDE в вакууме” есть следующие неприятности:

  1. Катастрофически много кнопок (многие пользователи поначалу теряются).
  2. Система сборки слишком твердолобая (прячется за тонной настроек — чтобы собрать что-нибудь нестандартное, придётся хорошо развлечься).
  3. Требует большого экрана (на ноутбуке во многих IDE работать непросто, хотя это постепенно исправляется).
  4. Упомянутая в п. 2 килотонна настроек, среди которых найти необходимые бывает непросто (на самом деле, это следствие их количества).

Справедливости ради стоит перечислить и достоинства:

  1. Много настроек (палка о двух концах, да).
  2. Хорошо развитое автодополнение и подсветка синтаксиса.
  3. Помогает очень быстро без предварительной подготовки выполнять типичные задачи на выбранном языке.
  4. Много весьма мощных плагинов и инструментов для изменений кода.

Зайдём с другой стороны. Второй по популярности инструмент для написания программного кода — текстовый редактор. Казалось бы — примитивная вещь! …скажете вы, вспомнив какой-нибудь Блокнот, но всё не так уж просто. Даже gedit, Notepad++ и Light Table (хоть именно его называют IDE, многие им пользуются просто для редактирования) — редакторы весьма суровые.

Вы слышали о Vim? Большой редактор с большой историей. Пощупать браузерный порт Vim можно здесь. Почему текст не пишется? Это связано с историей текстового редактора. Звучит, как безумие и абсурд, текстовый редактор не редактирует код, WTF? Да нет, всё в порядке, просто не так, как вы привыкли.

Vim создан в то время, когда у раскладок клавиатур далеко не всегда встречались отличия от печатных машинок. Поэтому он довольно сильно рассчитывает на буквы в управлении. Для ввода текста необходимо подать на то команду (да-да!), и таких команд много. Простейшая: i, вставить на место курсора, как мы привыкли в остальных известных нам редакторах, вроде блокнота. Нажимаете i, вводите текст, нажимаете Escape и вы снова в режиме приёма команд. Даже вместо стрелочек использовались клавиши H, J, K и L! Жуть какая!.. казалось бы. Пользователи Vim уверены, что так удобнее, потому что не нужно тянуться куда-то пальцами. Стрелочки, как правило, не находятся в одном блоке с буквами/цифрами, а размещены где-нибудь у уголка этого блока, обычно правого нижнего. Поэтому клавиши (весьма часто используемые) помещены к центру клавиатуры и смещены так, чтобы на них можно было удобно положить 4 пальца одной руки.

Что делает Vim действительно мощным — это набор команд. Он хорошо использует текстовую природу обрабатываемой информации: там много команд для изменения/замены/удаления/вставки отдельных слов, символов, строк. Можно с лёгкостью менять местами слова и строки и вообще чувствовать себя королём текста, но… всему этому необходимо научиться. Начинающие пользователи Vim часто “идут на штурм”, включают его и пытаются разобраться в происходящем прямо на ходу. Обычно всё кончается провалом, хотя в последних версиях хотя бы сразу написано, как из него выйти. Когда-то не было даже этого.

Ах да, выйти из Vim: :q!Enter. Без сохранения, естественно, мало ли что вы в нём успели открыть за это время :)

Многие считают Vim средой разработки. Надо сказать, заслуженно, но есть один нюанс: непосредственно “из коробки” он всё же только текстовый редактор. А уж IDE из него можно изготовить собственноручно при помощи сотен доступных плагинов. На чём бы вы ни разрабатывали — скорее всего, кто-то уже делал это в Vim и сделал плагин для облегчения своей деятельности. Дла написания плагинов есть целый язык VimL. После изучения ассортимента и установки интересующих частей в Vim вы получаете IDE, собранную собственноручно. Подсветка синтаксиса в Vim есть изначально, автодополнение можно установить (в haxe оно, к примеру, прямо в компиляторе, нужен лишь интерфейс), систему сборки можно написать самостоятельно или подключить уже известную (частый кандидат: GNU Make), а на экране кроме непосредственно кода обычно ничего нет, ничто не отвлекает глаз. Кнопочек для мыши тоже нет, всё на горячих клавишах. Это, впрочем, сомнительное преимущество… но эту идею развили другие.

Всё губит сложность освоения. Раньше альтернатив Vi (предку Vim) толком не было, и это не было важно. Сейчас же многие всерьёз считают нужным работать лишь с тем, что легко освоить. Постепенно этот порог (“лёгкости”) поднимается, но в случае с Vim над этим нужно немало поработать. Поэтому хоть это и очень популярный среди разработчиков редактор, многие начинают искать что-нибудь попроще. И что-нибудь не для Unix-подобных — реализация GVim на Windows меня опечалила своей работой с кодировками.

Не так давно (меньше года назад!) вышел Light Table. Изначально он разрабатывался как “IDE нового поколения” для ClojureScript с возможностью редактировать код и мгновенно видеть его эффект. Тесная взаимосвязь с REPL (исполнение кода по ходу написания) и хорошо реализованная модульность даёт ему шансы свою концепцию оправдать. Но пока это не сильно развитый узкоспециализированный редактор. Тем не менее, редактор хороший.

Чем он интересен? У него тот же “лёгкий” интерфейс, что мы видим в Vim, ислючений всего парочка: строка меню и сворачиваемые панельки слева, справа и снизу. А, и вкладки. Настроек тоже много, но здесь всё аналогично Vim. Ах да, я ж не рассказал об этом. Всё просто — конфигурационный файл, в котором описываются все настройки. vimrc какой-нибудь. Но здесь есть ряд деталей, делающих его куда более дружелюбным для пользователя и разгруженным по части кнопок. Я упомяну всего одну, самую важную из них: нечёткий поиск по командам.

Конечно, Light Table не был первым, кто это представил, но из опенсорсных “дружелюбных” редакторов это единственный, в котором я это видел. Что у него осталось от Vim, так это подход к настройкам. Оказалось, у такого подхода хватает преимуществ! Собрав для конфигураций какой-нибудь несложный язык, можно сделать их крайне гибкими без ухищрений в интерфейсе. На разовую настройку можно потратить немного времени. Ну, наверное.

Чем ещё хорош Light Table? Подходом к плагинам. Здесь прямо в среду встроен менеджер, который можно открыть, пролистать доступные плагины, рядом с понравившимися ткнуть “установить”, и после этого большинство плагинов уже начнёт работу. Все распространённые плагины можно там найти. Но это не их идея, что интересно. Это слегка упрощённая штука, которую все пользователи Linux знают, как “менеджер пакетов”. О них я расскажу позже, но их суть в том, что они позволяют установить программу по её названию: менеджер сам находит источник среди известных ему официальных, сам скачивает программу, сам устанавливает, сам размещает ярлыки где надо.

В чём у всего этого проблема? Это всё нужно настраивать. Подход с конфигурационными файлами действует и в LT, и потому, что он удобен. Хотя не для всех. Интересно то, что аудитории: фанаты конфиг-файлов и адепты текстовых редакторов — сильно пересекаются. Почему такое происходит?

Это происходит, когда большинство функций, предоставляемых IDE, теряет надобность. Тогда человек начинает искать, как облегчить среду разработки. Убирает панель за панелью и часто обнаруживает, что до каких-то нужных ранее функций уже не дотянуться, а горячие клавиши нужно запоминать или настраивать самому, что часто оказывается сложно или даже невозможно. Этим страдают многие IDE’шки. В некоторых это лечится, но особо нетерпеливые личности плюют и начинают собирать себе IDE самостоятельно на базе текстового редактора.

Здесь я упомяну о Sublime Text, тоже весьма серьёзном редакторе, посерьёзнее Light Table (и постарше, в этом и дело). Единственный его серьёзный минус — он не бесплатен. Но заставлять платить вас никто не будет. И нет, речь не о пиратстве; неактивированная версия просто будет иногда надоедать сообщениями. Если действительно начнёт надоедать — значит, инструментом вы действительно пользуетесь, могли бы ради приличия и купить ключ. Во всяком случае, так думал при покупке я. Я изначально загрузил этот редактор только из-за того, что он хорошо поддерживает Haxe, и при этом является кросс-платформенным: где запустится компилятор Haxe, запустится и он.

Light Table, может показаться, многие вещи позаимствовал из Sublime Text. Но на практике и ST многие из них реализовал не впервые. Кто первым придумал поиск по всем в IDE командам, я не сумел отыскать. Но это просто великолепная идея, которая сильно разгружает интерфейс редактора и несколько меняет порядок освоения команд. Вы по умолчанию добавите в среду только то, что вам нужно. Другое вам будет добавлять просто лень.

Поиск. Чем он так крут? Вы нажимаете некое сочетание клавиш, пишете в поле, чего вы хотите от среды, и среда вам выводит по мере набора запроса, какие команды наиболее на это похожи. Система довольно опечаткоустойчивая; во всяком случае, это традиционно реализуют “нечётким поиском”. Математически, ищутся все команды, в которых поисковый запрос является подпоследовательностью символов. Поэтому в поиске можете забывать пробелы и отдельные буквы, если не помните их или далеко тянуться. А если команду приходится использовать достаточно часто, можно выбрать горячую клавишу, найти в документации обозначение этой команды и добавить в конфигурационный файл запись о том, что вы хотите такое действие на такую клавишу. Но для этого нужно знать команды. А если не знаете? Можно поступить наоборот и почитать конфигурационный файл самого редактора — там полно интересных вещей.

Этот подход становится разумным, когда вы уже на все 100% понимаете, что делаете. А что не понимаете, знаете, где посмотреть. Он разумен, когда вам не требуются подсказки от IDE, хватит вывода от компилятора, если таковой вообще есть. Он разумен для веба, кстати, почти любого сорта, где понятие “сборка” размыто: это верно для моего блога, для Rails (а там ещё куча языков), для PHP. И он разумен для всего, для чего есть качественные плагины, делающие только то, что умеют делать хорошо. Unix-way: делай меньше, да лучше. Отдай брату то, что ему удаётся лучше, чем тебе.

Это сейчас выглядит “поучительно”, или около того, но на самом деле это тот ещё кошмар. Если я вам вдруг буду рассказывать о Rails, напомните мне, чтобы я рассказал о том, какие цепочки программ приходится строить для выполнения задачи из нескольких составляющих.

В общем, мораль: в IDE во главе всего система сборки и редакторы, специфичные для именно вашей среды; чтобы собиралось всё одной кнопкой. Текстовый редактор в них очень важное звено, но не главное. В редакторах же как раз наоборот; систему сборки вам ещё нужно будет заставить работать, зато редактирование кода доставит максимум удобств. Или даже больше. Потому что лично я, например, раз за разом нахожу всё новые мелочи, из-за которых проще жить.

Но тут я пишу в блог. Не слишком похоже на написание кода. Я ж не на чистом HTML пишу, мне ещё жить охота.

PS: я тут как-то совсем не упомянул о Notepad++. На мой вкус, неудобен, хотя я пользовался им действительно долго, подсветка синтаксиса решала многие проблемы. Потом стало не хватать мелочей, которые туда добавлять нужно, прилагая усилия. Мне же лень.