#46: Nikitonsky про современные редакторы кода

[00:00] Никита: Чем дольше ты в этом варишься, тем ты становишься лучше — на самом деле всё немножко не так. Человек находит какой-то локальный максимум, который для него работает, и в нём застревает.

[00:15] Никита: Это просто мега-улучшение, лучше уже ничего не бывает. Вот лучшее, что вы можете сделать, — это перенести стрелочки на home row.

[00:21] Никита: Ты какой-то разработчик, у тебя есть свободное время, и ты такой: «сейчас сделаю зашибись-редактор». Нет никакой причины делать его внутри терминала — ты можешь пойти и сделать точно такой же быстрый редактор с нуля, но в графическом GUI.

[00:34] Никита: Код, который ты сделал в Vim, в Sublime или в таком «тупом» редакторе, — это именно ты полностью всё создал, это твоя программа. А работа в IntelliJ — это больше как тебя пустили посмотреть в этот сложный механизм: ты там что-то поковырял и ушёл, но ты не отвечаешь за это всё целиком. Это не твоё, тебе просто дали немножко поковыряться.

[00:58] Александр: Здорово! Меня зовут Саша Пахомов, и я инженер, который любит своё дело. Вы слушаете подкаст, в котором разработчик современной базы данных изучает, как они работают, и делится знаниями со слушателями. Но сегодняшний выпуск не совсем про базы данных. Или даже так: сегодняшний выпуск совсем не про базы данных. У меня в гостях создатель самого популярного шрифта среди программистов, Fira Code, — Никита Прокопов. Мы поговорим про редакторы кода и попробуем нащупать понимание того, каким вообще должен быть современный редактор. Выпуск полон инсайдов и увлекательных мыслей. Не хочу спойлерить, но один вброс сделаю: я — виммер, а любимый редактор кода Никиты — Sublime Text. Будет интересно. Поехали!

[02:06] Александр: Привет, Никит!

[02:07] Никита: Привет!

[02:07] Александр: Сегодня мы про редакторы кода и в целом про то, как мы работаем с компьютером как программисты — именно когда набираем код. Наверное, хотелось бы начать с базовой-базовой вещи, которая знакома абсолютно всем, даже если сейчас нас слушают не программисты, — они поймут, о чём речь. Это то, как мы сидим за компьютером и как взаимодействуем с клавиатурой, как они располагаются, что такое home row. Ты как программист с большим стажем — как ты позиционируешь себя перед компьютером?

[02:37] Никита: Я в какой-то момент немножко заморочился этой темой. Поначалу не особо: у меня начали болеть руки, я понял, что надо разбираться, разобрался. В итоге переехал на сплит-клавиатуру, и всё стало хорошо. Но в целом клавиатура — это очень интересный предмет дизайна, который держится на принципе good enough: она достаточно хороша, чтобы не было мотивации её менять, но не оптимальна. То есть локальный минимум, но не глобальный. Изначально клавиатуры делались для печатных машинок: от каждой клавиши вверх шёл штырь, поэтому каждый ряд кнопок смещён относительно другого на одну четверть. Это протянулось до наших дней — самый странный артефакт лет ста-полутораста, и мы до сих пор наблюдаем его прямо перед собой. Мораль такая: потенциально это можно изменить, но необходимости больше нет; сделать лучше можно, но всем и так норм, поэтому никто особо не заморачивается.

[03:36] Никита: Если захотеть сделать клавиатуру получше, можно сделать параллельные ряды, чтобы все кнопки стояли строго одна под другой, — потому что пальцы ходят вверх-вниз, и удобнее скользить вверх-вниз, а не со смещением. Боковое смещение ничему не помогает. Можно ещё немножко сместить колонки вертикально, по длине пальцев. А когда у тебя одна цельная клавиатура — на ноутбуке, например, — плечи широкие, клавиатура маленькая, и кисти изогнуты довольно неприятным образом, что как раз вызывает боли. Не у всех и не всегда, и пока ты молодой, ни у кого особо проблем нет, но со временем эффекты негативные. Соответственно, ты можешь сделать две половины клавиатуры, развести их на ширину плеч — и становится кайфово. Я так и сделал: сейчас практически всегда сижу на сплит-клавиатуре. Ну, основная рабочая — сплит, но иногда день-два на ноуте посидеть, ничего страшного.

[04:33] Никита: Home row — тоже интересное явление, и оптимизации на этом не заканчиваются. У тебя пять пальцев: большой — самый сильный и тяжёлый, четыре остальных послабее, мизинец самый слабый. А в дизайне клавиатуры почему-то на мизинец приходится очень много всего: пробел, Shift, Control, Option, Command — ты нажимаешь мизинцем, что не очень здорово. А под большой палец отдан только пробел — ну что за дела. Маки чуть лучше винды, потому что основной модификатор — Command, который рядом с пробелом, а не Control. Его можно нажимать большим пальцем: немножко руку изогнуть, но гораздо удобнее. Когда я перешёл на мак, прям почувствовал, что стало сильно лучше.

[05:04] Александр: Я тоже почувствовал, что стало сильно лучше, но не осознал, что это в том числе из-за большого пальца. Я такой: как-то удобнее, — но не понял, что реально начал задействовать большой палец.

[05:24] Никита: Поэтому на эргономичных клавиатурах — Kinesis Advantage, Moonlander, Ergodox — под большой палец отдано пять-шесть кнопок: всякие энтеры, пробелы, модификаторы, потому что он может. И очень странно, что под него столько места. Кстати, из всей этой истории я до сих пор не очень понимаю, почему пробел такой большой. Это ведь не самая частая клавиша даже в тексте — процентов десять-двадцать в лучшем случае.

[05:56] Александр: Я когда учил слепую печать, там говорили, что на пробел нужно нажимать обоими большими пальцами — в зависимости от того, какая рука нажала последней: если правая, то левый большой палец на пробел, если левая — то правый. И чтобы он дотягивался до обоих больших пальцев, я думаю, его просто сделали одной длинной кнопкой.

[06:14] Никита: Ну, это тебя учат исходя из того, что клавиатура такая, какая есть. А если подходить с точки зрения «как сделать клавиатуру лучше» — пробел не обязан быть большим. Он может быть маленьким, как буква C. Или их может быть два, как шифтов, — хотя не уверен, что в двух есть смысл. Короче, вот эта загадка для меня. Надо загуглить, почему пробел до сих пор такой большой.

[06:39] Никита: Home row — интересная концепция, ей тоже учат в слепой печати. Это средний ряд букв: ASDF для левой руки и JKL; для правой. Место, из которого меньше всего тянуться до остальных клавиш: ставишь руку, держишь её там всё время, это базовое положение, и небольшим оффсетом двигаешься туда-сюда. По буквам всё отлично, до цифр немножко дальше тянуться. Поэтому существуют маленькие клавиатуры, 40–60%, в которых нет цифрового ряда: ты зажимаешь дополнительный модификатор, которого сейчас на клавиатурах нет, типа Raise или Lower, и на тех же кнопках, где сейчас буквы, набираешь цифры — просто чтобы не тянуть пальцы.

[07:31] Никита: И главная засада home row и традиционных клавиатур — что мизинец очень много работает, когда нужно уйти направо, и стрелочки. Стрелочки — вообще беда стандартных клавиатур. Вот большая клавиатура на 104 клавиши: основной текстовый блок, потом справа посередине блок со стрелочками и Home/Insert/Page Up/Page Down, а ещё правее — нампад. Ты сидишь исключительно в левой части, а мышка справа от всей этой махины. Каждый раз, когда нужно потрогать мышку, ты тащишь руку через два дополнительных блока очень далеко. Поэтому все эргономисты, которые заморачиваются клавиатурами, любят и текстовые интерфейсы, где всем управляешь с клавиатуры: тянуться за мышкой — отдельное действие, которое и по времени, и по усилиям заметно складывается.

[08:49] Никита: Стрелочки в таком формате находятся справа от основного блока — тебе нужно снимать руку с home row, никак до них не дотянешься, и гонять руку туда-сюда. А стрелочки нужны довольно часто. Если сильно не заморачиваться, ты этого не замечаешь, но если попробовать поработать и так, и по-другому, поймёшь: да, ты тратил довольно много времени, и это бессмысленная трата.

[09:23] Александр: Логично. И из физических следствий кажется, что нужно вынести стрелочки в основную секцию, в home row или рядом.

[09:31] Никита: Собственно, на этом заработал свою популярность Vim. Четыре стрелочки — это H, J, K, L, они в ряд: влево, вниз, вверх, вправо. В командном режиме ты нажимаешь просто эти буквы, даже без модификаторов, и бегаешь по тексту. Очень удобно. Мне кажется, это основной хук Vim, на который все подсаживаются: думаешь — о, как удобно, вот бы можно было так же. У меня, например, кастомная клавиатура с дополнительными модификаторами, которые меняют слои, и есть слой, который делает стрелочки на EJKL — в виде перевёрнутой буквы T, как на обычных клавиатурных блоках. Если на ноуте работаю, нажимаю Caps Lock — и эти четыре кнопки работают как стрелки. Кайф, что рука не уходит с home row вообще. Это просто мега-улучшение, лучше уже ничего не бывает.

[10:43] Никита: Я сделал это системным модификатором, то есть это не Vim-овская штука — оно работает во всех приложениях одинаково: к компьютеру буквально идут сигналы, что я нажал стрелочку. Этим я и заморачиваюсь. Но если заморачиваться неохота — Vim чисто для редактирования текста, стрелочки там будут.

[11:03] Александр: Ты про Vim уже начал говорить, это больше софтверная часть, а я бы хотел ещё покрутиться вокруг хардверной, потому что ты затрагиваешь много интересного. Честно говоря, перед записью я не знал, что ты пользователь сплит-клавиатуры, — для меня это приятное удивление, потому что я тоже с недавних пор на сплите. Хочу завершить эту тему, чтобы точно не осталось вопросов. Ты задал интересный вопрос: почему пробел до сих пор такой длинный, почему смещены ряды. Q и A не ровно друг под другом, а по диагонали — но пальцы-то у нас растут не так. Значит, это не эргономичное расположение, а чисто историческое, из-за штырьков от печатных машинок. Это логично. А нелогично мне вот что: почему до сих пор так? Неужели это просто good enough, все привыкли — и только в этом причина? Ведь огромную популярность набирают профессии, где очень много работают за клавиатурой: программист, дизайнер. И казалось бы, большие производители — Apple какой-нибудь — когда выпускает MacBook Pro, где Pro значит «для профессионалов», должны продумать эргономику. Но нет, этого не происходит. Есть у тебя мысли, как к этому относятся большие производители?

[12:41] Никита: Слушай, у меня такой же вопрос. Действительно не очень понятно, но, видимо, исторические причины и инерция. Кажется, что good enough. Я долго ломал голову, почему тот же Apple, условно, никогда не уберёт Caps Lock. Это самая странная клавиша, которая никому и нафиг не нужна, а её упорно пихают, — и народ благодарен, потому что на неё можно повесить другую: виммеры вешают Escape, маководы что-то ещё. Полезная кнопка в итоге. Но почему сразу так не сделать? Видимо, инерция. Помнишь, Apple в какой-то момент на ноутах сделал блок стрелочек в виде перевёрнутой T, но в половинчатую высоту, потому что места нет: влево-вправо — полноразмерные, а вверх-вниз — одна кнопка, поделённая пополам. Народ попробовал, и они вернули всё назад. Сейчас все четыре кнопки половинчатые. Много загадок на клавиатуре. Правый Shift и вообще правые модификаторы мне тоже непонятны, я ими не пользуюсь. Вот функциональные клавиши на макбуке полноразмерные — зачем? Можно в два раза меньше.

[13:59] Александр: Была же попытка убрать их — Touch Bar.

