Когда-то давно, в сентябре 2009-го года здесь появилась первая заметка про мое знакомство с ViM, Ruby и рождение Mxx_ru: ViM, Ruby, Mxx_ru – пять лет в пути! Часть первая: Mxx_ru (вот вторая часть). Спустя пять лет вышло продолжение истории: Vim, Ruby, Mxx_ru -- десять лет в пути... Затем прошло еще пять лет и была написана заметка Vim, Ruby, Mxx_ru -- пятнадцать лет в пути... И вот, спустя еще пять лет, можно опубликовать очередную часть этой истории 🤓
Как бы это смешно не звучало, ViM продолжает оставаться моим основным инструментом.
При этом не могу сказать, что я чему-то еще научился за прошедшие пять лет (при этом пять лет назад знал и умел совсем немного). Продолжаю довольствоваться малым и использую ViM в минималистичном, можно сказать, базовом варианте. Под катом мой .vimrc, желающие могут посмотреть если это вдруг кому-то интересно.
В таком минимализме для меня, в общем-то, и кроется весь смысл ViM-а: я оказываюсь практически в привычном окружении на любой новой системе с минимальными телодвижениями. Это как раз то, что мне и нужно.
Про ViM могу рассказать показательную историю. В конце прошлого года подключился к проекту, в котором пока основная часть разработки ведется под Windows (с эпизодическими профилактическими сборками под Linux). Основная среда -- VisualStudio, даже сам проект был оформлен в виде .sln-файла. И, что самое важное, разработка ведется на сервере заказчика, доступ к которому дается через RDC.
Так вот, какое-то время я честно пробовал вести разработку в VisualStudio... Но сама VisualStudio оказалась тем еще тормозом, плюс у нее куча раздражающих меня настроек по умолчанию, когда она сама начинает что-то выравнивать, что-то переносить, где-то расставлять парные кавычки или скобки, которые мне не нужны, и последствия этого приходится удалять вручную... Плюс к этому добавляется не очень быстрый отклик при работе в самом RDC, т.к. я нахожусь чуть ли не в тысяче километров от сервера. В общем, набор кода в VisualStudio стал для меня тем еще испытанием и оказался крайне медленным и нервирующим процессом.
Пару месяцев терпел, но в конце-концов не выдержал. Установил ViM и начал писать код в привычном для себя окружении, а компилировался в командной строке вызывая devenv с передачей ему .sln-файла и нужных параметров. Можно сказать, вернулся в родной мир.
Так что ViM-ом продолжаю с удовольствием пользоваться. А посему могу смело сказать: 20 years with Vim and still learning :) And happy Vimmming!
Ruby практически не использую в последнее время. Нет необходимости. Уж не знаю хорошо ли это или нет, но вот не нужен он пока. Из-за чего уже основательно подзабыл этот отличный динамически-типизированный язык.
Пару лет назад в одном из проектов довелось столкнуться с Python-ом. Мне не нужно было на Python-е программировать самому, требовалось встроить его в C++ приложение, но все равно пришлось почитать что это такое и погрузится в некоторые его особенности. Порадовался тому, что в свое время выбрал Ruby, а не Python. Как по мне, так Ruby делали как инструмент для программистов, тогда как Python -- для <censored> не умеющих программировать, мягко говоря. И, судя по тому, какое распространение Python получил за прошедшие годы, умеющих программировать больше не стало 😏
Mxx_ru продолжаю использовать при разработке SObjectizer и json_dto. И кайфую от этого. Но это прекрасное время уже скоро закончится... 🥹
В прошлом году в RESTinio-0.7 мы уже полностью перешли с Mxx_ru на CMake.
Полагаю, что в 2025-ом или в 2026-ом, при переводе SObjectizer-а на C++20 (а может быть и сразу на C++23) мы также откажемся от Mxx_ru в пользу CMake. А там и очередь json_dto подойдет.
И дело здесь не в том, что CMake стал лучше. Нет, как был CMake говном говна, так и остается. Но так уж вышло, что CMake сейчас стандарт де-факто и что если ты хочешь, чтобы твоей разработкой пользовались, то поддержка CMake обязательна. Ну а тянуть в проекте две системы сборки -- это сомнительное удовольствие.
Тем более, что комитет по стандартизации C++ в очередной раз поднасрал C++никам внедрив в язык настолько говенную мудрёную систему модулей, что разработчики компиляторов все никак не могут допилить ее полноценную поддержку. Но допилят рано или поздно. А когда допилят, то окажется, что все наколеночные системы сборки (вроде нашей Mxx_ru) превратятся в тыкву: либо обновляйся и добавляй поддержку того, что придумали сумрачные гении из комитета, либо переходи на что-то другое.
Возможностей сделать Mxx_ru-2.0 с поддержкой C++ных модулей у меня нет и вряд ли найдутся, сам я не становлюсь моложе, запаса сил все меньше. Поэтому Mxx_ru доживает свои последние годы. Се ля ви.
Наверное, как-то грустно получилось. Но, с другой стороны, отрадно, что сама по себе история продлилась целых двадцать лет. Так что все хорошо, нет повода расстраиваться. Даже интересно, смоглу ли написать что-то на эту тему спустя еще пять лет. Будем посмотреть 😉
А вот и мой .vimrc, которым я пользуюсь уже многие годы. Из недавних добавлений там разве что настройка listchars.
set noet set exrc set tabstop=3 set softtabstop=0 set shiftwidth=3 set noexpandtab set autoindent set incsearch syn on set wildmenu set wildmode=list:longest,full let g:html_use_css=0 let g:load_doxygen_syntax=1 filetype plugin indent on colorscheme koehler set list listchars=tab:\┊\ ,trail:·,extends:>,precedes:<,nbsp:% set nu! set modeline set modelines=5 set undodir=~/tmp/vimundo set undofile set nohlsearch |
> Установил ViM и начал писать код в привычном для себя окружении, а компилировался в командной строке вызывая devenv с передачей ему .sln-файла и нужных параметров
ОтветитьУдалитьВам повезло, что можно было быстро вычислить нужные параметры для передачи devenv. Я, например, работаю сейчас над проектом, где самостоятельно параметры никогда не угадаешь. Благо, для этого дела уже сформированы питоновские скрипты
@sv
Удалить> Вам повезло, что можно было быстро вычислить нужные параметры для передачи devenv.
Так а чего там вычислять -- имя .sln-файла + имя цели (подпроекта) внутри этого .sln-файла.
Собственно, все параметры компиляции настраиваются внутри .sln (точнее внутри vcxproj-файлов для целей).
Другое дело, что в VisualStudio какая-то дебильная система определения параметров через диалоговые окна, в результате чего можно настроить параметры для Debug-сборки, но забыть сделать это же для Release-сборки.
Да, возможно это у нас настолько муторная система сборки. Вспомнил, что у нас не сам sln файл используется, а из cmake-а генерируется sln файл и потом исполнятся
ОтветитьУдалить@sv
УдалитьТак сейчас же VS поддерживает CMake из коробки. Или нужно именно devenv из командной строки запускать?
Ну вот както так получилось :) Как минимум, версия cmake, которой генерируется sln, и версия cmake, поддерживаемая студией, разная. Поэтому просто visual studio на cmake файле не запустить
Удалить@sv
УдалитьНу вот из-за таких вот фокусов и предпочитаю с IDE не связываться, а работать как в глубокой древности -- текстовый редактор отдельно, консоль для компиляции в командной строке отдельно :)