Это уже оффтоп, но использование автомобилей очень часто неоправдано и дейстивтельно только убивает людей. Наличие автомобиля не означает, что надо ездить везде и всегда только на нём, в большинстве случаев общественный транспорт лучше для всех. С IDE - то же самое, это далеко не такая универсальная и удобная вещь. Перефразирую исходный коммент в аналогию с автомобилями, почувствуйте абсурдность:
Есть много странных людей, которые будут использовать что угодно, от трамваев из позапрошлого века до аж велосипедов, лишь бы не ехать на автомобиле.
А что там прикидывать? В бесонечности, это значительно выше второй космической. Плохо представляю, что это за цифра - 15, может это были тысячи миль в час? Всё равно не подходит, но уже ближе.
Вы меня совершенно не поняли. Я не предлагаю отказаться от CMake и вернуться к баш скриптам. Я сам стараюсь им пользоваться и делать так, чтобы cmake --build собирал всё, на всех платформах и не требовал ничего. Мой тезис в том, что это может оказаться настолько дорого, что не будет иметь никакого практического смысла.
С очень большой вероятностью в нестандатной сборке буста не будет смысла
Я не про использование буста, я про разработку самого буста. И он такой не один, возьмите достаточно старый живой проект и там не будет CMake. Первое, что приходит в голову кроме буста - GCC. Кто-то смог и перешёл, а кто-то ещё использует autotools или ручной make, например.
Типа.. где-то же он компилируется, почему он локально то не может скомпилироваться?
Оно компилируется и работает только под линуксом. За кроссплатформенность никто платить не готов, да и даже она не решает задачу дебага на конкретной платформе. Разработчики тоже не готовы сидеть под линуксом, и даже в этом случае десктопный будет отличаться от серверного и будет сборка в контейнере без иксов и красивой IDE. Ваш выбор в этой ситуации - vim, который с плагинами хотя бы видит правильные инклюды, или IDE на хосте, которая не будет видеть вообще ничего. Ну и прямо сейчас - VS Code с Remote плагином, но это фактически запуск IDE на удалённом хосте.
Не все проекты не на ультра современных технологиях надо выбрасывать. Нестандартным образом собирается, например, boost. Выкидываем?
Вы описали CI\CD сейчас. Опять же не понятно, причем тут вим.
Вы никогда не разрабатывали проект, который локально у вас вообще не имеет шансов на компиляцию? Локально у разработчика винда или мак, на сервере линукс, сервис работает под линуксом. Локально вы даже хэдеры не притащите.
Ни разу за 10 лет карьеры не сдвигал код на один пробел
Это не значит, что это никому не нужно. Стандарты форматирования разные бывают, далеко не всё можно объяснить clang-format пока что.
Греп я практически не использую в работе
Я вот использую и часто. И скорость получения результата по сравнению с контекстным поиском несравнима. Да, это секунды и не влияет на продуктивность, но это очень влияет на настроение и желание пользоваться инструментом.
Если для сборки проекта надо сделать больше, чем кнопка Build - это плохо собираемый проект.
Последний пункт зацикливается на первый, что делать-то с такими проектами? Они важны и нужны. Переписывать всё на CMake? Занимался я таким и не мало - дело долгое и не благодарное, потому что продуктивность разработчиков от этого не меняется. Разве что скорость вхождение новичка повышается.
у нас все собирается за 1 кнопку, всем контора покупает вижуал студию
Это личный опыт. У меня он противоположный, я прешёл в большую контору с вижуал студией и скучаю по временам перловых скриптов сборки. Их я мог прочитать и переделать инструментарий так, как мне удобно, выбрать IDE или редактор, который я могу настроить удобно, а сейчас я этого лишён.
sublime и notepad++ это и есть текстовые редакторы, это не IDE.
IDE сама ничего собирать не умеет
В случае MS VS это ещё какой сборщик и компилятор. С настройками не в конфиг файлах и скриптах сборки, а в интерфейсе. Именно IDE позволяют полностью оторваться от компилятора и понажимав кнопочки мышкой создать и собрать проект, не имея представления о том, как это работает. Это уже скорее проблема обучения программированию, а не работы, но всё равно вызывает дискомфорт. За это я люблю VS Code, она вроде как и IDE, но фактически редактор, который запускает понятные скрипты и не делает ничего неявно.
Не надо считать странными всех, с чьими проблемами вы лично не сталкивались. Я вдиел нескольк действительно большимих проблем в использовании IDE
1) Кастомные скрипты сборки, подгрузки ресурсов, зависимостей, тестирования и тд и тп. Когда perl грузит модули, python собирает ресурсы, а bash перекладывает инклюды туда, где их увидит компилятор. Большинство IDE превращаются в тыкву в такой ситуации, не могут найти исходников, не видят реальных флагов компиляции и начинают подчёркивать всё, деградируя до тупого и очень визуально шумного текстового редактора. Подружить старый проект с такими скриптами с IDE - трудоёмкая задача с сомнительной пользой.
2) Удалённая разработка. Vim на сервере работает по ssh, можно вести разработку на монстр-сервере с терабайтом памяти и 64 ядрами, что очень сильно ускоряет компиляцию, упрощает разворачивание общей для разработчиков среды и тд. Кроме того на продуктовом сервере можно иметь привычное окружение разработчика, чтобы дебажить наживую. Да, VS Code сейчас позволяет делать что-то похожее, но это появилось недавно на фоне C++.
3) Топорность и скромный функционал по работе с текстом. Мультикурсоры, редактирование всех вхождений, да банальный сдвиг блока кода не на 1 таб, а на 1 пробел - тривиальные задачи для вимеров и сложные в большинстве IDE.
4) Тяжеловесность IDE и тормоза даже на современных компах. Любимый текстовый редактор открывается за миллисекунды и готов к работе. IDE лагают на простых операциях, как текстовый поиск - сравните с тем же grep на большом проекте.
5) Погуржённость в инструментарий. Если вы пишите в редактори и с консольки собираете проект, то скорее всего вы понимаете, как он собирается или можете открыть скрипт сборки и прочитать. Что и когда делает IDE - чёрный ящик, залезть в который гораздо сложнее.
Я пока со всем этим не столкнулся, тоже не понимал, что это они в каменном веке сидят. А когда потратил дни на то, чтобы всё же внедрить умную IDE, понял, что часто оно того не стоит. Я почти познал дзен с VS Code, но сейчас работаю на проекте, где только большая VS и солюшн только под него - это ад: тормоза при функционале меньшем, чем в VS Code.
Не то чтобы совсем не решает, но лучше выглядит для тех, для которых SFINAE изначально придумывали. То есть простой разбор перегрузок без замороченных отличий по особенностям типов и enable_if. Например, перегрузки функции, обрабатывающей список значений, vector и map шаблонного типа. Гораздо проще написать 3 шаблонных функции-перегрузки с list, vector и map в сигнатуре, чем писать концепт is_list, is_vector, is_map.
А вот все использования enable_if и подобного уровня хаки концепты однозначно решают лучше.
Суть в том, что на удалённом хосте поднимается VS Code без графики, к ней коннектится тот инстанс, что запущен локально. Соответственно рисуется всё локально и нативно для клиента, в разы эффективнее XServer. Это для коннекта к хорошему серверу, который будет тянуть подсказщик, сборку и тд, в то время как на клиенте почти ничего не требуется. Да, такое можно сделать и без браузрености и электронов, но с ним это оказалось просто реализуемо, поэтому и сделали.
Я понимаю, что электрон и браузер, но из тех IDE, которыми я пользовался VS Code - самая легковесная и шустрая. Vim не в счёт. "Нативная" большая студия в разы тормознее. Да, теоретически можно было бы сделать такую же крутую IDE без тормозов, но на практике неосуществимо. Плюс браузреность дала возможность сделать удалённую разработку по SSH очень удобной. Огромной коллекции плагинов тоже не было бы. На скромном ноуте с 4 GB ram code чувствует себя нормально, компиляция жрёт куда больше, так что я бы не называл её расточительной, особенно на фоне всех остальных вариантов.
Соотношение и матовость - его основные плюсы. Долго сидел на 1920*1200 - очень удобно, хотел бы то же самое с разрешением повыше. Этот близко к идеалу, но да, лучше бы 27" и 120Гц.
SFINAE никуда не денется, он всё ещё используется и работает. Концепты не полностью заменяют, а решают 90% задач коротко и просто. Точно так же constexpr не решает все задачи шаблонов, только выделяет популярное подмножество и предлагает понятный способ решения.
Простите, а это в каком году написано? Наезжать на инклюды и SFINAE после выхода C++20 странно. Я понимаю, что не все проекты могут себе позволить перейти на него, сам на 17м сижу, но это же не претензия к развитию языка.
Расширения обсуждались, только не в таком виде, а как унифицированный синтаксис вызова функций и методов, когда this уходит первым аргументом, как в D, но не пошло, а жаль.
Ну а properties бесплатные только когда инлайнятся, а если хочется бинарной совместимости, то нужен честный вызов метода, что не так уж дёшево.
Буду токиском, но зачем? Зачем люди продолжают делать свои IDE при том, что они примитивнее всего существующего? Чем эта красная панда лучше VS Code с clangd в виде плагина? Или QtCreator? Я понимаю, что CLion или VS может не нравится своей монструозностью и требованиями, но сейчас через LSP clangd можно к любому калькулятору подключить.
И C++03, C++11 и C++20 — это три сильно разных языка с сильно разными парадигмами и стилями написания кода.
Эти изменения ничтожно малы по сравнению с базовыми знаниями C++. Если хорошо пишете на C++11, вам понадобится несколько месяцев, чтобы перейти на хороший уровень C++20, а изучить даже C++03 с ноля это не один год практики. Никакие концепты 20-го стандерта не меняют сложность и глубину SFINAE. Внешне язык может и поменялся сильно, но база под ним огромна и почти неизменна.
Точно так же изучение нового языка программирования в разы проще, чем обучение программированию с ноля (если речь не про совсем экзотику). Инженерные и математические знания это не про ГОСТ и диаметр болтов, который может поменяться, а про умение выстраивать логические цепочки, знание законов математики и физики, которые не менялись и не поменяются никогда.
Сейчас токсичностью называют уже банальную прямоту и честность. Если я сделал работу плохо, то я хочу услышать на ревью честную оценку, что я налажал. И да, не все такие из себя правильные, могут и матом покрыть - это ок, повод учиться и улучшать свою работу, а не жаловаться на токсичность. Главное, чтобы этоносилось к работе, а не личности. Конкруентность и демонстрация максимума своих возможностей - отличная среда для развития всех членов колектива. П@х, что токсичная, зато мотивирующая. This is Sparta!
Автобус проезжает около 200 км в сутки. То есть ночная зарядка это хорошо если 1/5 от суточного потребления, всё остальное - высокие пики в строго нужный момент времени. Автобусы не стоят на конечной в ожидании дешёвого электричества, им надо зарядиться так быстро, как возможно, и ехать дальше. Электробусы и так тормознуты и требуют больше водителей и техники, нет там манёвра по времени для управления нагрузкой.
Пункт про электробусы скорее фантастический, чем реальный. Запас хода московсикх электробусов около 40км, а в реальных условиях и того ниже. Это запас на один рейс, а не день. Вся их система выстроена не на ночную зарядку, а на постоянную дозарядку на конечных, поэтому балансировать не выйдет. А делать аккумуляторы на весь день дорого и технически сложно, хотя и возможно.
Это уже оффтоп, но использование автомобилей очень часто неоправдано и дейстивтельно только убивает людей. Наличие автомобиля не означает, что надо ездить везде и всегда только на нём, в большинстве случаев общественный транспорт лучше для всех. С IDE - то же самое, это далеко не такая универсальная и удобная вещь. Перефразирую исходный коммент в аналогию с автомобилями, почувствуйте абсурдность:
Есть много странных людей, которые будут использовать что угодно, от трамваев из позапрошлого века до аж велосипедов, лишь бы не ехать на автомобиле.
А что там прикидывать? В бесонечности, это значительно выше второй космической. Плохо представляю, что это за цифра - 15, может это были тысячи миль в час? Всё равно не подходит, но уже ближе.
Вы меня совершенно не поняли. Я не предлагаю отказаться от CMake и вернуться к баш скриптам. Я сам стараюсь им пользоваться и делать так, чтобы cmake --build собирал всё, на всех платформах и не требовал ничего. Мой тезис в том, что это может оказаться настолько дорого, что не будет иметь никакого практического смысла.
Я не про использование буста, я про разработку самого буста. И он такой не один, возьмите достаточно старый живой проект и там не будет CMake. Первое, что приходит в голову кроме буста - GCC. Кто-то смог и перешёл, а кто-то ещё использует autotools или ручной make, например.
Оно компилируется и работает только под линуксом. За кроссплатформенность никто платить не готов, да и даже она не решает задачу дебага на конкретной платформе. Разработчики тоже не готовы сидеть под линуксом, и даже в этом случае десктопный будет отличаться от серверного и будет сборка в контейнере без иксов и красивой IDE. Ваш выбор в этой ситуации - vim, который с плагинами хотя бы видит правильные инклюды, или IDE на хосте, которая не будет видеть вообще ничего. Ну и прямо сейчас - VS Code с Remote плагином, но это фактически запуск IDE на удалённом хосте.
Не все проекты не на ультра современных технологиях надо выбрасывать. Нестандартным образом собирается, например, boost. Выкидываем?
Вы никогда не разрабатывали проект, который локально у вас вообще не имеет шансов на компиляцию? Локально у разработчика винда или мак, на сервере линукс, сервис работает под линуксом. Локально вы даже хэдеры не притащите.
Это не значит, что это никому не нужно. Стандарты форматирования разные бывают, далеко не всё можно объяснить clang-format пока что.
Я вот использую и часто. И скорость получения результата по сравнению с контекстным поиском несравнима. Да, это секунды и не влияет на продуктивность, но это очень влияет на настроение и желание пользоваться инструментом.
Последний пункт зацикливается на первый, что делать-то с такими проектами? Они важны и нужны. Переписывать всё на CMake? Занимался я таким и не мало - дело долгое и не благодарное, потому что продуктивность разработчиков от этого не меняется. Разве что скорость вхождение новичка повышается.
Это личный опыт. У меня он противоположный, я прешёл в большую контору с вижуал студией и скучаю по временам перловых скриптов сборки. Их я мог прочитать и переделать инструментарий так, как мне удобно, выбрать IDE или редактор, который я могу настроить удобно, а сейчас я этого лишён.
sublime и notepad++ это и есть текстовые редакторы, это не IDE.
В случае MS VS это ещё какой сборщик и компилятор. С настройками не в конфиг файлах и скриптах сборки, а в интерфейсе. Именно IDE позволяют полностью оторваться от компилятора и понажимав кнопочки мышкой создать и собрать проект, не имея представления о том, как это работает. Это уже скорее проблема обучения программированию, а не работы, но всё равно вызывает дискомфорт. За это я люблю VS Code, она вроде как и IDE, но фактически редактор, который запускает понятные скрипты и не делает ничего неявно.
Не надо считать странными всех, с чьими проблемами вы лично не сталкивались. Я вдиел нескольк действительно большимих проблем в использовании IDE
1) Кастомные скрипты сборки, подгрузки ресурсов, зависимостей, тестирования и тд и тп. Когда perl грузит модули, python собирает ресурсы, а bash перекладывает инклюды туда, где их увидит компилятор. Большинство IDE превращаются в тыкву в такой ситуации, не могут найти исходников, не видят реальных флагов компиляции и начинают подчёркивать всё, деградируя до тупого и очень визуально шумного текстового редактора. Подружить старый проект с такими скриптами с IDE - трудоёмкая задача с сомнительной пользой.
2) Удалённая разработка. Vim на сервере работает по ssh, можно вести разработку на монстр-сервере с терабайтом памяти и 64 ядрами, что очень сильно ускоряет компиляцию, упрощает разворачивание общей для разработчиков среды и тд. Кроме того на продуктовом сервере можно иметь привычное окружение разработчика, чтобы дебажить наживую. Да, VS Code сейчас позволяет делать что-то похожее, но это появилось недавно на фоне C++.
3) Топорность и скромный функционал по работе с текстом. Мультикурсоры, редактирование всех вхождений, да банальный сдвиг блока кода не на 1 таб, а на 1 пробел - тривиальные задачи для вимеров и сложные в большинстве IDE.
4) Тяжеловесность IDE и тормоза даже на современных компах. Любимый текстовый редактор открывается за миллисекунды и готов к работе. IDE лагают на простых операциях, как текстовый поиск - сравните с тем же grep на большом проекте.
5) Погуржённость в инструментарий. Если вы пишите в редактори и с консольки собираете проект, то скорее всего вы понимаете, как он собирается или можете открыть скрипт сборки и прочитать. Что и когда делает IDE - чёрный ящик, залезть в который гораздо сложнее.
Я пока со всем этим не столкнулся, тоже не понимал, что это они в каменном веке сидят. А когда потратил дни на то, чтобы всё же внедрить умную IDE, понял, что часто оно того не стоит. Я почти познал дзен с VS Code, но сейчас работаю на проекте, где только большая VS и солюшн только под него - это ад: тормоза при функционале меньшем, чем в VS Code.
Не то чтобы совсем не решает, но лучше выглядит для тех, для которых SFINAE изначально придумывали. То есть простой разбор перегрузок без замороченных отличий по особенностям типов и enable_if. Например, перегрузки функции, обрабатывающей список значений, vector и map шаблонного типа. Гораздо проще написать 3 шаблонных функции-перегрузки с list, vector и map в сигнатуре, чем писать концепт is_list, is_vector, is_map.
А вот все использования enable_if и подобного уровня хаки концепты однозначно решают лучше.
https://code.visualstudio.com/docs/remote/remote-overview
Суть в том, что на удалённом хосте поднимается VS Code без графики, к ней коннектится тот инстанс, что запущен локально. Соответственно рисуется всё локально и нативно для клиента, в разы эффективнее XServer. Это для коннекта к хорошему серверу, который будет тянуть подсказщик, сборку и тд, в то время как на клиенте почти ничего не требуется. Да, такое можно сделать и без браузрености и электронов, но с ним это оказалось просто реализуемо, поэтому и сделали.
Я понимаю, что электрон и браузер, но из тех IDE, которыми я пользовался VS Code - самая легковесная и шустрая. Vim не в счёт. "Нативная" большая студия в разы тормознее. Да, теоретически можно было бы сделать такую же крутую IDE без тормозов, но на практике неосуществимо. Плюс браузреность дала возможность сделать удалённую разработку по SSH очень удобной. Огромной коллекции плагинов тоже не было бы. На скромном ноуте с 4 GB ram code чувствует себя нормально, компиляция жрёт куда больше, так что я бы не называл её расточительной, особенно на фоне всех остальных вариантов.
Соотношение и матовость - его основные плюсы. Долго сидел на 1920*1200 - очень удобно, хотел бы то же самое с разрешением повыше. Этот близко к идеалу, но да, лучше бы 27" и 120Гц.
SFINAE никуда не денется, он всё ещё используется и работает. Концепты не полностью заменяют, а решают 90% задач коротко и просто. Точно так же constexpr не решает все задачи шаблонов, только выделяет популярное подмножество и предлагает понятный способ решения.
Есть уже 10 лет как. Пользовательские литералы объявлены в стандартной библиотеке и "abrakadabra"s это std::string, если есть соответствующий using.
https://en.cppreference.com/w/cpp/string/basic_string/operator""s
Простите, а это в каком году написано? Наезжать на инклюды и SFINAE после выхода C++20 странно. Я понимаю, что не все проекты могут себе позволить перейти на него, сам на 17м сижу, но это же не претензия к развитию языка.
Расширения обсуждались, только не в таком виде, а как унифицированный синтаксис вызова функций и методов, когда this уходит первым аргументом, как в D, но не пошло, а жаль.
Ну а properties бесплатные только когда инлайнятся, а если хочется бинарной совместимости, то нужен честный вызов метода, что не так уж дёшево.
Буду токиском, но зачем? Зачем люди продолжают делать свои IDE при том, что они примитивнее всего существующего? Чем эта красная панда лучше VS Code с clangd в виде плагина? Или QtCreator? Я понимаю, что CLion или VS может не нравится своей монструозностью и требованиями, но сейчас через LSP clangd можно к любому калькулятору подключить.
Эти изменения ничтожно малы по сравнению с базовыми знаниями C++. Если хорошо пишете на C++11, вам понадобится несколько месяцев, чтобы перейти на хороший уровень C++20, а изучить даже C++03 с ноля это не один год практики. Никакие концепты 20-го стандерта не меняют сложность и глубину SFINAE. Внешне язык может и поменялся сильно, но база под ним огромна и почти неизменна.
Точно так же изучение нового языка программирования в разы проще, чем обучение программированию с ноля (если речь не про совсем экзотику). Инженерные и математические знания это не про ГОСТ и диаметр болтов, который может поменяться, а про умение выстраивать логические цепочки, знание законов математики и физики, которые не менялись и не поменяются никогда.
Подгонкой определения. Было бы не круглое, взяли бы совершенно другое основание: расстояние до луны, радиус земли, радиус солнца и тд, и тп.
Сейчас токсичностью называют уже банальную прямоту и честность. Если я сделал работу плохо, то я хочу услышать на ревью честную оценку, что я налажал. И да, не все такие из себя правильные, могут и матом покрыть - это ок, повод учиться и улучшать свою работу, а не жаловаться на токсичность. Главное, чтобы этоносилось к работе, а не личности. Конкруентность и демонстрация максимума своих возможностей - отличная среда для развития всех членов колектива. П@х, что токсичная, зато мотивирующая. This is Sparta!
Автобус проезжает около 200 км в сутки. То есть ночная зарядка это хорошо если 1/5 от суточного потребления, всё остальное - высокие пики в строго нужный момент времени. Автобусы не стоят на конечной в ожидании дешёвого электричества, им надо зарядиться так быстро, как возможно, и ехать дальше. Электробусы и так тормознуты и требуют больше водителей и техники, нет там манёвра по времени для управления нагрузкой.
Пункт про электробусы скорее фантастический, чем реальный. Запас хода московсикх электробусов около 40км, а в реальных условиях и того ниже. Это запас на один рейс, а не день. Вся их система выстроена не на ночную зарядку, а на постоянную дозарядку на конечных, поэтому балансировать не выйдет. А делать аккумуляторы на весь день дорого и технически сложно, хотя и возможно.