[14:02] Никита: Ну, Touch Bar вообще странная штука. Его проблема в том, что кнопки перестают быть стабильными, перестают быть на своих местах: тебе нужно на это смотреть, а это убивает саму идею кнопок. Печальная была история. Но, видимо, инерция. Кстати, макбуки же выпускают с разными раскладками — ты при покупке выбираешь целый новый клавиатурный блок с по-другому расположенными кнопками, всякие европейские клавиатуры. Так почему не сделать ortho-linear раскладку как опцию и не продавать её? Фиг знает.

[14:38] Александр: Я бы точно себе купил ortho-linear и немножко развёрнутый, как сплит, положенный сверху.

[14:44] Никита: Тут надо смотреть: на макбуке не так много места, чтобы развернуться.

[14:53] Александр: Место — согласен. Знаешь, попытки же были, ты сейчас со стрелочками привёл: производители что-то меняют, смотрят на реакцию, и реакция говорит не менять. И вот вопрос про реакцию людей. Я иногда за собой замечаю странную штуку: когда показываю свою клавиатуру программистам, друзьям — на меня смотрят немножко странно, мол, ты чего на сплите сидишь? Меня удивляет, что люди не осознают ценность, удобство, эргономику вещей, за которыми проводят по 8–12 часов в день. Говоришь: смотри, это же удобно, — а они: это же надо учить, я лучше на ноуте сгорбленный посижу. Мне непонятно, почему абсолютное большинство даже с отторжением относится к идее сплита. Ты такого не замечал?

[15:47] Никита: Ну да. Я как-то смотрел доклад одной тётки — не помню, чей, — и она сказала прикольную вещь. Человек учится какому-то навыку и делает это очень долго: месяц, год, десять лет. Мы все думаем, что чем дольше он работает, тем лучше он работает. На самом деле это немножко не так. Человек находит какой-то локальный максимум, который для него работает, и в нём застревает. Дальше он автоматически не улучшается: если не предпримешь специальный шаг, чтобы пересилить себя, будешь продолжать делать, как делал. Ты находишь способ, который работает, — скорее всего, неоптимальный, потому что нашёл его рано и не делал research, какие способы вообще возможны, — но он для тебя good enough, чтобы делать основную работу, и ты продолжаешь. Это везде наблюдается, в том числе с клавиатурами. Например, если ты в IDE не поставил себе задачу выучить шорткаты, то, скорее всего, и через десять лет ими не пользуешься — потому что никогда не потратил день, чтобы их выучить. Работает формирование привычки. Наши предки ходили охотиться, нашли какой-то путь через лес к водопою — и всегда будут по нему ходить, хотя, может, можно было короче. То есть это специальный навык: нужно сознательно организовать активность, улучшить что-то в мастерстве, иначе будешь продолжать делать неоптимально. Поэтому я, например, очень люблю смотреть, как работают другие: сразу — о, можно было так, а тут можно посоветовать. Садишься рядом с человеком, смотришь — и открываешь для себя кучу неочевидных штук.

[17:34] Александр: Про «смотреть, как работает» — интересный момент, я тоже за собой замечаю. И ещё как будто программирование и всё, что нас окружает — клавиатуры, мышки, — это что-то личное: ты сам выбираешь, за чем работать. Нет стандарта в индустрии, какие клавиатуры должны быть у программиста, — иначе ты не получишь аккредитацию. А вот у МЧСников, пожарных, какие бы они ни были разгильдяи, всё равно будет форма — одна из лучших, которые сейчас используются, просто потому что индустрия пришла: тёмный цвет со светоотражающими полосками виден при задымлении, поэтому все её носят. Пожарный не может прийти в домашнем халате, а программист может. И интересно, почему в некоторых профессиях есть способ делать работу качественно, который использует абсолютное большинство, а в программировании такого нет. Единственное, что могу предположить, — просто довольно молодая профессия. Есть мысли?

[18:36] Никита: Конкретных мыслей нет — наверное, потому что от этого действительно ничего не зависит: на каком редакторе ты придёшь писать, не особо влияет на результат. А почему у них так — именно потому, что есть люди, которые специально занимаются оптимизацией: смотрят, какие формы лучше работают и почему, и у них есть способ навязать это всем остальным. Если бы участники были предоставлены сами себе, они приходили бы в халатах и в кроссовках — я стопроцентно уверен. Постепенно, через общение друг с другом, научились бы носить непрогораемые сапоги, потому что нога в первый раз сгорит, — но разброд был бы гораздо больше. Это иллюстрация того, что улучшение само по себе не случается: адаптационный период есть, и сам он не пройдётся, это должно быть сознательное усилие. Людям просто неохота или они не понимают, что это так работает.

[19:44] Александр: А с точки зрения большой компании? У меня тысячи сотрудников. Неужели я как компания не могу сделать примерно такое же исследование, как в МЧС и медицине? Ну, реально: посадить тысячу программистов на сплиты, тысячу — за обычные компьютеры, и два года наблюдать, как меняется income, который они генерируют.

[20:22] Никита: Наверное, можно. А ты веришь, что это действительно улучшит качество работы?

[20:26] Александр: Это как раз тот вопрос, к которому я хотел подвести. В это даже я не верю. И это, мне кажется, ещё одна из основных причин, почему люди скептически ко всему этому относятся: нет чёткого понимания, что через два года после перехода на сплит ты начнёшь зарабатывать больше. Нет же такого. Тебе какие-то красноглазики вроде меня, которые сидят ночью за компом, говорят: сплит — это классно, — а ты думаешь: ну, ребята, поехали, я пойду за компом посижу. То есть реальных исследований нет, и в плане ощущений очевидно, что круто, а в плане результата работы — вопрос. Есть у тебя на личном опыте моменты, когда ты как профессионал именно для людей снаружи начал решать эффективнее, быстрее, — или это всё про внутренние ощущения?

[21:16] Никита: Это на самом деле больше про здоровье. У меня начали болеть кисти, я развёл клавиатуры и избавился от изгиба — мне это помогло. Кому-то надо ещё больше заморочиться: наклонять поверхность клавиатуры относительно стола, чтобы был правильный разворот. Мне плоского сплита достаточно, я на нём кайфую. Ты не так сильно тянешь пальцы, кисти не так изгибаются — но это долгосрочный бенефит, мерить надо на 10–20 лет. А во-вторых, компания не так сильно заморочена здоровьем сотрудников: не думаю, что кто-то будет париться, какие кисти будут у конкретного чувака через 20 лет. Плюс не все люди предрасположены к, как он называется…

[22:00] Александр: Туннельному?

[22:01] Никита: Да, туннельному синдрому. К нему тоже не все предрасположены, только какой-то процент, — то есть это ещё не на всех повлияет. Но в целом можно. Наверняка есть нормы: размер монитора, как далеко он стоит, какой высоты стул. Стулья же тоже никакие не покупают — какие-то офисные, «в кавычках», которые поддерживают спину. Всё делается по минимуму. Хотя в американских фильмах я часто вижу в офисах Herman Miller — не самый дешёвый стул, видимо, немножко всё-таки заморачиваются.

[22:35] Александр: Подытоживая тему с клавиатурами и эргономикой, расскажу свой короткий опыт. Я чуть больше полугода сижу на сплите и подмечаю изменения в своём флоу, в состоянии. Что могу сказать: концентрироваться и входить в состояние потока стало гораздо лучше — отвлекающих факторов стало меньше. Помимо того, что глаза не бегают (а раньше я, даже владея слепой печатью, подглядывал, когда открываешь-закрываешь скобочку или амперсанд), у тебя глаза и руки в комфортном положении. Просидев 8 часов за компьютером, я не чувствую боли в спине. Раньше, за обычной клавиатурой, плечи были спущены вниз, и усталость я чувствовал не только эмоционально и интеллектуально, но и физически — и эта усталость заставляла выйти из-за компьютера, прекратить концентрироваться, пойти погулять или полежать. Сейчас я из-за компьютера не выхожу от усталости, а выхожу, потому что понимаю: надо. Концентрация и состояние потока стопроцентно стали лучше. Стал ли я лучше писать код? Не могу сказать. Но точно стал намного комфортнее работать и меньше переживать: сложную задачу я могу сесть и решить в любой момент. А раньше мне нужно было выспаться, чтобы спина не болела, в зал сходить — и только когда меня ничто не отвлекает, я мог целый день программировать. Сейчас такой день — каждый. У тебя есть что-то подмеченное, какое-то эмоциональное состояние?

[24:17] Никита: Слушай, нет, но ты правильно нащупал, что это немножко персональная история: каждый по-разному предрасположен, кому-то просто нравится пробовать новое. Я, в принципе, не могу работать не на сплит-клавиатуре. Рад бы взять Apple Magic Keyboard, но просто не могу — пробовал возвращаться несколько раз, не получается. И поэтому я очень завидую людям, которые могут: мир механических клавиатур в основном сделан под стандартный лэйаут — предсобранные клавиатуры с классными капами, но все с длинными шифтами и пробелом. Если бы я мог, мне было бы доступно гораздо больше. А так приходится возвращаться. В моём случае это именно здоровье: если у вас туннельный синдром, скорее всего, нужно специально заморочиться — наклон, сплит, эргономика. Каждый сам для себя решает. У тебя вот психологические бенефиты, что тоже прикольно.

[25:13] Никита: Сплит — большой шаг, и клавиатура в целом большой шаг. Но как минимум каждый может попробовать перенести стрелочки на середину клавиатуры. У меня на tonsky.me есть статья, как перенести курсор на Mac, там, по-моему, и винда расписана. Ставишь Karabiner, ставишь профиль — и у тебя появляется Caps Lock + EJKL. Кардинально меняет жизнь. Я сделал это лет десять назад и с тех пор ни разу не оглядывался — единственное улучшение, которое настолько жёстко прижилось. Прям удивлён, что оно не всегда так было. Всем рекомендую попробовать.

[25:48] Александр: Супер-совет, полностью поддерживаю. У меня EJKL тоже на отдельном слое. С одной стороны, я подсмотрел эту идею вдохновения в Vim — попробовал, о, реально удобно, — и перемапил себе везде: на всех сайтах прокручиваю этими клавишами, в менюшках табаюсь. И оно во всём софте работает. Не надо, поработав в Vim и выйдя из него, спотыкаться — а тут стрелки другие. Они везде одинаковые, и в Vim в том числе. Так что плюсую всеми руками.

[26:32] Александр: Можем уже перейти к Vim — про эргономику мы хорошенько поговорили. Давай так начну. Я сейчас вкатился в Neovim и всю эту Vim-овскую движуху — примерно одновременно с тем, как начал взаимодействовать со сплитом. И в целом доволен. Я не адепт: думаю, что существуют разные способы программировать долго, — но мне сейчас персонально прям подходит этот. Про него я как-нибудь отдельный выпуск запишу, это долгая история, про Vim можно разговаривать бесконечно. У тебя есть чем поделиться: ты и программировал в Vim довольно долго, и потом переходил обратно. Расскажи своё отношение к Vim, к Neovim и почему ты перешёл обратно на другой редактор?

[27:20] Никита: На Vim я сидел где-то год. Это было довольно давно, лет пятнадцать назад. Я был в компании, где все сидели на Vim, — ну ладно, надо разобраться. А ещё мы работали по SSH: нужно было зассшиться и там работать, без вариантов. Я поставил Vim, научился, запомнил все эти команды, поднастраивал. Кстати, тогда Vim был не такой популярный, где-то на уровне Emacs. Сейчас, мне кажется, он сильно вырвался вперёд — я слышу мега-хайп-волну именно Vim, у него какое-то второе пришествие случилось, что довольно забавно. Короче, я посидел, знаю, о чём говорю, всё попробовал — было нормально. И до сих пор немножко этими навыками пользуюсь, когда нужно что-то подредактировать на сервере, — это Vim и мышечная память, руки всё помнят.

