Четыреста слов про Брэма Муленара и vim

Когда я возобновил публикации про vim летом этого года, я совсем не ожидал, что вскоре прочитаю столь печальную новость.

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

Печальная новость о смерти Брэма Муленара

Люди смертны. К моему великому сожалению, земная жизнь Брэма Муленара внезапно завершилась.

 vim
vim

Более 30 лет Брэм Муленар выполнял титаническую и уникальную работу по созданию vim. Иногда, раздававшаяся критика, была отчасти справедлива, но не могла перечеркнуть простой факт — редактор давно стабилен, надёжно работает, и делает свою работу хорошо. Качество кода и надёжность vim давно стала привычной вещью для пользователей. Функционал редактора просто огромный и давно обеспечивает самые различные потребности, во всяком случае, даже опытные пользователи иногда обнаруживают новые для себя функции, о которых они раньше не знали и, с удивлением, начинают читать разделы документации, которая не слишком подробна, но в ней обычно написано всё необходимое для работы.

Заменить Брэма Муленара невозможно. Во всяком случае, заменить vim на что‑то более удобное до сих пор полностью нечем.

Cудьба vim

На появление vim повлияла историческая эпоха 80-х и 90-х. Это было время появления массовых и относительно недорогих компьютеров, построенных на базе микропроцессоров. Время определило такие свойства редактора, как экономное использование ресурсов, так и клавиатурный интерфейс.

Vim входит в большинство дистрибутивов Linux и BSD и, очень часто, используется не самая последняя версия, редактор стабилен и серьёзных ошибок давно не содержит, так что использование самой последней версии не особенно критично.

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

Сообщество разработчиков, возможно, сможет развивать продукт, но этого пока не случилось. Мы должны понимать, что любой человек, который попытается развивать vim, будет делать это совсем по‑другому. Не обязательно лучше или хуже, а просто по‑другому. Пример развития другого редактора — neovim довольно хорошо показывает этот банальный факт — программирование занятие столь индивидуальное, что получить похожий результат от двух разных людей невозможно.

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

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

Я не сомневаюсь в том, что vim надолго переживёт своего создателя, а имя Брэма Муленара будет долго напоминать нам о замечательном мастере, создавшем одну из самых удивительных программ.

@piratarusso
05.09.2023 13:20 UTC
Первоисточник

Комментарии

@DikSoft
05.09.2023 09:34 UTC
-6

программирование занятие столь индивидуальное, что получить похожий результат от двух разных людей невозможно

Это не программирование индивидуальное, это мир линукса превратился в бродячий цирк/зоопарк, где зверушки ценятся не за силу, скорость и выносливость, а за наличие ярких отличительных особенностей. Что ни программа, то своя уникальная "единственно правильная" логика в синтаксисе и логике команд и конфигурационных файлов.

@
05.09.2023 10:19 UTC
0
НЛО прилетело и опубликовало эту надпись здесь
05.09.2023 11:18 UTC
-3

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

Пример: найдите сходу формат принимаемый path_end в том же HAproxy, влюченном почти во все репозитории.

Докуменатация MS конечно тоже не подарок, но по полноте и общей целостности она рядом не стоит с линуксовым "разнообразием".

05.09.2023 17:29 UTC
+1

https://github.com/haproxy/haproxy/blob/fb4294be55d372a20aee0c0f430c508a20bfb020/doc/management.txt#L4166

30 секунд на поиски, при том, что я хапрокси вижу первый раз в жизни.

05.09.2023 17:31 UTC
0

Нагуглить, где это слово встречается, я тоже умею. Документация и описание где?

05.09.2023 17:43 UTC
+1

То есть doc/management.txt - это не документация?

Нуок :)

05.09.2023 17:47 UTC
+1

По приведеной ссылке нет ни описания, ни примеров синтаксиса. Ещё попытки будут?

PS Я кстати, таки нашёл, но искать каждый раз в глубинах и находить не факт, что актуальное описание, это плохая практика.

05.09.2023 19:44 UTC
0

По приведенной ссылке все кристально понятно любому, имеющему хоть минимальный опыт. Увы.

06.09.2023 12:45 UTC
+1

example\howto - НЕ документация, максимум - какая-то её часть. Из примера можно сделать вывод что "так - работает", но все ли это возможности? Могу я туда, скажем, регулярку запихнуть? А если "да" - то в каком формате?

