Здравствуйте, Skorodum, Вы писали:

ARK>>Я бы сказал даже так:
ARK>>

ARK>>gcc build_the_project.cpp
ARK>>

S>Так не получиться: нужна какая-то опция компилятору, говорящая, что этот файл особый и нужно запустить бинарь после сборки.

Этот файл не особый. А какой бинарь надо запускать, не понял.

S>>>Императивные языки для этого не особо подходят.
ARK>>Почему?
S>Например потому что придется ручками разрешать порядок сборки на основе зависимостей между проектами. Куда проще писать "A needs B needs C" и оставить на откуп системы сборки разрешение порядка.

Это должно поддерживаться на уровне языка. Никакие системы сборки не нужны. Мало того, такие языки уже есть — Jai от Джонатана Блоу, например.

Здравствуйте, AlexRK, Вы писали:

ARK>Этот файл не особый. А какой бинарь надо запускать, не понял.
Бинарь который собирет проект build_the_project.cpp компилируется в "средство сборки" которое уже соберает проект. Только так твоя идея имеет теоретический смысл в мире С++.
А как ты хотел? Одной строкой собрать проект?

ARK>Это должно поддерживаться на уровне языка.
Прекрасно, тогда это какой-то императивный язык. И системы сборки такие есть, например QBS.

ARK>Никакие системы сборки не нужны.
И компиляторы? Ну ок, где-то можно жить с Python и JS

ARK>Мало того, такие языки уже есть — Jai от Джонатана Блоу, например.
Давай хелловорлд на нем!

Здравствуйте, Skorodum, Вы писали:

ARK>>Этот файл не особый. А какой бинарь надо запускать, не понял.
S>Бинарь который собирет проект build_the_project.cpp компилируется в "средство сборки" которое уже соберает проект. Только так твоя идея имеет теоретический смысл в мире С++.

Да, надо было изначально сделать оговорку, что я говорил не о С++, а вообще (тема вроде как в language agnostic разделе). Если брать конкретно С++, то "просто так" взять и сделать иначе, разумеется, нельзя — нужна модификация языка и компиляторов.

S>А как ты хотел? Одной строкой собрать проект?

Да, именно так.

ARK>>Это должно поддерживаться на уровне языка.
S>Прекрасно, тогда это какой-то императивный язык. И системы сборки такие есть, например QBS.

Да.

ARK>>Никакие системы сборки не нужны.
S>И компиляторы? Ну ок, где-то можно жить с Python и JS

Компиляторы нужны. Они же должны и сборкой проектов заниматься.

ARK>>Мало того, такие языки уже есть — Jai от Джонатана Блоу, например.
S>Давай хелловорлд на нем!

Вот тут есть какие-то примеры кода, хотя хелловорлда вроде нет: https://github.com/BSVino/JaiPrimer/blob/master/JaiPrimer.md

Здравствуйте, Skorodum, Вы писали:

CC>>Потому C++ под никсами всегда был болью.
S>Боль — это поддерживать сложную сборку под несколько ОС, компиляторов и IDE, но это задача реального мира и за нее хорошо платят

При этом заботливо поддерживаются версии Alpha, Sparc Sun Solaris, Sun OS 68000k, Vax DEC, PDP-10 и прочее давно сдохшее дерьмо.
А на сборку под виндой клали большущий болт.
"Реальный мир", такой реальный.

Да что там винда, меня поразило, что добавленные опции (yes/no) конфига сборки ядра ломают билд. Например в одном из случаев — не хватало точки с запятой в конце строки.
Т.е. эти деятели не только собранное не тестируют (а как тестировать несобираемое ?), но даже сам факт сборки не проверяют.

Также очень веселым оказалось красноглазое решение обернуть gcc в питон-скрипт, который без параметров не делает ничего, а при компиляции файлов сообщает что скоро его задепрекейтят.
Разумеется это сломало kbuild где-то очень глубоко внутри.
Наружу добралось только сообщение "multiple target patterns" (тут ремарка о сверх-информативных сообщениях буханки, которые, ясное дело, не чета виндовым).