[28:11] Никита: Но в целом я с него ушёл, потому что мне не нравится идея режимности. Я одно время увлекался юзабилити, а в юзабилити есть утверждение, что модальность — это не очень хорошо. Модальность — это когда программа может находиться в нескольких режимах и в них работает по-разному. Самый простой пример — модальное окно: появляется окно, вся остальная программа перестаёт реагировать, кардинально меняется поведение, правила игры. А в Vim модальность ещё хуже, потому что она почти невидимая: где-нибудь сбоку, возможно, есть индикатор режима, но видеть его очень сложно. Ты используешь одни и те же кнопки в обоих режимах, но работают они кардинально по-разному: в одном набирают текст, в другом двигаются по тексту и производят операции. Считается, что это плохо, потому что нужно постоянно держать в памяти, в каком ты режиме. Это как ощущение, когда ты нажал Command-C и до того, как куда-то вставил, у тебя в пальцах чувство, что там что-то находится.

[29:33] Никита: Альтернатива модальности — квазимодальность: у тебя есть другой режим, но он работает только пока ты держишь кнопку. Большие буквы, когда зажимаешь Shift, — это квазимодальность. Она считается не такой плохой, потому что ты физически держишь кнопку, и очень сложно забыть, что ты в режиме.

[29:49] Александр: Я, в принципе, согласен. Мне идея режимов Vim тоже не очень нравилась, но к ней можно привыкнуть.

[29:53] Никита: Второй момент, который мне не нравится: редактирование текста в Vim кардинально отличается от всей остальной системы. Ничто не работает по тем же принципам, что Vim. Это белая ворона, чёрный лебедь — отдельная штука, которая играет только по своим правилам. Ты как программист сидишь 8 часов в этом Vim, потом переходишь в Chrome заполнить форму — а там ничего не работает, и такой: блин, да что ж такое. Я долго пытался настроить всю систему под те же правила, но понял, что смысла нет. И в итоге перешёл на Sublime, потому что он работает точно так же, как вся остальная система: все комбинации клавиш, обычное редактирование — всё одинаково. Мне не нужно переключать ментальные режимы «сейчас я в Vim / сейчас не в Vim».

[30:41] Никита: Второй момент — система команд Vim, которую все так любят и которая якобы кардинально повышает эффективность. Когда ты нажимаешь двоеточие или там w, delete — много «прыгни вправо на два, удали следующие три слова и закрой кавычку», набрал одной командой, запустил, оно выполнилось. Я тоже считаю, что это не очень актуально сейчас. Смотри: Vim изначально создавался под медленные терминалы. Тонкий клиент коннектился куда-то, как SSH сейчас, но интерактивности не было — ответ приходил настолько долго, что у тебя действительно было время подумать и набрать, что именно ты хочешь. Чем больше набрал, тем быстрее придёт ответ на все команды: фидбэк-лупа не было постоянно. В современных системах такой проблемы нет — ты сразу видишь, что сделал, задержки нет.

[31:39] Никита: Работа с Vim — это как работа по телефону: ты говоришь чуваку на том конце «перейди вперёд на две команды и удали три символа», он: хорошо. А ты не видишь, какие символы он удалил, какие выделил. А в редакторе это immediate feedback: нажал Shift, прыгнул вправо на три слова — и три слова сразу выделились. Мне кажется, это гораздо более человечный способ работать и с текстом, и вообще с любыми системами команд: ты видишь объект, над которым будешь производить действия. Вместо того чтобы писать «следующие три слова», а войдёт ли туда кавычка или нет — блин, не знаю. За год я так и не научился каким-то мега-командам Vim, которые работают настолько хорошо, что я не могу воспроизвести их в обычном редакторе. Прыгать на слова, вперёд-вниз на сколько-то строчек — мне проще нажать три раза вверх, чтобы выделить три строчки, чем думать, какую команду нажать и считать эти строчки. Я не знаю, как их считать: вижу, что мне нужно добежать до слова function, а сколько там строк — семь, десять, фиг знает. Мне проще нажать «вверх» и ждать, когда дойдёт. Короче, я считаю, что система команд не такая уж классная, у Vim совсем другие правила, он не интегрирован с остальной системой, — поэтому Vim пришлось отказать.

[33:04] Александр: Окей, спасибо большое. Думаю, некоторые слушатели уже подгорели и хотят тебе ответить, что ты не прав вот здесь, здесь и здесь. Как человек, думающий о росте аудитории, я бы сказал: пишите свои несогласия в комментарии. Но я отвечу за вас, ребята, — не то чтобы я на вашей стороне, но мне есть что дополнить. Никита, у тебя опыт взаимодействия пятнадцатилетней давности, а ты сам классно рассказывал, как любишь смотреть, как работают коллеги. Так вот, ты можешь буквально пять минут посмотреть — думаю, ты видел, как работает, например, блогер The Primeagen в Vim. Эта история «набрал команду и потом увидел результат» действительно хороша в контексте того времени, а сейчас Vim используют немножко по-другому. Или я по-другому его использую, потому что начинал программировать на редакторах в идее «what you see is what you get»: я люблю что-то выделить и с ним что-то сделать. И я просто в Visual Mode — есть такое в Vim — нажимаю v, двигаю куда надо, он выделяет кусок, а дальше я принимаю решение, что с ним делать: заменить или скопировать. То есть паттерн взаимодействия у меня не такой, какой в него закладывали деды, — гибридный. И этой проблемы вообще нет: я постоянно что-то выделю, посмотрю, подумаю, потом сделаю.

[34:26] Александр: А наборы команд в голове я вбиваю в единственном случае — когда нужно записать макрос. Условно, у меня тут тысяча строчек, каждая начинается с кавычки и заканчивается стрелочкой, мне нужно кавычку убрать, а стрелочку поменять на открывающую скобку. Вот это всё я действительно записываю в макрос в голове, воспроизвожу один раз, а дальше повторяю тысячу раз с цифрой. Это единственный use case, когда что-то приходится визуализировать. Во всём остальном это как будто мышечная память, я об этом вообще не думаю. По поводу модальности тоже скажу: у виммеров, которые сейчас программируют, у абсолютного большинства есть рефлекторная привычка постоянно нажимать Escape. Escape — просто клавиша, которая жмётся постоянно: нажав её из любого мода, ты всегда попадаешь в нормальный. И на рефлексах, если что-то хочешь, ты прям Escape — и пошёл.

[35:20] Никита: Абсолютно. Escape — и погнал. У меня Escape на сплите на двух больших пальцах: тык — и пошёл. Это просто как отбивка, только мышцы думают, голова об этом не думает.

[35:31] Никита: Про это, кстати, сайдноут — про неосознанное нажатие кнопок. У меня переключение языков стоит на правом Command и правом Option: правый Command включает английский, правый Option — русский, чтобы всегда перейти, куда нужно. Я так и живу. И вот ставлю виртуалку с линуксом на мак, нужно что-то потестить. Открываю линукс, что-то делаю — хоп, окно выскакивает, что за херня, закрыл. Продолжаю — хоп, снова. И потом я понял, что неосознанно жму кнопку переключения на английский, которая в F13 куда-то транслируется, и в линуксе нет этого шортката — он там что-то другое делал. Нифига себе: я постоянно на неё жму и сам не понимаю.

[35:57] Александр: Да-да. У меня с F13 тоже переключение языка подмаплено, и я постоянно его тыкаю. Перед тем как начинать печатать, у меня рефлекс: напечатал две буквы, тык-тык, понял, в каком я языке, стёр и начал печатать — чтобы не смотреть глазами в угол.

[36:29] Никита: Прикольно.

[36:35] Александр: Про Vim ещё, в плане того, что он чёрный лебедь либо белая ворона, отдельный вообще от всех систем. Это, наверное, один из самых сложно оспариваемых аргументов, потому что так и есть: способ ввода и навигации по тексту в Vim кардинально отличается от всех — если не брать терминал. В терминале Vim смотрится очень лаконично: там та же less-команда с такими же Vim-овскими проскроллами, ты там как рыба в воде. Но если убрать терминал и оставить редакторы кода, браузер, мессенджеры — наверное, три программы, в которых сидит большинство, — то, кроме редакторов кода, где можно поприседать и понастроить, в браузере и мессенджере надо прям сильно извращаться. В браузере плагины есть, я знаю, но себе не ставлю: в мессенджер плагин всё равно не поставлю, идеального Vim у меня везде не будет, поэтому пусть будет неидеальный. А в редакторах кода это, благо, уже решённая проблема: в большинстве популярных есть Vim-овские биндинги и моды, ставишь плагин — и живёшь, как в терминале.

[37:43] Александр: То есть программирование точно не задействовано. Если ты не программируешь в браузере, в каком-нибудь GitHub, где пишешь людям кучу сниппетов на ревью, там тоже будет проблема, а в остальном — небольшая для меня лично. Как оказалось, переключиться с Vim на обычный текст несложно, потому что у меня стрелочки замаплены на те же штуки, что и в Vim: в терминале я стрелочками прыгаю, кнопки те же, просто чуть медленнее, — и в целом комфортно. Так что немножко я сбалансировал твой спич про то, что Vim устарел: для некоторых людей, которые близки ко мне тем, что могут изучать новое и адаптироваться, сейчас это в большинстве случаев ок.

[38:25] Никита: Нет, Vim сейчас на хайпе, потому что куча блогеров начинает на нём писать, и прикольно смотреть, как чувак программирует в Vim. Это моё личное мнение, почему он на хайпе. Ну и не Vim, конечно, а Neovim — плагины и вот это всё. Куча интересных плагинов пишется в комьюнити, и это движется вперёд сильно быстрее, чем тяжёлая, неповоротливая Xcode или даже IDE. Neovim — это Lua: плагины на Lua, для обратной совместимости поддерживается Vim Script, и большая часть переписана на Lua. Я так понимаю, они в какой-то момент форкнули Vim и начали фигачить на Lua вокруг.

[39:04] Никита: В целом плагины, то, как это выглядит и работает, — очень прикольно. Прям глоток свежего воздуха в day-to-day разработку, когда есть какая-то движуха. Я, например, на Java пишу, а в Java-мире движухи вообще нет: комьюнити мёртвое, все деды. Обновил идею? Нет, у меня трёхлетней давности. Блин, надо обновить. Ой, Lombok отвалился. Вот всё, что происходит в комьюнити Java. А тут ты берёшь себе, IDE-клон собрал, плагины настроил — а тут отскочило, а там раз, надо обновить. Реально просто веселье. Стримеры, блогеры это всё делают, прикольно наблюдать, и ты заражаешься.

[39:50] Никита: На самом деле, мне тоже интересно, почему Vim и почему сейчас. Я нашёл сервей Stack Overflow: Neovim — 20%, а Vim — ещё 12%, вместе 33%. Emacs в жопе — 4%. Я рос во времена, когда они шли примерно вровень, а сейчас Vim вырвался сильно вперёд. Sublime Text, кстати, 10% — в два раза популярнее Emacs. Очень интересно.

[40:14] Александр: Я очень согласен насчёт движухи. Думаю, во многом людям в кайф возможность настроить всё это под себя. Звучит так, что Vim — это новое пришествие Emacs: когда-то все делали себе свой редактор на основе Emacs, а сейчас это происходит с Vim. Он даёт возможность самовыразиться, легко модифицировать себя, сделать красиво. Вся эта теория мне очень нравится. Но мне непонятно, почему с VS Code такого не произошло. Это именно контркультура: VS Code самый популярный, а мы хотим что-то менее популярное, но с большим комьюнити.

[40:54] Никита: А ты работал в VS Code?

[40:56] Александр: Я использовал его чуть-чуть, что-то подредактировать, профессионально в нём не писал.

[41:01] Никита: Я работал, посидел порядка года-двух, когда он был ещё молодой и фич было мало. Основная причина, почему я сбежал, — фич стало очень много. Меня раздражает, как там всякие свистелки-перделки, каждый месяц апдейты, нужно всё отключать. Он стал слишком большим, поэтому я перешёл обратно на Sublime.