"Документация" raw.githubusercontent.com/haproxy/haproxy/fb4294be55d372a20aee0c0f430c508a20bfb020/doc/configuration.txt вот это, но как найти без гугла - не особо ясно, если честно.

07.09.2023 14:28 UTC
0

но как найти без гугла - не особо ясно, если честно.

Эм... Впервые вижу этот софт, забиваю в гугл "HAProxy", перехожу на официальный сайт. Там в меню слева "Documentation", где, среди прочего, есть ссылка на Configuration Manual для каждой версии.

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

09.09.2023 05:33 UTC
+1

Прежде чем минусами раскидываться и писать, что коментаторы или тупят или слишком умничают перечитайте утверждение с которого ветка началась.

Узнать о существовании ACL path_end уже проблематично, но ок, узнали, что это string. А как туда ту же регулярку засунуть и можно ли вообще - только поиск в форумах.

И это общий стиль всей документации Линукс. Неполнота, никаких стандартов, агрессивное комьюнити. Вы яркий пример, кстати.

19.09.2023 21:00 UTC
0

В том файле, который вам показали, написано:

path_end : suffix match

Это просто suffix match. Просто сравнение с концом строки. Там обычно имена расширений файлов. Не нужен никакой regexp.

UPD. Вот и пример. Тот же файл:

Example:

acl url_static path_end .gif .png .jpg .css .js

@piratarusso
06.09.2023 04:05 UTC
+2

В vim с документацией неплохо. Что касается программ для Linux и Windows, то тут всё по-разному. Есть программы неплохо документированные, а есть не очень хорошо. К тому же многие программы из Linux переносят в Windows, гораздо реже переносят из Windows в Linux.
Так получается потому, что самые новейшие технологии в Linux появляются раньше.
Что же до "бродячего цирка", то он иногда случается. Но есть и вполне хорошо продуманные программы. У вас есть свобода выбора.

@Old_Pepper
06.09.2023 04:08 UTC
+2

Вы на мой взгляд заблуждаетесь. Если и сравнивать мир Linux, то скорее всего он похож на дикий лес, где выживает сильнейший. Вам не нравится vim? Есть nano, mcedit, emacs, тысячи их. Vim, Nginx, bind, и прочее популярное ПО выжило не потому, что не было альтернатив, а потому что (по мнению большинства) нет лучших альтернатив. Почему медленно умер SysV? Потому что появилась альтернатива - systemd

06.09.2023 04:53 UTC
+1

скорее всего он похож на дикий лес, где выживает сильнейший

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

В это плане пример HAProxy показателен. Сильный инструмент, с низким порогом входа. Но с совершенно формально и неполно описанными способами конфигурирования. То, что привели в качестве документации, и что устроило написавших комментарии, показывает, насколько все привыкли к необходимости "додумывать" мануалы и гуглить если, что-то осталось после неё непонятно. И это очень плохая черта мира Линукс.

06.09.2023 05:51 UTC
0

Это существенный недостаток программы. Но поскольку программа довольно древняя, то пользователи как-то справляются.

06.09.2023 06:04 UTC
+1

Это существенный недостаток программы.

Это общая беда экосистемы Linux. У HAProxy на общем фоне и за счет распространённости ещё очень даже неплохо всё выглядит. Да, свои закидоны с конфигами, но это у всех так. Что ни пакет, то всё своё. )

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

@azudem
06.09.2023 03:14 UTC
+3

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

@piratarusso
06.09.2023 05:17 UTC
+2

Я хорошо помню религиозные войны vim/Emcas. С тех пор у меня выработалась привычка воздерживаться от негативных высказываний в адрес emacs. Emacs по-прежнему разрабатывается, есть сообщество пользователей. Пользователи Emacs — это люди, которые думают по-другому.
Это, в конце концов, естественно. Мы все разные и это здорово: )

@checkpoint
06.09.2023 08:12 UTC
+1

Скажу больше. Я пользуюсь редактором vi/nvi из поставки FreeBSD уже более 25-ти лет и я не понимаю зачем мне что-то более навороченное. Уже 20 лет назад в vi были все необходимые для работы фичи. А еще мне нравится лаконичность команды :viusage вывод которой вмещается на одну экранную страницу. Команда :help в vim или neovim это отдельная кроличья нора.

То же самое могу сказать и про утилиту screen, которую увлеченные линуксоиды тщательно пытаются изничтожить и подменить хренью под названием tmux.