Это нормально, это можно. Подумаешь ядро годовой давности не собрать, в том же виде и тем же компилятором.
А вот добавить поддержку отступов пробелами в грёбаных makefile — никак нельзя.
Потому что в парсинг очень трудно это обязательно сломает ОЧЕНЬ НУЖНУЮ УТИЛИТУ 1488 года. Какую и почему — никто не знает. Но сломает — 146%
С — совместимость.

S>В реальном мире МС переходит на линуховые тулзы, а не наоборот (CMake, git)

Бугага.
Это она понторезов мягко к себе переманивает. Ну и обычным людям несколько упрощает жизнь, ковыряться в сплошном и густом unix-way становится попроще.

S>А не надо путать в кучу личные привычки и универсальное удобство
S>Если вам нужна разработка только под МС — так сидите на студийных солюшенах приковынные цепью к одной IDE
S>За возможность сборки на разных платформах/компиляторах/IDE приходиться платить.

Отчётливо запахло мазохизмом.

Здравствуйте, Слава, Вы писали:

С>Я как-то раз искал конверторы для БОЛЬШИХ файлов. Нужно было перегнать кучу данных из dbf в постгрес. Это потом я уже узнал слово ETL и Pentaho Spoon, а тогда я за каким-то хреном стал искать утилиты. Можно было например сделать csv из dbf, но они получались какие-то кривенькие, и постгрес их не импортировал. В ходе сборки разных утилит, make, make install и всё такое, я познакомился с чудесным миром autotools, который до того времени как-то обходил стороной. То там makefile.ac какие-то не те инструкции содержит, то ещё чего, а одна из утилит потребовала для себя gnu lisp, и стала собирать самоё себя через оный лисп, где-то на середине процесса свалившись с ошибкой. Всё делалось на убунте.

что-то делал, решил не разбираться, что-то не заработало... плохой autotools.