[41:31] Александр: Обычно люди, которые пишут на JavaScript, фронтендеры, очень яро используют VS Code. По крайней мере, так было, когда я начинал писать на Java семь лет назад: у нас в IntelliJ IDEA единственный вариант, а однокурсники рядом сидели в VS Code — смотри, тут можно что-то быстро запускать. Я попробовал: что значит быстро запускать? Но семь лет назад IntelliJ IDEA действительно долго запускалась, особенно если у тебя не было SSD, а VS Code был быстрее. Я его запускаю, он открылся — такой: чего? Это же геймченджер. Потом идея тоже начала открываться сносно, появились нормальные SSD, проблему перестаёшь замечать. Но тогда VS Code на этом хайп собрал нормально. Плюс он расширяемый, можно писать плагины — я, правда, ни одного не писал, но комьюнити должно его драйвить, и оно там довольно большое. Почему оно не такое живое, как в Neovim сейчас?

[42:32] Никита: Мне кажется, просто потому, что Neovim — это open source. Комьюнити никем… ну, VS Code — это же Microsoft. И, возможно, потому что терминал: мне кажется, некоторые используют Neovim именно потому, что он работает в терминале. Это точно отличает его от VS Code и всего остального.

[42:53] Александр: Но как будто бы идея программировать в терминале в 2024 году кажется как минимум странной, когда у нас есть видеокарты, игры в 4K и 8K, — а мы тут в терминале печатаем на MacBook Pro. Что ты думаешь про разработку в терминале с помощью чисто текстового интерфейса?

[43:13] Никита: Мне тоже кажется, что это очень странно. Я частично поэтому и ушёл с Vim — он был в терминале, и мне это казалось странным, потому что терминал живёт немножко по своим правилам. Кнопки не те, ничего нельзя сделать, он не дружит с операционной системой. Ты не можешь нормально скопировать и вставить текст. Когда я работал в Vim — может, сейчас по-другому, — при вставке он посылает в терминал команды набора этого текста: не вставляет одним куском, а печатает побуквенно. Ты скопировал 300 килобайт и ждёшь, пока это всё «просрётся». Копирование тоже хреново интегрировано: выделил текст в Vim, скопировал — а он у тебя есть только в Vim, в Chrome не вставишь. И какие-то кнопки не работают — Page Up, Page Down наверняка криво. Мне это не нравится, и кажется странным: ты идёшь через супер-престарую технологию, которой 50 лет, и зачем-то пытаешься из неё что-то сделать.

[44:17] Никита: Вот второй момент. Окей, терминал удобен, чтобы ходить на удалённые сервера, прекрасно. Но ты берёшь его и пытаешься сделать из него графическую IDE — с панельками, с иконками, со всякой фигнёй. Ты хочешь графику, хочешь всё это нарисовать, но зачем-то мучаешь себя примитивными, неподходящими для этого средствами. У меня есть шрифт Fira Code, и мне периодически пишут: я пытаюсь набрать статус-бар в Vim, а у меня зазоры, что-то плохо выровнено. Я такой: ну конечно, потому что это шрифт. Нормальную графику на шрифте никогда не сделаешь — он будет рендериться как получилось, углы где-нибудь не сойдутся, что-нибудь всё время не так. По конструкции невозможно сделать правильно. Это движение мне непонятно: зачем страдать. Вроде сейчас на сервера по SSH никто ногами не ходит, все деплоят через докеры или ещё что-то, разработка идёт локально, — вся эта движуха мне непонятна. Кроме, опять же, контркультуры и того, что, может, удобнее сделать интерфейс приятным, когда есть только ограниченное количество выразительных средств — сетка из букв.

[45:29] Александр: На всю эту тему у меня гипотеза: люди ассоциируют с терминалом две вещи, которые на самом деле никак напрямую не следуют из терминальности. Это скорость — что терминальные приложения якобы быстрее обычных, — и клавиатурная ориентированность. Но скорость мне непонятна. Да, Vim быстрее, чем IntelliJ, и даже, наверное, чем современный VS Code. Но это ниоткуда не следует.

[45:52] Никита: Ты можешь технически написать такой же графический редактор, который будет работать с той же скоростью, что Vim. Просто так получилось, что его писали давно, он рассчитан на старый компьютер и поэтому сейчас работает быстрее. Но это не свойство, присущее терминалу по какой-то причине. Если ты какой-то разработчик, у тебя есть свободное время, и ты такой: сейчас сделаю зашибись-редактор, — нет никакой причины делать его внутри терминала. Ты можешь сделать точно такой же быстрый редактор с нуля, но в графическом GUI.

[46:20] Никита: С кнопками та же штука. Почему Vim хорошо работает с клавиатурными шорткатами? Потому что мышка хреново поддерживается, тебя вынуждают хорошо работать с клавиатурными комбинациями — ты обязан сделать так, чтобы всё делалось кнопками. Цель благородная, но теоретически ты можешь делать то же самое в графической программе. Просто там нет этого вынуждения, поэтому иногда подзабивают: в каком-нибудь VS Code размер панельки не подвигаешь с клавиатуры, потому что на мышку же есть. Но теоретически ничто не мешает: если задаёшься целью сделать быстрый редактор с хорошим клавиатурным управлением, всё это можно сделать в GUI не хуже, чем в терминале. По факту, да, Vim сейчас лучше это поддерживает, но это очень странное следствие ограничений, которые больше нерелевантны.

[47:07] Александр: Так, я тут два пальца загнул, чтобы не забыть. Первый разгибаю — это про то, что скорость в терминале никак не связана со скоростью приложения. Стопроцентно согласен. Если понимаешь, как работают программы, странно утверждать обратное: тебе всё равно текст надо парсить, поиск по тексту делать. То, что ты графически отображаешь пиксели вместо текста, на современных компьютерах не стоит ничего, если делать правильно. Что такое «быстро», когда мы говорим про редакторы? Когда нажимаешь кнопку, начинаешь печатать и сразу видишь текст — обратная связь быстрее, 120 FPS. Или скорость — это когда открываешь файл в Vim, и он тут же открылся, а не запускается идея с при-скриптом, потом чёрный экран, и на нём потихоньку начинает отображаться файл. Скорость — совокупное ощущение, и в плане открытия файликов тут, конечно, Vim: он в той же среде запускается, рендерит сильно меньше и вообще меньше кода исполняет. Потом мы будем говорить про современные легковесные редакторы — там проблемы скорости нет.

[48:07] Александр: И второй палец отгибаю — про то, что нет смысла заставлять себя работать в терминале, когда у нас есть мышка, нормальные GUI-приложения, компьютер, и разработка ведётся локально, а потом ты что-то деплоишь. Эта мысль понятна и справедлива. Но я на своём опыте заметил: как только я начал потихоньку приучать себя работать в терминале на своём же компе — например, написал REST-сервер, мне нужно дёрнуть GET, я иду и пишу curl в терминале на макбуке. Казалось бы, что за идиотизм: у тебя есть Postman, HTTP-клиент в идее, две кнопки нажми. Но когда я преодолел порог странности — зачем я пишу curl, зачем запоминать -X GET, -d, как хедеры передавать, как body, — у меня начали по щелчку решаться проблемы в окружении. Например, внутри Kubernetes бежит бэкенд, что-то не работает. Большинство вокруг: блин, это что, надо Remote Debugger подключать? А как? А я просто делаю SSH, захожу в под, делаю там curl, смотрю — а, вот это не работает. Проблемы, которые, если у тебя нет этого на кончиках пальцев, ты просто не будешь решать: да какой curl, пойду GPT спрашивать, да ну нафиг, пойду лучше чайку попью. Начинаешь отходить от задачи, а я просто решаю и иду дальше. Это прямое следствие того, что я иногда занимаюсь такими странными вещами локально. Всё-таки актуальность уметь что-то сделать в терминале есть — просто потому что сервера никто не отменял, и есть вещи, которые нужно смотреть прямо на бегущих машинах: например, проблемы с сетью внутри пода в Kubernetes. Как ты это будешь решать с локального GUI?

[49:55] Никита: Я согласен. Я имел в виду немножко другое. Работать в терминале полезно и нормально — а вот пытаться засунуть в терминал редактор, вот что мне кажется странным. Редактор по определению графическая штука: у тебя список файлов, текст бегает туда-сюда. Это не терминальное приложение, у него нет ввода-вывода текста. Вот это мне непонятно.

[50:15] Александр: Знаешь, к чему пришли терминальные развитые сборки Emacs или Neovim, какие-то экстремальные случаи? Ты, наверное, как создатель Fira Code знаешь, что есть надмножество — Nerd Font. Это, по сути, прикольные лигатурки, встроенные девелоперские эмоджики. И с помощью этих комбинаций реально делают графический интерфейс в терминале: этими иконочками собирают какие-то лэйауты, где-то появляется статический футер — то есть прям реально GUI. А когда начинаешь думать, что это просто как будто напечатано на машинке, символы печатные постоянно меняются и эмулируют графику, — это действительно становится странновато. Зачем, если ты можешь просто рендерить пиксели приложением, а ты берёшь текстом и эмулируешь? Костыль прям явный. Тут я с тобой согласен, но это экстремальный пример. Более-менее адекватно в разных случаях — это как ты пятнадцать лет назад Vim пользовался: плюс-минус он таким и остался, просто цвета появились.

[51:38] Никита: Ну да, дай фронтендеру возможность расширять редактор — он сделает из него что-то сложнее, чем идея выглядит. IntelliJ IDEA скачал — непонятно, но чуть-чуть можно разобраться. А смотришь на какую-нибудь сборку Doom Emacs, в котором куча всего, — такой: это круче, чем идея выглядит, как вы это в терминале сделали? Здесь я полностью согласен: от терминала мы, мне кажется, уходим и уйдём, не знаю когда. Но какая замена? Понятно, почему терминал живёт, почему GUI живёт. Что-то должно быть посередине — смесь Remote Desktop Development и терминала. Какая-то среда, в которой ты легко отредактировал код и запустил на том окружении, на котором хочешь, и чтобы это было прозрачно, просто, и все этим пользовались. Ну, фиг знает.

[52:10] Никита: Мне кажется, у Fleet была такая идея немножко: забрасывать на таргет-машину файл-систем-демон — демон, который умеет работать с файловой системой, — а интерфейс крутить локально. Соответственно, ты работаешь на удалённом проекте, но как будто он локальный. То же самое можно организовать через Network File System, подмаунтить удалённый файл, но тогда поиск по файлам не работает — очень медленно. А поскольку демон живёт там, он всё это умеет. Не знаю, в каком он состоянии сейчас, но изначально одна из концепций была такая.

[52:44] Александр: Да, такой Remote Development. Много попыток: какие-то клауд-IDE, в браузере что-то можно делать. Куча попыток, но как будто самым удобным реально способом остаётся SSH и Vim. Если тебе нужно не сидеть целыми днями программировать, а что-то подправить, проверить, запустить, быстро покрутиться в фидбэк-лупе, решить задачу — а дальше уже пойти нормально зачекаутить репозиторий себе на тачку и делать работу комфортно.

[53:17] Александр: Окей, про Vim мы нормально прошлись, про терминал тоже. Дальше мы планировали поговорить про расширяемость редактора — тему, которую почти не затронули.

[53:27] Никита: Да, давай.

[53:28] Александр: Давай я начну. Когда я вкатывался в программирование, идея плагинов и расширяемости была для меня новой. Я до этого играл в игры, которые не Майнкрафт, которые не расширяются, — есть программа, она работает. А тут получается, что есть программа, и ты можешь подключить туда кусочек другой программы, которая меняет поведение твоей, и это может сделать любой человек. Тогда я познакомился с плагинами идеи и такой: вау, открываю Marketplace, пошёл всё ставить. Думаю: чем больше плагинов, тем я круче, — такой был студент. В итоге это дико тормозило, зашумляло интерфейс, были неконтролируемые поломки, постоянно ломалась совместимость. И я ушёл в абсолютно противоположную сторону: вообще ни одного плагина, только один — котик с загрузкой, просто чтобы что-то было, потому что он всегда работал. Сейчас у меня один плагин — Vim, чтобы работать комфортно, и всё. Но расширяемость как тема довольно интересная. Есть у тебя мысли, как она должна быть устроена и нужна ли она?

[54:46] Никита: Да, думаю, нужна, потому что создатель редактора не может предусмотреть все случаи, которые тебе понадобятся. Я наблюдаю эту индустрию уже лет двадцать. Когда я начинал, open source уже начинал свой взлёт, но до этого мир был устроен по-другому: у тебя были вендоры — большая корпорация предоставляла всё, что нужно для работы. Идея IDE оттуда же: в одном пакете все интерфейсы, все ручечки для всего-всего, чтобы сделать приложение на Win32 или на Java с базами данных. Мир с тех пор ушёл в сторону open source: появился миллион мелких тулз, любой человек может написать утилиту, которая завтра станет популярной. И глупо ожидать, что JetBrains послезавтра напишет под неё плагинчик, — а сам разработчик тулзы может. Надеяться, что кто-то один покроет все случаи, невозможно. Соответственно, расширяемость нужна.

[55:57] Никита: Второй момент — твои частные задачи. Мне нужно всегда стартовать мою Clojure-программу с такими-то параметрами, потом коннектиться по Repl и открывать браузер. Комбинация трёх штук, я хочу сделать это одной кнопкой — почему нет? Чисто моя конкретная задача, все пути захардкожены. Это немножко другая расширяемость. Есть расширяемость, когда разработчик может написать плагин, а есть — когда я могу подхачить свой собственный редактор. Во втором случае король, наверное, Emacs: он всё время своего существования известен тем, что половину команд ты пишешь сам, чисто под себя. Там всё очень просто: открываешь файлик, который загружается на старте, пишешь туда код — и он автоматически подхватится.

[56:43] Никита: Поэтому, когда появился VS Code, идея была классная. Я думаю: о, отлично, наконец у нас будет Emacs, но с JavaScript. Проблема Emacs в том, что нужно писать на Lisp, а тут — прикинь, то же самое, но на JavaScript. Это же возможности взрывают мозг, можешь делать всё что угодно. Думаю: сейчас полетит. Он полетел, но немножко не так — под контролем Microsoft. А хотелось бы, чтобы под контролем людей, которые им пользуются. Там нужно сделать определённое количество телодвижений, просто чтобы оформить плагин: создать N файлов, скомпилять TypeScript и прочее, — и только тогда всё появится в редакторе. Это немножко сложнее, чем следовало бы. Плагины действительно есть, но это плагины других людей, не конкретно под твою задачу.

[57:34] Александр: Как с этим обстоят дела в Neovim? Тоже открываешь файлик и сразу фигачишь, как я понимаю?

[57:41] Никита: Это, знаешь, попытка найти золотую середину между экстеншенами VS Code и гибкостью Emacs с интерпретацией Lisp прямо везде.

[57:52] Александр: Там есть специальная директория домашней конфигурации, по дефолту ~/.config/nvim, и там лежит просто init.lua. Открываешь этот файл и пишешь в нём Lua-код. Lua — что-то похожее на JavaScript-Python, довольно доступный язык, чтобы что-то написать. Хочешь — иди по REST, сходи, возьми, положи, напиши текст себе в редакторе. Единственное ограничение: это всё Vim, и у тебя нет таких широких возможностей с точки зрения UI, как в VS Code. Дебаггер там свой написать довольно сложно, и есть проблема в Neovim с дебаггингом приложений: тебе нужно ставить брейкпойнты, шаг дальше, текущий стек-фрейм печатать — это прям UI-задачка, сложно решать в терминале. С этим бывают проблемы. А всё остальное — просто добавление плагина. Ты пишешь одну строчку кода с GitHub-репозиторием, у тебя есть плагин-менеджер, он его подцепляет, устанавливает — и он начинает работать. Максимально просто: копируешь путь до GitHub-репозитория, вставляешь строчкой в файл, и он подсоединяется. Естественно, можешь тут же конфигурировать, но по дефолту работает. Я себе так Copilot поставил.

[59:19] Александр: Самый приятный юзер-экспириенс, который я когда-либо испытывал. Есть в Vim-сообществе такой Tim Pope, известный чувак, он написал этот плагин. Я литерально добавил одну строчку себе в конфиг, которая указывает на GitHub, вставил, сделал сейв, перезагрузку редактора — я обычно выхожу-вхожу, но есть и команда Reload, — и у меня начал работать Copilot. Я такой: вау, это всё? Был в шоке. А теперь сравни, как в идее выглядит запуск Copilot.

[1:00:19] Александр: Тебе нужно понять, что это плагин, найти его, пойти в plugins, в этом Marketplace среди тысячи других выбрать нужный, нажать install, он скажет relaunch IDE, ты релончишь, потом появится окно, в нём надо нажать «открыть», понять, что нужно пройти аутентификацию, идёшь туда, тебя перекидывает на сайт, копируешь код, вставляешь, переходишь обратно, забыл закрыть табу в браузере, идёшь её закрывать — куча гемора. Было у меня так с плагином в идее. И вот — одна строчка, плагин в Neovim. Такая вот разница.

[1:00:19] Никита: Круто. На самом деле, ты, мне кажется, не совсем прав насчёт того, что в VS Code легче написать дебаггер. VS Code сильно ограничивает пространство того, что ты можешь модифицировать экстеншеном, — там всё довольно ограничено. Вот в Atom можно было сделать: Atom давал тебе полностью HTML, ты мог создавать новый DOM, а в этом DOM — любой CSS, и делать все возможные штуки. Например, в Clojure кто-то делал плагин: валишь формулу, получается результат — и у тебя интерактивное маленькое дерево с этим результатом, вложенные мапы, можешь их разворачивать, проваливаться внутрь. Это всё был кастомный HTML. А в VS Code такого нельзя — только то, что они тебе разрешили. Это лучше работает для них в смысле экосистемы: они могут контролировать API. В Atom, как я понимаю, были с этим проблемы — весь редактор доступен, любой код можешь писать, и в итоге они не могли ничего нормального развивать, потому что если что-то поменять, какие-то плагины сломаются. Но зато для пользователей было дружелюбнее.

[1:01:24] Александр: А с точки зрения написания плагинов у тебя опыт есть? Ты писал плагины под какие-то редакторы?

[1:01:30] Никита: Я писал под Sublime Text, у меня сейчас несколько есть. Есть Clojure-плагин, который делает прям серьёзные вещи: парсит Clojure-код, коннектится в Repl и валит всякие штуки — довольно большая штука. Есть несколько попроще, несколько команд чисто для моих нужд, чисто локальных. На Python — кстати, Python тоже нормально для плагинчиков.

[1:01:56] Александр: Да, Python и Clojure — брат-близнец-сват в плане того, как на нём писать код. То есть какой у тебя экспириенс: принял решение написать плагин — что делаешь? Тебе доступны точки интеграции с редактором?

[1:02:10] Никита: Ну да, он похож чем-то на VS Code, потому что там нет свободного HTML — вообще нет HTML. Ты можешь делать ограниченное количество вещей: создавать текстовые буферы, писать в них, читать, аннотировать. Собственно, Eval работает так: есть специальная штука, ты выделяешь регион текста и аннотируешь его — справа печатается аннотация, это результат Eval. Но это примерно всё, что можно делать. Есть терминальный плагин для Sublime — один из наиболее замороченных, которые я видел. Они очень сильно постарались воспроизвести экспириенс терминала при том, что у тебя это текстовый буфер, панель для блокнота, в которую ты можешь вставлять и удалять текст. Каким-то образом заморочились, чтобы это выглядело похоже на терминал: стрелочка вверх работала, всякие команды, цветной output.

[1:03:07] Александр: Это абсолютно диаметрально противоположный пример. GUI в терминале, а это терминал в GUI.

[1:03:09] Никита: Да-да. Но терминал уже почти везде есть: в VS Code есть, во Fleet даже есть. Это одна из первых вещей, которые, мне кажется, делают IDE современными. Связано с тем, что никому неохота переключаться на второе окно — удобно, когда в том же окне ты быстро делаешь curl, как ты говорил.

[1:03:29] Никита: Если бы у них было больше денег, они бы, наверное, сделали встроенный терминал чуть лучше по качеству, но денег не так много, поэтому это сделали сторонние люди. Что говорит о пользе комьюнити.

[1:03:44] Александр: Про Sublime Text давай чуть попозже поговорим — прям видно, что ты в нём давно сидишь и знаешь экосистему. У нас есть раздел про такие легковесные редакторы: Sublime, Zed, немножко Fleet, немножко ещё про VS Code дотронемся. Но прежде чем про лёгкие редакторы говорить, есть смысл поговорить про самый популярный редактор, по крайней мере в Java-комьюнити, — IntelliJ IDEA, и начать с интерфейса. Поясню: я поймал себя на мысли, что вся моя кастомизация IntelliJ IDEA — это что я выкидываю нафиг всё из интерфейса. Это единственное, что я кастомизирую в этом продукте. Ну и плагин IdeaVim.

[1:04:01] Александр: По дефолту у меня есть ужимный ноутбук, на нём IntelliJ IDEA стоит, я смотрю и вообще не понимаю, как можно разобраться в этом интерфейсе. Окно для редактирования кода — реально четвёртая часть экрана. Ещё треть — это Project View, процентов двадцать — всякие странные рамки, которые нафиг не нужны, и терминал. То есть полезной нагрузки процентов сорок-пятьдесят по дефолту, если ничего не настраивал. Я смотрю и думаю: да как ты тут вообще программируешь, что ты хочешь увидеть? У меня даже есть записанный стрим на YouTube, который довольно много просмотров набрал, где я просто сижу и из идеи выкидываю: вот это нафиг, вот это нафиг, здесь шрифт поменять, здесь чтобы это не показывалось. В итоге у меня остаётся окно, где я печатаю код, терминал, а нужные окна и тулбары выскакивают по клавишам и убираются тут же. Шумность таких больших продуктов — IDE, VS Code, Xcode — как будто бы должна была быть фичей, но сейчас, по крайней мере мне, кажется, что это обременение, и надо бы от этого избавляться. Что ты думаешь?

[1:05:47] Никита: А идея, кстати, они же почистили интерфейс, ты новый UI видел? У меня новый UI стоит, и из него я тоже много всего выкидывал. Там есть очень странные по бокам рамочки с иконочками — Git, терминал, Gradle, Maven, — они занимают много места. Я их убрал сначала в Compact Mode, а потом просто убрал, потому что не нужны. Я Shift-Shift нажимаю и вызываю нужный тулбар по имени: нужен Gradle — пишу Gradle, какие проблемы. Ещё убрал верхнюю панель, табы перестал показывать — убрал вообще всё. У меня голый редактор с одной тоненькой полосочкой внизу.

[1:06:37] Александр: Я помню: старый интерфейс особенно, эти панели сбоку, иконки, которые разворачиваются, — я их сворачиваю, но в итоге слева столбик иконок, справа столбик панелей, снизу столбик иконок, и такой: блин, обложили со всех сторон, как тут жить-то? Не очень понимаю, зачем они все четыре. Должно быть место, чтобы дышать спокойно. Соберите их в одну кучу с одной стороны, зачем так делать?