С>Теперь вот что. Я писал на ассемблере под дос, резиденты, для собственного интереса. Я писал на си-с-классами, когда ещё не началось победное шествие темплейтов с stl, а были модны т.н. "паттерны проектирования". Я писал на яве, на C#, на FoxPro всяком, на JS, на xslt, на дельфях, на питоне и даже на прологе чуть-чуть. Достаточно много писал на SQL.
С>Но вся эта культура кривоугрёбищных утилит, недоязычков вроде bash/sh, где в условиях if [ надо обязательно пробелы ставить, потому что одмины не умели делать парсеры, где vim ваш умеет только бибикать и всё портить, где на клавиатуре нет курсорных клавиш — она прошла мимо меня. И знакомиться я с ней не желаю, наоборот — я желаю ей смерти, вместе со всеми её носителями.

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

С>Зачастую "программисты-осиляторы" вроде тебя испытывают слабо объяснимое отвращение к SQL. Видите ли, байтиков не видно, выдрачивать нечего. Да ещё и платить надо, за базы-то нормальные. Но именно sql и вообще реляционные базы являются хорошим примером того, как надо делать. Есть некое множество, если полная алгебра действий над объектами. Оно замкнуто, оно работает хорошо. Это правильная автоматизация.

autotools и SQL. сравнение, конечно, божественное.
особенно про байтики понравилось. после упоминания баша-то.

С>А убожество вроде утилит сборки autotools и тому подобного, которое до сих пор иногда не поддерживает пути с \ вместо /, с пробелами в именах, с не-ascii именами — это автоматизация убогая. Не покрывающая полное пространство вариантов использования. Вася чего-то там накодил для его решения, о сука — работает! поделюсь-ка! Нет, вася, надо было тебе, васе, это обратно в глотку засунуть, сразу же, пока оно не распространилось. Или, вася, делай нормально, или вообще никак не делай. Засилие убогих инструментов сдерживает развитие инструментария нормального. Где maven для си? Где nuget хотя бы? Ась? Чому оно такое всё кривое? Почему это вообще надо "осиливать"?

дык мавен же говно. ладно бы ещё sbt какой помянул.. но мавен. фу, отвратительно!
а Вася всё правильно сделал: выбрал максимально универсальный и распространённый вариант.

С>Как я и писал выше в теме, тут нужен интерпол и прокуратура. Чтобы народишко, который любит всякое говно, этим говном не увлекался.

С>Ничего из широко используемых программ не было написано с использованием вот этой всей субкультурки. Ни оракл, ни ms office, ни скайп, ни аська какая-нибудь (я понимаю, что в 2019 году вместо бесплатной аськи предпочтителен платный slack (жрите, жрите, то ли ещё будет в мире SaaS), но массовость была именно у аськи), ни corel draw, ни первый doom со вторым, ни norton commander, ни ещё множество разных программ, которыми люди пользуются в офисах и дома. 95% полезного софта, с чем множество людей буквально выросло рядом, было сделано именно под винду, именно в студии, и именно без кроссплатформенности.

ничего из широко используемых программ не было написано в вижуалке: ни емакс, ни баш, ни перл, ни irssi.

С>Ваш линуксовый восход в РФ начался с нулевых годов и апача (русского) с php. На этом можно было писать сайты, где показывались сиськи. Вот это ваши истоки, "реального мира".

ну да, пока виндовозы пытались поднять кривой IIS, линуксоиды уже запустили и показали миру сиськи.

С>Кстати, расскажите мне, если вы знаете, каким образом собирается ms exchange, и почему именно на нём сидят множество контор, например московских. И почему именно мир, породивший оный exchange, оказался столь успешен, что альтернативщики по сей день не сделали ничего сравнимого. Наверное, до сих пор из vim выход найти не могут. Бесконечный тупик у них.

это легко объяснимо, как и привязка к софту от мелкософта типа вижуалки:
— всё дело в варезе

пока ты воровал софт, вася писал мейкфайлы руками и учился.
прошли года — вася стал успешным, а у кого-то до сих пор ms exchange

С>PS: В какой-то момент гуглам это всё безобразие надоело, и они сделали Golang, который не даёт возможностей для особенного разгула фантазии у разных изобретателей. И go так попёр, что потеснил практически все прочие языки. Хороший язык, палка для битья по рукам там прямо в компилятор встроена.

чего ж тебя тянет-то на гадость? голанг — это очень кастрированная поделка, которую ещё очень и очень сильно поменяют в будущем.

Здравствуйте, neFormal, Вы писали:

F>что-то делал, решил не разбираться, что-то не заработало... плохой autotools.

Вообще-то большая доля правды есть. Скомпилировать софт в произвольном случае (если не из репозитория) — это, да, сделал configure и потом make, а оно чих-пых валится с ошибками компиляции. Обычное дело. В особо клинических случаях еще и сам configure завершается с ошибками (и не по причине отсутствия нужных библиотек). Причем по идее configure как раз и придумали, чтобы автоматически готовить правильный Makefile так, чтобы все что нужно было на выходе.

Здравствуйте, 00011011, Вы писали:

0>Это просто списки файлов (без директорий) которые лежат внутри. Это не исходники. А просто какие-то файлы.

В живых должен остаться только один. (С)

CMakeList.txt — тот самый де-факто уже стандарт.


0>Это не программирование на С++, а черти что.

Это оно и есть.


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

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


0>Я наверное что-то делаю не так. Но у меня идеальный проект — это когда в корневой директории проекта лежит единственный файл проекта, и папки исходников (подпроекты, ресурсы и т.п.). И как правило именно так и получается. Все, никакого мусора. А тут — ну я не знаю что с этим делать.

www.google.com


0>CMakeLists.txt:503 (select_cxx_standard)
0>Зачем мне с этим разбираться?

Потому что три стандарта сменились за относительно короткий срок.
Укажи стандарт явно.


0>Потому что чистые исходники на С/С++, написанные нормальным образом, как правило компилируются.

А иногда по ходу билда нужно сгенерить код.


0>Иногда приходится подправить какие-то мелочи, добавлять библиотеки которых у меня нет — но по крайней мере это все понятно, компилятор ругнется например на "нет такого-то инклуда"

О том, что нет такой-то библиотеки ты узнаешь еще на этапе CMake.


0>и я полезу его искать, найду и в итоге добавлю новую библиотеку в каталог с библиотеками.

Дудки. Там такой же CMake, всё то же самое.
Зато, когда поставишь ту либу с помощью CMake, то оный на целевой программе обнаружит зависимость и пропишет в файле проекта все нужные пути.


0>А то, что комитет по стандартизации должен принудить всех разработчиков компиляторов к тому, чтобы был один единый для всех компиляторов и для всех операционных систем формат файла проекта, с простым и понятным json- или xml-подобным синтаксисом.

При чём тут компилятор?
Например, компилятор C# ничего не знает про MS Build.
Зато CMake знает и умеет генерить в том числе и в MS Build.

Здравствуйте, Слава, Вы писали:

С>Но вся эта культура кривоугрёбищных утилит, недоязычков вроде bash/sh, где в условиях if [ надо обязательно пробелы ставить, потому что одмины не умели делать парсеры, где vim ваш умеет только бибикать и всё портить, где на клавиатуре нет курсорных клавиш — она прошла мимо меня. И знакомиться я с ней не желаю, наоборот — я желаю ей смерти, вместе со всеми её носителями.
ДА!

С>А убожество вроде утилит сборки autotools и тому подобного, которое до сих пор иногда не поддерживает пути с \ вместо /, с пробелами в именах, с не-ascii именами — это автоматизация убогая. Не покрывающая полное пространство вариантов использования. Вася чего-то там накодил для его решения, о сука — работает! поделюсь-ка! Нет, вася, надо было тебе, васе, это обратно в глотку засунуть, сразу же, пока оно не распространилось. Или, вася, делай нормально, или вообще никак не делай. Засилие убогих инструментов сдерживает развитие инструментария нормального. Где maven для си? Где nuget хотя бы? Ась? Чому оно такое всё кривое? Почему это вообще надо "осиливать"?
ДА!!!

Здравствуйте, neFormal, Вы писали:

F>что-то делал, решил не разбираться, что-то не заработало... плохой autotools.
Не дюд, это говно и палки.

F>ничего из широко используемых программ не было написано в вижуалке: ни емакс, ни баш, ни перл, ни irssi.

Здравствуйте, Michael7, Вы писали:

F>>что-то делал, решил не разбираться, что-то не заработало... плохой autotools.
M>Вообще-то большая доля правды есть. Скомпилировать софт в произвольном случае (если не из репозитория) — это, да, сделал configure и потом make, а оно чих-пых валится с ошибками компиляции. Обычное дело. В особо клинических случаях еще и сам configure завершается с ошибками (и не по причине отсутствия нужных библиотек). Причем по идее configure как раз и придумали, чтобы автоматически готовить правильный Makefile так, чтобы все что нужно было на выходе.

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

Здравствуйте, CreatorCray, Вы писали:

F>>что-то делал, решил не разбираться, что-то не заработало... плохой autotools.
CC>Не дюд, это говно и палки.

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

F>>ничего из широко используемых программ не было написано в вижуалке: ни емакс, ни баш, ни перл, ни irssi.
CC>

да, виндовый мирок не единственный на этой планете.

Здравствуйте, B0FEE664, Вы писали:

BFE> AB>Да, у тебя неправильный подход — ты "со своим самоваром приехал в Тулу". У всех остальных <данные> проекты собираются стандартными configure && make.
BFE> Нет. Не собираются.

Скорее всего, ты просто чего-то не умеешь / не знаешь.

Здравствуйте, 00011011, Вы писали:

0>Даже не компиляции, а какая-то мутная ошибка невозможности выполнить Custom Build для файла который нужно обработать программой moc. Опять фигня, не относящаяся к программированию никаким боком.

А я периодически размышляю, нет ли во всех этих развесистых кастом билдах и скриптах какого-нибудь зловреда. Там ведь все равно сам черт ногу сломит, так что теоретически можно хоть слона там запрятать.

Здравствуйте, Michael7, Вы писали:

M>Бесплатные такие тоже есть. Я видел платные очень энтерпрайзные проекты такие, что это вообще кошмар сборщика. Например, часть файлов надо собрать в одной версии Delphi, часть в другой, потом кое-что из результата пропатчить в 16-ричном редакторе и продолжить сборку в еще одной версии Delphi. И все эти манипуляции толком не описаны, являются чуть ли не сакральным знанием.

Ага, я примерно такое на предыдущей работе видел, только под .NET. Проект из репозитория — реально на гигабайты, я только пока закончится чекаут из TFS пару часов дожидался. И он вообще не собирается, с кучей каких-то мутных ошибок. Огромная куча зависимостей от внешних либ, из них многие указаны в конфигах NuGet или проектах с неверной версией, а еще некоторые надо патчить вручную (где, что и как — нигде не написано). Куча развесистых скриптов, которые, естественно, постоянно падают с невнятными ошибками.
И самое забавное — что авторы всего этого чуда техники считали себя неимоверно отличными спецами, круче них только яйца.

Здравствуйте, neFormal, Вы писали:

F>>>что-то делал, решил не разбираться, что-то не заработало... плохой autotools.
CC>>Не дюд, это говно и палки.
F>что было в далёком прошлом, то и работает.
Проблема в том что оно окуклилось и не эволюционирует.

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

Здравствуйте, 00011011, Вы писали:

0>Это типа крика души Для меня самое сложное в программировании это не собственно программирование, а разобраться с тем, как собрать чужие проекты (как правило open-source) скачанные из инета. Да, я понимаю что у меня наверное совершенно неправильный подход, и наверное никто так не делает.

0>Скачиваю какой-то проект, с гитхаба например. Хочу собрать. И что я вижу?
0>Вот например.
0>Это просто списки файлов (без директорий) которые лежат внутри. Это не исходники. А просто какие-то файлы.

В файле .appveyor.yml как раз описано то, что нужно сделать для сборки под VC++

p.s.
тоже не очень нравится когда нужно качать зависимости из разных мест.
я все либы скидываю в один репозитарий, чтобы одним солюшеном собиралось сразу после git clone
https://github.com/pavel-pimenov/flylinkdc-r5xx

тут кстати можешь забрать проект сборки libtorrent
в отличии от того, что генерирует cmake — в нем относительные пути.

Здравствуйте, CreatorCray, Вы писали:

CC>Потому C++ под никсами всегда был болью.
CC>Особенно после полноценной VS.

У виндовз-программистов какое-то извращённое Микрософтом представление о мире. Да, Микрософт сделал довольно неплохую VS под себя. Но подходить к ней надо как к инструменту Микрософт для Микрософт, вещь в себе. При этом на момент создания VS (1997) уже были GNU Make (1976) и даже autotools (1996). А ещё были прямые слэши в файловых путях, но Микрософт сделал всё по-другому.


CC>Да, некоторые люди ездят на личных комфортных машинах в то время как остальные толкаются в переполненной маршрутке.
CC>Вот только непонятно почему маршрутчики считают что это нормально и все должны страдать как они?

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


Кстати тут же опенсорс — ну сделай проект под Студию, выложи в общий доступ.

Здравствуйте, Dair, Вы писали:

D>уже были GNU Make (1976)

говно мамонта, которое за >40 лет так и не научилось поддерживать пробелы в makefile

D>даже autotools (1996).

Смотри:

configure:3396: checking for arm-linux-gnueabi-g++
configure:3426: result: no
...
configure:3440: checking for g++
configure:3456: found /usr/bin/g++
configure:3467: result: g++
configure:3483: WARNING: using cross tools not prefixed with host triplet

И потом всё обычным g++ компилит.
У меня g++ для арма не стоял, только gcc.
А тупой автоконф обладает искусственным интеллектом: пытаетcя откомпилить всем подряд, чем-то вроде компилится и похер, что вообще другая архитектура.


D>А ещё были прямые слэши в файловых путях, но Микрософт сделал всё по-другому.

Обратные слеши — наследие CP/M (1974), и она тогда была гоооораздо популярнее чем эти ваши юниксы.

Если бы не аутисты, полюбившие залипать на бегущие в Unix консоли строчки — всё могло сложиться совсем по-другому

Здравствуйте, PPA, Вы писали:

PPA>тоже не очень нравится когда нужно качать зависимости из разных мест.
PPA>я все либы скидываю в один репозитарий, чтобы одним солюшеном собиралось сразу после git clone
Используй тогда уж сабмодули, чтобы не терять историю зависимостей.

Здравствуйте, Слава, Вы писали:

С>Но вся эта культура кривоугрёбищных утилит, недоязычков вроде bash/sh, где в условиях if [ надо обязательно пробелы ставить, потому что одмины не умели делать парсеры, где vim ваш умеет только бибикать и всё портить, где на клавиатуре нет курсорных клавиш — она прошла мимо меня.
Зато культуру убогого CMD ты впитал по полной

С>И знакомиться я с ней не желаю, наоборот — я желаю ей смерти, вместе со всеми её носителями.
Учиться в возрасте тяжело. Сочувтвую

С>Зачастую "программисты-осиляторы" вроде тебя испытывают слабо объяснимое отвращение к SQL.
Зачастую "программисты-НИосиляторы" вроде тебя испытывают слабо объяснимое отвращение к SQL...

С>Видите ли, байтиков не видно, выдрачивать нечего. Да ещё и платить надо, за базы-то нормальные. Но именно sql и вообще реляционные базы являются хорошим примером того, как надо делать. Есть некое множество, если полная алгебра действий над объектами. Оно замкнуто, оно работает хорошо. Это правильная автоматизация.
В мире "осиляторов" есть PostgreSQL и MySQL которые собираются autotools и CMake и имеют прекрасную командную строку

С>А убожество вроде утилит сборки autotools и тому подобного, которое до сих пор иногда не поддерживает пути с \ вместо /, с пробелами в именах, с не-ascii именами — это автоматизация убогая. Не покрывающая полное пространство вариантов использования.
Ну так особо одаренные зачем-то стали использовать "\".

С>Вася чего-то там накодил для его решения, о сука — работает! поделюсь-ка! Нет, вася, надо было тебе, васе, это обратно в глотку засунуть, сразу же, пока оно не распространилось. Или, вася, делай нормально, или вообще никак не делай. Засилие убогих инструментов сдерживает развитие инструментария нормального.
Это про МС, их компилятор, командную строку, остутсвие пакетного менеджера и т.д. Ну сейчас они стали немного исправляться.

С>Где maven для си?
Ест CMake, есть meson, QBS.

С>Где nuget хотя бы? Ась? Чому оно такое всё кривое?
Где в вашем виндовом мире sudo apt install?

С>Почему это вообще надо "осиливать"?
Решает задачу и за это платят

С>Как я и писал выше в теме, тут нужен интерпол и прокуратура. Чтобы народишко, который любит всякое говно, этим говном не увлекался.
Это про проекты основанные на Студийных солюшенах?

С>Ничего из широко используемых программ не было написано с использованием вот этой всей субкультурки.
И далее он пишет про Го

С>Ни оракл, ни ms office, ни скайп, ни аська какая-нибудь (я понимаю, что в 2019 году вместо бесплатной аськи предпочтителен платный slack (жрите, жрите, то ли ещё будет в мире SaaS), но массовость была именно у аськи), ни corel draw, ни первый doom со вторым, ни norton commander, ни ещё множество разных программ, которыми люди пользуются в офисах и дома. 95% полезного софта, с чем множество людей буквально выросло рядом, было сделано именно под винду, именно в студии, и именно без кроссплатформенности.
Ты это в каком браузеры пишешь? ИнтернетЭксполорер 6.0?

С>Ваш линуксовый восход в РФ начался с нулевых годов и апача (русского) с php. На этом можно было писать сайты, где показывались сиськи. Вот это ваши истоки, "реального мира".
Ваша винда в РФ началась с пиратства

С>Кстати, расскажите мне, если вы знаете, каким образом собирается ms exchange, и почему именно на нём сидят множество контор, например московских. И почему именно мир, породивший оный exchange, оказался столь успешен, что альтернативщики по сей день не сделали ничего сравнимого. Наверное, до сих пор из vim выход найти не могут. Бесконечный тупик у них.
Кстати, расскажите мне, если вы знаете, в какой системе контроля версий храняться исходники МС? И почему имеено гитом пользуется весь мир? Почему имено мир, породивший оный гит оказался столь успешен, что альтернативщики по сей день не сделали ничего сравнимого. Наверное, до сих пор со студией мучаются. Бесконечный тупик у них.

С>PS: В какой-то момент гуглам это всё безобразие надоело, и они сделали Golang, который не даёт возможностей для особенного разгула фантазии у разных изобретателей. И go так попёр, что потеснил практически все прочие языки. Хороший язык, палка для битья по рукам там прямо в компилятор встроена.
Хороший язык, прямо из "осиляторной тусовки"