[1:07:16] Никита: Да, я согласен про шумность, но это ещё интересный вопрос. Я всю жизнь думал, что это просто бред и так быть не должно. Недавно видел твит чувака, который жалуется на шумность Notion. Notion не самый худший интерфейс, но там тоже чуть больше иконок, чем нужно. Читаю — да-да, абсолютно согласен. А потом чувак пишет: ну, для меня это не очень. Такой: подождите, да меня это тоже отвлекает. Я пока живу в гипотезе, не очень подтверждённой, что весь этот визуальный мусор одних людей отвлекает, а другие просто не смотрят туда, и всё нормально. Иногда страшно смотреть на чужой компьютер: миллион вкладок, док торчит, тут нотификация. Видел, чувак программирует, а у него поп-ап макосовский с нотификацией висит, и он его просто не закрывает, даже не обращает внимания. Я говорю: закрой, ты что! Возможно, не все одинаково на это реагируют. Но я реагирую — не могу смотреть на весь этот шум. Поэтому люблю, когда мало иконок, есть командная панель: понадобится — вызову, что нужно, а не хочу постоянно на это смотреть.

[1:08:36] Никита: IntelliJ, кстати, новый интерфейс выглядит более-менее. Мне не нравится, что у них огромные иконки, и ещё нотификации на них — кругляшочки, типа здесь что-то новое, синий такой. Я такой: блин, надо посмотреть, сходить. Мне не надо, но поскольку он висит, я не могу смотреть на то, как он висит.

[1:08:57] Никита: Но самый сигнал, когда всё пошло под откос в IDE, — это когда придумали нотификации текста в редакторе. В VS Code, по-моему, один из первых ввёл, хотя, может, в IntelliJ было до этого. В VS Code есть интерфейс для управления нотификациями, и он постоянно тебе что-то выдаёт. Мне кажется, это полный бред — редактор кода не должен задерживать нотификации, я не хочу отвлекаться на шум. Думаешь: окей, может, он нужен, чтобы показывать что-то полезное. Но поскольку такой интерфейс есть, у людей нет самоконтроля: они не понимают, когда уместно что-то показать. И все разработчики плагинов начинают пихать всякое: о, наш плагин обновился с версии 0.13.7 до 0.13.9. Ну офигеть, спасибо, что отвлекли меня от работы, очень важная информация. Раз механизм есть, им начинают пользоваться. Единственный способ сделать нормально — чтобы его не было: тогда никто не может показать нотификацию, все заткнулись, и ты работаешь спокойно.

[1:10:00] Александр: Нотификации — ты имеешь в виду всплывающий алерт?

[1:10:04] Никита: Да, всплывающие алерты, квадратные такие.

[1:10:07] Александр: А над иконкой — это тоже, как он называется, индикатор. Я в целом полностью согласен. Не уверен, что некоторых это не раздражает, а некоторых раздражает. Программирование — процесс, который делается в редакторе и у всех требует концентрации. И то, что эту концентрацию отвлекает, — это как раз нотификации. Вопрос: зачем инструмент, созданный для того, чтобы в нём концентрироваться, делает противоположные вещи? Не понимаю.

[1:10:41] Никита: Никто не знает. Но мне кажется, это всё у разработчиков IDE. У них немножко другие цели: им нужно продавать свою IDE, а не чтобы ты максимально оптимально работал. Им нужно продать максимально большое количество копий. Поэтому там есть вещи, которые, если подумать, не очень в интересах пользователя, но в интересах продажи. У VS Code миллион фич, и они пихают всё, что могут придумать, потому что чем больше фич, тем больше шанс зацепить конкретного человека. В Sublime Text одна десятая фич — но это те, что мне нужны, поэтому он меня зацепил. А кого-то не зацепил, зато в VS Code он увидит то, что ему нужно. Это не всегда в интересах пользователя. Частично это карго-культ, частично люди просто не понимают, как это работает. Ты сделаешь интерфейс IDE чуть похуже — и у тебя нет никакого фидбэка, как ты узнаешь, что стало хуже? Продастся ровно столько же копий, потому что продажи идут через business-to-business. Как ты узнаешь, что пользователи начали страдать? Никак. Это нездоровый цикл, и от них не стоит ожидать инноваций в этой области.

[1:11:55] Никита: Инновации надо ожидать от каких-то андердогов, которым нужно захватить рынок сейчас, только на него выйти: им нужно понравиться пользователям, действовать в их интересах. IntelliJ не нужно — она уже победила, ей просто нужно продолжать существовать, она продаётся сама. Возможно, отчасти поэтому люди иногда выбирают Neovim — просто потому что там чисто open source, и люди, которые его разрабатывают, сами пишут код. Они понимают, чего хотят, и дают тебе возможность программировать так же, как они. У них нет sales-ов, которые определяют, что делать, а что нет, — они сами определяют. Поэтому продукт для разработчиков получается довольно приятный. Даже не продукт, а просто open source soft, который люди пользуют и расширяют.

[1:12:40] Александр: По поводу шумности и фичей: есть некоторые киллер-фичи в больших редакторах, которые прям очень классные. Никто не спорит, что дебаггер в идее для Java просто замечательный — один из лучших дебаггеров вообще среди всех языков, очень удобно дебажить. Но я как программист, который уважает эту фичу и иногда её использует, не хочу видеть другие сто фич и даже знать о них, потому что они мне совершенно нерелевантны. Мне абсолютно не нужна поддержка какого-нибудь docker-compose в идее — я docker-compose запускаю в терминале, потому что считаю, что это единственное место, откуда его надо запускать: и на сервере из терминала, и локально из терминала. Иначе может случиться, что в идее он работает, а на сервере в терминале — нет. А оно там есть и иногда требует обновлений. Я уже не говорю про то, что когда обновляешь идею, какой-то левый плагин отваливается, Lombok например, и ты такой: блин, я не хочу, чтобы он вообще существовал. За тебя решают то, что не надо за тебя решать, — ты сам можешь это решать.

[1:13:54] Никита: Ну да, так есть. Какой-то чувак сказал классную фразу про Excel, когда Excel был на взлёте, — да и до сих пор doing strong. Он говорит: это правда, что большинство пользователей Excel используют от силы 10% Excel. И правда, что многие стартапы пытаются скопировать эти 10%. Но секрет популярности Excel, почему он всех победил, в том, что каждый пользователь использует свои 10% — всегда разные. Кому-то нужен этот кусочек функциональности, кому-то тот, но все ведут себя так, как хотят. Думаю, к идее примерно тот же принцип применим.

[1:14:32] Никита: А второй момент — я так говорил, когда VS Code начал катиться под откос, когда он мне разонравился. Не знаю, считают люди, что он катится под откос, или нет, но мне разонравился. Думаю, когда он обогнал Atom, у них просто стало слишком много денег. У тебя много денег, много разработчиков, много возможностей — и в итоге ты делаешь фичи, которые не критичны для выживания продукта, а просто nice to have. Могли бы быть, могли бы не быть. Вот я открыл страничку с идеей: там скриншот довольно чистенький, но рядом с каждым методом какая-то иконка, буква «i» в кружочке. Что это значит? Не знаю. Зачем мне это? Тоже не знаю. У них были деньги, чтобы разработчик пошёл и эту букву имплементировал. И поэтому мне частично нравится Sublime: на нём сидят три разработчика, и все фичи, которые они делают, супер-критичны для выживания продукта. Они не делают булшита: если у них есть силы, то на что-то, что действительно нужно. У них нет сил распыляться над nice to have. И мне как пользователю это нравится, потому что Sublime целиком помещается у меня в голове: я знаю все его функции, знаю, что они делают, у меня нет ощущения, что я должен что-то использовать. Ничего не отвлекает. It’s very focused — именно на том, что действительно важно, а не на том, что в принципе могло бы быть.

[1:16:00] Александр: Да, интересная мысль. Парадоксально, но много денег не всегда хорошо. Я раньше об этом сильно не думал, но в фоне проскальзывало: когда пишешь софт больше трёх лет, не знаю, 10–15 лет, начинаешь понимать, как в целом софт разрабатывается, и что много людей в продукте — непонятно, хорошо или плохо. Это вообще ничего не значит. Очень часто может быть плохо, потому что чем больше людей, тем меньше процент талантливых, увлечённых, реально горящих продуктом. Условно 10% реально хотят сделать классно и относятся ответственно, остальные 80% просто работают: есть задача в Jira сделать фичу — пойду сделаю, я в офис пришёл, мне бонусы получить. Они относятся к этому не так, как я. И продукт получается такой: денег много, фич много, но каждая в отдельности не великолепная, не заставляет восхищаться. Она просто есть, как-то работает, и можно на сайте сделать скриншот, что это есть, и продать. Для кого-то это окей — для тех, у кого машина просто средство передвижения из точки А в точку Б, нет разницы между классным Audi Avant и просто Logan: что-то, что довозит. Но для автолюбителей разница огромная. И тут тоже есть разделение: для тех, кто ценит софт и понимает, как человек вложил сюда душу, подумал над этим, — ты это ценишь как профессионал. А кто-то просто: мне надо сделать коммит, написал, push, кнопку нажал, оно ушло, таску в Jira передвинул, какие вопросы. И то, и то имеет право на жизнь, просто это разные штуки. И Sublime как раз хороший пример тех людей, которых немного и которые прям ответственно относятся к тому, что делают, вкладывают душу.

[1:17:56] Александр: Мы можем уже про Sublime поговорить. Чем он тебе настолько нравится, почему ты его предпочёл? Понятно, почему идею, понятно, почему Vim, — это что-то рядом стоящее. Но есть же и другие редакторы-конкуренты Sublime, про которые мы тоже чуть-чуть поговорим. Давай конкретно про него.

[1:18:15] Никита: Ну а какие конкуренты Sublime?

[1:18:17] Александр: Подожди, у меня как раз методом исключения получилось — больше ничего не было. На тот момент, когда ты переходил, наверное, ты прав, но тогда был Atom. Мне казалось, что Atom — что-то похожее на Sublime. Но сейчас понимаю, что с точки зрения перформанса и того, как редакторы работают, Atom — всё-таки немножко другое.

[1:18:36] Никита: Да, изначально вся эта история началась с TextMate. Был TextMate, супер-минималистичный редактор под macOS, со всеми цеплениями макосовских конвенций. Одна из его основных фишек — что ты мог работать на любом языке: открыть файл на любом языке, и он не сильно много мог предложить, но подсветить синтаксис мог. С тех пор эту штуку украли. Идея, например, в этом смысле не так хорошо работает: мы делали в JetBrains проект, в котором был Java и C++, и такие — стоп, а как нам сделать его в идее? Никак. Либо Java, либо C++, ты не можешь сделать один проект, в котором и то, и то, — нужно две разные идеи держать. Короче: TextMate, Sublime, потом появился Atom. Atom был exciting, потому что это те минималистичные редакторы, но теперь с JavaScript, — всем понравилось, потому что все любили JavaScript. Потом VS Code перехватил пальму первенства на тех же принципах, но с деньгами Microsoft. Перформанс у Atom был окей, но он мне не очень нравился: у него был не очень качественный интерфейс, сделанный на веб-технологиях, тяп-ляп — всё дрожало, ехало куда-то, криво стояло. А Sublime сделан на OpenGL, там иконки ровно стоят и текст ровно написан, потому что им не нужно бороться с HTML.

[1:20:00] Никита: В целом перформанс мне очень нравится. Сейчас основной аргумент за Sublime — это перформанс: он быстро стартует, быстро редактирует, открывает большие файлы, парсит и подкрашивает очень быстро. И минималистичность: там очень мало фич, но именно те, что мне нужны, поэтому он полностью помещается у меня в голове. Экосистема плагинов, наверное, не самая лучшая, но мне хватает. Не хватало Clojure — я сам пошёл написал. Для большинства людей, наверное, не самый оптимальный способ, но мне было по кайфу.

[1:20:28] Александр: Давай топ твоих фичей, которые ты считаешь необходимыми, которые в Sublime есть и должны быть в самом минималистичном редакторе.

[1:20:34] Никита: Ну, подсветка синтаксиса — и, в общем-то, всё. Что там у меня ещё есть? Подсветка синтаксиса.

[1:20:43] Александр: Автокомплит есть какой-то? Начинаешь печатать — что-то дополняют.

[1:20:47] Никита: Да, кстати, автокомплит. Мне кажется, это гениальное решение, по-моему из TextMate пошло. Автокомплит в Sublime работает по текстовому файлу: если он видит такое же слово у тебя в этом файле, он его дополнит; не видит — не дополнит. Когда работаешь в Java, ты пишешь object., и в Java нужно сообразить, что этот object типа Object, сходить посмотреть, какие у него методы. Это интеллектуальный автокомплит, реально сложный. Не скажу точно, можно ли сделать это в Sublime — возможно, что-нибудь через LSP. Но по дефолту, если ничего не делаешь, Sublime будет автодополнять просто всеми словами, которые есть в файле. Напишешь obj, нажмёшь автокомплит — он посмотрит, что раньше ты уже писал слово object, и предложит его. Самое смешное, что этого достаточно, по крайней мере мне. Я с особо большими проектами не работаю, и мне хватает выше крыши: либо ты знаешь короткое слово, либо слово длинное, но оно уже где-то есть, — жмёшь Tab, и оно дополнится. Go to Definition в Sublime есть, кажется, с третьей версии, но я им не пользуюсь: мне проще поискать или перейти в нужный файл.

[1:22:01] Никита: Вот, кстати, мега-фича — мультикурсоры. Их вроде придумали в Sublime, если не путаю. Мне этот способ нравится больше, чем в Emacs и Vim: ставишь нужное количество курсоров, где надо, и одновременно редактируешь текст во всех местах сразу. В IntelliJ, например, умеют парсить код, понимают, что есть что: видят, что переменная rect в одной функции локальная и в другой rectangle тоже локальная, ты говоришь переименовать — он переименует только внутри этой функции, потому что она локальная. Это классно, корректно, логично. Но я понял для себя, что часто нужно сделать редактирование, которое синтаксически некорректно. Условно, есть термин rectangle — он может просочиться в название функции, класса, в локальные переменные, в комментарии. Поскольку ты писал код про этот rectangle, оно много где упоминается, и в какой-то момент ты решаешь его переименовать — все эти места. И единственное, что их объединяет, — что это те же буквы; логически они в разных местах, но буквы те же. Такое переименование мне нужно гораздо чаще, чем то, что технически корректно. Поэтому я кайфую с мультикурсором: нашёл все вхождения слова, переименовал. А так я даже не знаю, что ещё. Плагины достаточно легко писать, мне это нравится. Я говорю: у него ничего нет.

[1:23:24] Александр: Про автокомплит ты прикольно мысль задвинул. Я для себя это сформулировал так: умный автокомплит переоценён.

[1:23:37] Никита: Да-да-да.

[1:23:38] Александр: Я тоже последнее время замечаю: не то чтобы он мне не нужен — он иногда удобный, — но я абсолютно спокойно могу без него писать код. Когда нарабатываешь какой-то процент опыта, даже если не знаешь, что у объекта должен быть такой метод, у тебя есть профессиональная чуйка, что он в каком-то виде есть. Это даже более здраво — когда начинаешь понимать, что делаешь. Мне нравится, что когда пишешь код и сконцентрирован, ты выражаешь мысль, а тебе её не автодополняют, не говорят, как написать, — ты сам. Это как если бы я сейчас говорил мысль, а ты бы меня постоянно прерывал и на две мысли вперёд поддакивал. Неестественно идёт программирование, когда всё автокомплитишь, потому что рано или поздно ты промахнёшься, оно скомплитит не то, прервёт тебя, да ещё задним числом. Мне нравится просто открыть Neovim и писать код, чтобы он компилировался, а я там грепом что-то менял, каким-то макросом или Vim-овской точкой везде поменял. Да, чуть дольше, но я понимаю, что меняю, где, когда, — и этот мануальный контроль даже удовольствие доставляет.

[1:24:44] Александр: Хочу отметить, что это ситуативно: моя ситуация, мои проекты позволяют мне работать на Sublime Text. Я какое-то время работал на большом легаси-проекте — много людей, очень много кода, — и я бы, наверное, подофигел работать в Sublime без Go to Definition, без автокомплитов, потому что там другая ситуация: кода реально очень много, он не помещается в голову, меняется каждый день. Пришёл завтра — кто-то уже накоммитил, подвигал, и ты не знаешь, где что лежит, особенно на Kotlin. В Java ещё более-менее, а на Kotlin ты можешь любой метод, функцию, переменную, класс положить в любой файл — нет соотношения один к одному. Я знаю, что мне нужен такой класс: в Java по имени файла найдёшь, а в Kotlin название файлов абсолютно рандомное, поэтому без Go to Definition было бы очень тяжело.

[1:25:42] Никита: И Sublime для меня стал самым естественным способом редактировать именно текст: я на всё смотрю как на текст, не как на код, для кода нет чего-то специального. В IntelliJ есть файлы, которые она понимает, и файлы, которые не понимает, — с теми, что понимает, гораздо лучше работать. А в Sublime все текстовые файлы одинаковые, поэтому очень легко переключаться между языками: Bash, Python — нажал, и всё одинаково работает. Autocomplete я, кстати, тоже отключил по дефолту. Знаешь, как работает: пишешь что-то, и сразу выскакивает эта херня с вариантами. Ты даже не знал, что этого хочешь, а она говорит: я знаю, что ты хочешь. Я отключил, потому что она мешает, перекрывает то, что пишешь. Предпочитаю нажать сам, когда нужно, когда действительно устал печатать — давай, дополни.

[1:26:38] Александр: Да, или подзабыл что-то. Согласен. Кстати, очень хорошее замечание про то, что зависит от проекта. Слушатели, которые подгорели от моего «ты чё, грепом переименование делаешь, а ты попробуй в большом проекте, где JSON-ы в разных мапперах, ты же офигеешь всё это переименовывать», — тут, конечно, да, рефакторинг идеи, где ты просто нажал, и он прошёлся по дереву, мини-работу garbage-коллектора выполнил, достижимость переменной нашёл и везде, где она используется, заменил — и это точно корректно. Это прикольно. Но не очень прикольно с точки зрения того, что потом этот код приходится ревьюить: то, что умная идея сделала, а людям-то глазами смотреть. Я часто встречаю, что за этим шумом кода, который идейка автоматически зафигачила, ты суть начинаешь терять. И тут уже вопрос: а действительно ли кодовая база должна быть такой? Может, её переосмыслить, если без идеи мы не можем её дорабатывать? Но это уже философский вопрос, зависящий от конкретной ситуации.

[1:27:44] Никита: У меня есть ещё философский прогон.

[1:27:46] Александр: Давай.

[1:27:46] Никита: В целом про влияние IDE или простого текстового редактора на то, как ты пишешь код. Изначально предполагается, что чем больше твой редактор умеет, тем лучше. Идея помогает найти, где лежит класс, показывает, какие есть методы, — эту чисто механическую работу делает за тебя, ты тратишь меньше времени. До сих пор считается, что это безусловный плюс, никто даже не задавался вопросом, действительно ли это хорошо. Это статус-кво, никто не думает, есть ли тут минусы: очевидно же, что если компьютер сделал часть работы за тебя, это хорошо. Но есть неочевидный эффект. Ты начинаешь меньше интернализировать, как устроен твой код. Ты тупеешь. Когда ты бегаешь, нажимаешь Command-click, Go to Definition, — у тебя открыт файл, ты редактируешь функцию, видишь объект: ага, давай посмотрю на него, — нажимаешь и переходишь сразу туда, где он лежит. Когда делаешь это постоянно, у тебя не запоминается, где что лежит, как организован код, как называются файлы. Эта информация просто не попадает в мозг, потому что не проходит через него: ты напрямую переходишь к результату. Это как если бы тебя учили математике, но сразу давали ответы: не учили решать примеры, а учитель всё время давал ответы, — ты бы ничему не научился.

[1:29:08] Никита: Я заметил, что если работаешь в «тупом» редакторе кода, то начинаешь больше уделять внимания тому, где что лежит: в каком порядке организованы файлы и функции, как они называются, какие папки. Ты начинаешь на более интимном уровне работать с кодом, плотнее его понимать, у тебя больше контекста, больше кода загружается в мозг. Я несколько раз это наблюдал. Первый раз — когда с Eclipse перешёл на Sublime, тоже на Java писал, удивился приятному эффекту. Потом попал в JetBrains, мы писали на Kotlin в IntelliJ, и я заметил, как начинаешь просто кликать на все эти штуки и вообще не понимаешь, в каком файле находишься — в середине, в начале, в конце. Почему это здесь? Почему эти две вещи рядом? Ничего не понимаешь. Как будто каждая функция существует в каком-то абстрактном месте, никак не расположена, не сгруппирована, никакой логики, последовательности нет. Мне этот эффект не очень нравится.

[1:29:52] Александр: Это всё подтверждается каким-то исследованием, у меня была про это статья в ЖЖ.

[1:29:56] Никита: Ты же не помнишь описание исследования. Но там примерно то же самое: если тебе сложнее пройти через проблему, когда её решаешь, то ты выдаёшь чуть лучше результат, потому что больше внимания уделяешь проблеме. Что контринтуитивно — казалось бы, всё должно только помогать. Но на самом деле есть и негативные эффекты у этой всей слишком хорошей помощи.

[1:30:31] Александр: Да, я тоже это заметил, только когда начал программировать в Vim. Там философия редактирования кода, если не брать способ, модальность, в целом очень похожа на Sublime: по дефолту никто тебе ничего не подсказывает, не помогает — просто берёшь и пишешь. Захотел подсветку синтаксиса — поставил Treesitter с этим языком. То есть всё по шагам, и ты понимаешь, что bare software editor — это просто нотпад: открыл и начинаешь писать. Потом: ага, синтаксис подсветил, Go to Definition. Ты начинаешь каждую отдельную штуку понимать. А когда у тебя такая махина перед тобой, ты её не можешь понять и просто по наитию пытаешься пробиться сквозь всё это, чтобы решить задачу и уйти. По факту помощь — в том, чтобы саму себя преодолеть: тебе помогают с тем, с чем в целом можно было бы и не помогать. Сами себе придумали и сами решаем эти проблемы.

[1:31:27] Никита: Ты очень хорошо сказал — как будто ты начинаешь чувствовать ответственность за этот код. Код, который ты сделал в Vim, в Sublime или в таком тупом редакторе, — это именно ты полностью всё создал, это твоя программа. А работа в IntelliJ — это больше как тебя пустили посмотреть в этот сложный механизм: ты там что-то поковырял и ушёл, но ты не отвечаешь за это всё целиком. Это не твоё, тебе просто дали немножко поковыряться.

[1:31:48] Александр: Да-да-да.

[1:31:56] Александр: Получается, мы хорошенько прошлись по большим продуктам, как IDE, довольно неплохо обсудили Sublime. И когда ты сказал «а какие конкуренты у Sublime», у меня сразу лампочка загорелась: Zed. Сейчас все про Zed. Но я не стал говорить, потому что знал, что мы планировали. Давай поговорим про этот редактор — мне кажется, это самый ближайший конкурент Sublime на сегодня, только переосмысленный и, обязательно надо сказать, написанный на Rust.

[1:32:24] Никита: Да, Zed — конкурент, но новый, появился совсем недавно, в этом году. Народ был очень восхищён, а я сидел и пожимал плечами: ребят, Sublime есть, он до сих пор такой же быстрый, даже, по-моему, чем-то быстрее. У них дурацкий график на главной странице, где они показывают, что они быстрее. Я померил два раза разными способами — они не быстрее Sublime.

[1:32:46] Александр: Да, в latency вот это не улучшено.

[1:32:48] Никита: Но в целом да, всё правильно: написанный с нуля на Rust редактор, очень быстрый. У них есть продающая фича — коллаборация: ты можешь подключиться с кем-то и работать совместно над файлом, как Google Docs, только внутри редактора. Уникальная фича, но мне от неё ни тепло ни холодно, восторга не вызывает. Если бы была нужна, может, восторгался бы. В целом приятный редактор. Создатели Atom решили сделать второй заход. Смотрел их стримы, они периодически рассказывают, как к этому пришли, — хорошие стримы. Они такие: мы типа первый раз пишем на Rust, для нас системное программирование, указатели — всё в новинку. Я такой: блин, ребята, вам по 20 лет программировать, вы старше меня. Или: решили не делать кастомный GUI, поэтому сделали второй дизайн, похожий на Tailwind. Я такой: ммм. Я сам занимаюсь кастомным GUI, и мне кажется, повторять веб — неправильное направление. Желаю ребятам удачи, но посмотрим, что получится.

[1:33:58] Александр: Мне нравится, как они позиционируют. Они как будто бро тебе: йоу, чувак, мы такие же, как ты, любим быстрый софт, пишем его, вот тебе факты, бенчмарки, прикольные штуки, и мы реально понимаем, что тебе нужно, и даём это. Тебе не внушают, как некоторые продукты, что тебе это надо, — тебе показывают. По-другому у них маркетинг выстроен, не могу сформулировать как, но мне нравится. И в плане коллаборативности — не первый продукт, который я пристально смотрю и который, скорее всего, начинался во время ковида: идея коллаборативности тогда была очевидна — парное программирование на расстоянии. Мне кажется, они в это пушили, а потом случился AI и ковид прекратился, и сейчас они прямо на главной показывают, что у них передовая интеграция с LLM, они коллабятся с Anthropic, есть специальная поддержка общения с моделью внутри редактора, итеративная штука. Как будто ребята немного свичнулись с коллаборации в сторону AI — понятно почему, им нужны деньги. И тут можно поговорить про закрывающую тему: языковые модели в редакторах, в программировании, в процессе набора текста. Автодополнение мы уже закопали. Есть у тебя вижен, как ты бы их использовал, используешь ли, и, может, пример мисс-юза этих технологий внутри редакторов?

[1:35:34] Никита: Да, сейчас про это закончу и потом отвечу. Давай.

[1:35:38] Никита: Я согласен, интересная штука. Я тоже заметил: у них очень хорошо с маркетингом, и я не очень понимаю, что именно они делают, но каким-то образом всё правильно и привлекают очень много внимания. С Atom тоже такая история была — он очень много внимания привлёк. Мне непонятно, что конкретно они делают, но хотелось бы так научиться. Я когда писал в канал пост про редактор Zed, кто-то мне: слушай, а есть же ещё один редактор на Rust. Я такой: действительно есть. Никто не слышал, всё то же самое, никто про него не знает. У них хорошо именно с маркетингом — интересная штука, они точно попадают в программиста. Похвально.

[1:36:20] Александр: Про свитч я на самом деле не задумался. Ну да, ковид-коллаборация, а теперь AI.

[1:36:26] Никита: А теперь это… По-моему, они начали до ковида, если совсем честно. Они же пытались на CRDT сделать редактор ещё. Между Atom и Zed у них было две попытки сделать редактор на CRDT.

[1:36:38] Никита: Про языковые модели. Я ничего не знаю, сразу скажу, не пользуюсь. Пытался пару раз попробовать Sonnet, но он мне не выдал ничего прикольного, не решил мои проблемы, поэтому я такой: ну ладно. Но опять же, я пишу на Clojure, у меня довольно специфичные, сложные, нестандартные задачи. Мне не нужно генерировать много boilerplate-кода — как раз Clojure хороша тем, что там минимум boilerplate. На C++, даже если делаешь что-то нестандартное, тебе часто нужна какая-то унылая длинная кодогенерация — вот это может быть полезно. А на Clojure такого не возникает, поэтому мне это как-то не особо нужно, и я не сильно пробую. Возможно, за этим какое-то будущее, может, стопроцентно, но пока меня не заменили, надеюсь. Мне нужно, чтобы ещё лет 15–20 оно было не очень хорошим. Потом уйду на пенсию, и пусть AI захватывает мир.

[1:37:39] Александр: Мне надо немножко побольше времени. Хотелось с точки зрения редактора кода и интеграции с этим, потому что интересно: языковые модели — это большой бум, и написание кода — одна из задач, с которыми они справляются лучше всего. Прямое применение, которое действительно может работать, потому что by design. Когда их пытаются применять для анализа каких-то сложных явлений, мне сейчас это кажется немножко странным — возможно, в будущем будет работать. Но с текстом они уже неплохо справляются: отредактировать мой кривой английский модель точно может хорошо, это задача, которая решается на сто пудов. И в редакторе я сейчас иногда развлекаюсь со стримами на YouTube, пишу базу данных на Rust. Это компилируемый язык, но когда описываешь модель данных, дерево, тоже много кода надо писать, довольно простого: структуры данных со ссылками друг на друга. И очень неплохо справляются. Тесты очень хорошо генерирую — сажусь такой: ну вот, давай тест. Написал имя теста, и он такой: вот тебе такой SQL на вход, такое дерево на выходе. Смотрю — да, надо так, — и просто принимаю. В некоторых штуках действительно полезно. Мне интересно было узнать твоё мнение, и хорошо, что поделился: ты пока не то что скептик — просто не нашёл применения для своих задач, потому что не справляется. Когда задачи сложные, ты пару раз пробуешь, оно бред выдаёт, и такой: нафиг больше не буду, зачем на это время тратить.

[1:39:00] Никита: Ну типа того, да.

[1:39:14] Александр: И, наверное, ещё вопросик, который хотелось обсудить, потому что ты человек, который что-то знает про редактор Fleet. Я, когда он только вышел в бете, себе поставил, посмотрел и подумал: надо подождать. И вот я уже жду довольно долго, а как будто ничего нового не происходит. Может, ты тоже отдалился от темы, но если есть что рассказать про Fleet — это тоже условно конкурент Zed, условно конкурент Sublime, в этой компании находится. Хотелось бы поговорить, потому что легковесный редактор от ребят, которые делают IDE, — что-то, что должно быть интересно.

[1:39:50] Никита: Концепция там точно интересная. Насчёт того, что ничего не происходит, — по-моему, они плагины недавно выкатили, но я не особо слежу. Насчёт легковесности он, конечно, не очень легковесный: стартует несколько секунд, занимает довольно много памяти, поэтому это не конкурент Zed или Sublime. Легковесный редактор надо писать на C++, ты не напишешь легковесный редактор на Kotlin — это нонсенс. Но ощущается он легковеснее, чем IntelliJ, хотя я в этом тоже не уверен. Как мне казалось изнутри, возник он частично из-за страха перед VS Code: VS Code так хорошо продаётся, всех завоевал. Особенно тяжело конкурировать, потому что VS Code бесплатный. Но это моя интерпретация, а не официальная позиция компании. Они хотели мультиязычный редактор по новым принципам, но новые принципы сложно изобрести в этой области: что ты сделаешь такого, чтобы все побежали скачивать? Что сделали в Zed — я не знаю, не уверен, что много людей пользуются.

[1:40:52] Александр: Ты видел человека, который на Zed прям фулл-тайм сидит?

[1:40:55] Никита: Фулл-тайм? Нет. Одного, кстати, недавно видел.

[1:40:59] Александр: Меня часто спрашивают, а почему ты в Zed не программируешь. Я не знаю, что ответить. Хайп он поднял большой, но не уверен, сколько реально людей перешло. Явно не уровень даже Neovim пока что.

[1:41:11] Никита: Поэтому не очень понятно, что такого можно сделать в редакторе. Но в целом там были интересные концепции. Одна из них — Remote Development: ты закидываешь демона на отдалённую машину, он работает с файловой системой локально на той машине, а тебе пересылают высокоуровневые команды — открыть, прочитать, записать файл, поиск по дереву файлов сделать, такие вещи, чуть более умные. У Fleet заложено, что ты можешь подключить мозги от IntelliJ. Если у тебя слабый компьютер, запускаешь его без мозгов, и он даёт базовую подсветку синтаксиса и редактирование. Если сильный — запускаешь с мозгами от IntelliJ, и он делает автокомплит, рефакторинги. Плюс потенциально можешь крутить эти мозги на сервере, индексы будут храниться там, и вся компания может их шарить. Тоже интересная концепция, не знаю, насколько она сейчас реализована.

[1:42:04] Никита: Но в целом мне кажется — и это моё личное впечатление изнутри, а не факт о мотивах компании, — что JetBrains страдает от своего успеха: IntelliJ продаётся слишком хорошо, ничего для этого делать не нужно. Как мне казалось, написание Fleet не было вопросом выживания компании, поэтому к нему относились умеренно серьёзно, но не критически. Это не был продукт, на который компания сделала все ставки. Поэтому он получился такой ни туда ни сюда. У чуваков, которые делают Zed, это Zed-продукт, единственное, что они делают, самое главное в их жизни. У JetBrains Fleet таким не был, поэтому и восторга вызывает меньше. Но технически проект интересный, мне работа на нём была интересна. Мы сделали кастомный рендер — я делал, наверное, с Skia, графической библиотекой Google Chrome и Android. Мы притащили её в Java, у нас там свой UI-фреймворк, всё полностью кастомное: нет ни Swing даже, ни веба, не дай бог. Все UI-компонентики рисуются с нуля, все менюшечки и текстики. Довольно прикольно, и архитектурно очень интересный. Но, видишь, это tough sell: не так легко заманить людей на такие идеи, большинству нужно просто открыть файл локально. Сложно предложить мега-улучшения.

[1:43:18] Александр: Ты очень интересно затронул тему UI на Java, Swing и Skia, и того, как это сделано во Fleet. Мне как человеку, у которого супер-задротский подкаст про базы данных, это дико интересно. Но если мы начнём про это говорить, будет просто бесконечный жёсткий разговор. Если вдруг кому-то интересно, ребят, заходите в блог «Стой под стрелой» Никиты в Telegram и пишите ему под постами: хотим узнать, как работает рендеринг в Kotlin, — потому что реально интересно. Но я бы не хотел туда погружаться из экономии времени Никиты.

[1:43:50] Александр: В общем-то, мы с тобой прошлись по многим редакторам. Почти все самые популярные, которые на слуху, сегодня прозвучали. Разве что про Helix не поговорили, но вроде как ни Никита, ни я особо ничего про него не знаем, поэтому что говорить. Модальный редактор, только наоборот, не как Vim.

[1:44:08] Александр: Всё, что я знаю про него: в Vim у тебя сначала действие, а потом объект — или наоборот, объект?

[1:44:14] Никита: Да, наоборот. Короче, то, над чем ты делаешь действия, а в Helix наоборот. И мне кажется, что наоборот более правильно, чем в Vim. В Vim частично мне не нравится, что сначала ты говоришь «удалить», а потом «что удалить». Когда составляешь предложение, звучит нормально, но когда думаешь про механическое действие — сначала, наверное, хочешь указать на что-то, а потом удалить. И в Helix более правильно сделано, с точки зрения вкатывания. Но в целом, мне кажется, и к тому, и к другому можно привыкнуть. Просто модальность там присутствует.

[1:44:43] Александр: Окей. Никита, есть ли тебе что-то, что ты хотел бы сказать слушателям подкаста? Всё, что хочешь, можешь поделиться.

[1:44:49] Никита: Ну, в целом нет. Довольно много уже всего сказали, так что подписывайтесь на канал в Telegram.

[1:44:55] Александр: Да-да-да, это по-любому. Тебе отдельное спасибо большое за то, что согласился прийти. Создателю самого популярного шрифта среди программистов не каждый день удаётся записать подкаст. Большое тебе спасибо.

[1:45:07] Никита: Спасибо, что позвал.

[1:45:09] Александр: Ну и всё. Всем пока. Давайте, пока.