Кто как борется с фактическим отсутствием приватных объявлений в C++?

Иногда возникает ощущение, что они из одной и той же книжки черпают вдохновение — в общем-то, на самом деле так оно и есть.

Это какая же? Неужели Страуструп? Лично я его так и не осилил, только несколько глав (в отличие от K&R) — видимо я ненастоящий крестовик :)

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

Ничего, в соседнем треде уже занялись юнионы в C++

Как следствие множество Implementation-defined behaviour, Undefined behaviour и Unspecified behaviour. И да, это все разные вещи!

Проблема преувеличена, best practices (кому их не хватает - линтеры) никто не отменял. Но признаю, что есть более строго бьющие по рукам языки.

Реализации языка используют архаичный сишный тулчейн для сборки. Все так или иначе упирается в Makefile или его аналог, который компилирует .cpp файлы в объектные, а затем их линкует между собой

Ты что ли про отсутствие модулей? Или в чём архаичность? Makefile — вообще прекрасная вещь, не понимаю претензий. Ну если надо скорости, берите ninja

И самое смешное, что это все нестандартное, даже близко, каждый натурально дрочит как он хочет

А ты из тех, кто стремится всё максимально унифицировать? А как же «пусть расцветают сто цветов...»? Разнообразие систем сборок — это плюс, а не минус. Каждый проект или команда выбирает удобную им.

фактически копипастить код для каждого T — еще одна гениальная придумка плюсовиков, но я обещал уложиться в два пункта!

Что работает лучше мономорфизации в контексте системных «zero-cost» задач?

Я хаю вас, слепых защитников своего любимого инструментика.

Кого вас? Я один здесь (с)

Один костыль логически обосновывает другой, и так по кругу, концов не найти.

Напомни, это свойство в математике называется «полнота» или «непротиворечивость»?

Это 5!

Всё так, тут оратор выше мне в одном из прошлых крестосрачей пытался рассказать, что у C++ самый быстрый компилятор в индустрии. Хотя де-факто медлененее компилятор разве что у Rust, и то только потому, что его писали крестовики, которые в упор отказывались видеть проблемы в двухчасовой перекомпиляции проекта, потому что «ничего страшного, мы параллельно будем заниматься другой веткой».

Назови мне системный язык, не уступающий возможностям С++ и Rust, при этом позволяющий компилировать кодовые базы сравнимой сложности намного быстрее? Правда интересно =)

Во-вторых, прочитайте Design And Evolution of C++. Хотя бы

Что нового я должен был там увидеть? Из того, что я прочитал, он точно так же продает фичи и их историю, как это делал всегда, и очевидно провальные даже для 1975 года решения Страуструп разглядывая в упор называет преимуществами даже в 80-90-е. Это манагер-продажник, весьма успешный, но это не программист-архитектор. В свое время в институте я не одного такого сказочника видывал, но всех их объединяет та же нулевая прикладная польза. Один из этих сказочников должен оказываться особенным потому, что ему поверило руководство AT&T? Однако, нынче ему не верят многие. и не только я.

И это твой аргумент? Блин. Да ты сам как фанатик себя ведешь

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

Заголовочные файлы — это одна из самых ненавистных фич крестов, хотя многие не формулируют так дословно свое отношение. Голосование в треде Опрос: Три-пять лучших фич C++ показало, что очень много людей хотят нормальные модули и неймспейсы.

Менее очевидный факт — вся легендарная медленность компиляции C++ вызвана заголовками и только ими. Ведь ясен пень, что это не десять строчек кода компилируется две секунды, а включенные этим файлом заголовки снова и снова распаршиваются компилятором вхолостую — а не делать этого компилятор не может, поскольку нормальных модулей с четкими зависимостями в крестах нету. Еще менее очевидный факт: раздельная компиляция является одним из усугубляющий факторов, замедляющий компиляцию, а наиболее быстрые системы компиляции крестов используют именно цельную компиляцию, избегая таким образом многократные повторные парсинги-комиляции.

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

Вот берешь ты либу и сразу по клику на функции/классе попадаешь в ее объявление - по моему супер удобно. Не нужно сразу в доки лезть. Можно быстро оценить интерфейс класса, посмотреть, кто от кого наследуется и т.д

«А где тут шморгалка?»

Заголовочные файлы не имеют никакого отношения к удобству обзора кода, в индустрии были десятки альтернативных способов организации интерфейсов разработки, и заголовки среди них являются не самым лучшим вариантом, мягко говоря. И особенно сильно мешает понимать код наследование — это настолько очевидно всем, кроме упоротых фанатов крестов, что нынче уже наследования нет в тех же Rust и Go, и никто не собирается это наследование туда добавлять.

(Я не программист, но) ccache? Модульная архитектура?

Здесь правильно заметили, что случай не терминальный, на бустах у людей бывает и хуже. «Модульная архитектура» — это такой абстрактный конь, что сложно отвечать на это.

Это какая же? Неужели Страуструп? Лично я его так и не осилил, только несколько глав (в отличие от K&R) — видимо я ненастоящий крестовик

Видимо ненастоящий. Я тебя не помню, то ли мало общались, то ли настолько ненастоящий крестовик, что совсем мне не интересен.

Проблема преувеличена, best practices (кому их не хватает - линтеры) никто не отменял. Но признаю, что есть более строго бьющие по рукам языки

Проблема все-таки актуальна в том плане, что кто ж знает эти best practice? Ну вот я знаю, что в гугле пытаются по ним писать, и то только «пытаются», потому что влияние популярных подходов слишком уж велико, потому что в этом стиле уже написаны всякие там кути и бусты, население просто бездумно копирует патологичные паттерны, интерес к которым еще больше подогревается в книжках.

Ты что ли про отсутствие модулей? Или в чём архаичность? Makefile — вообще прекрасная вещь, не понимаю претензий. Ну если надо скорости, берите ninja

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

Разнообразие систем сборок — это плюс, а не минус. Каждый проект или команда выбирает удобную им.

Я бы поправил на «каждый выбирает наименее неудобную им».

Что работает лучше мономорфизации в контексте системных «zero-cost» задач?

Внезапно, раздвушийся до безобразия код перестает влезать в кэш и может даже работать медленнее полиморфичного (не путать с vtable). Я считаю ручной инлайн неудачным с технической стороны решением Страуструпа. Не провальным, но неудачным. Зато успешным с маркетинговой стороны, поскольку появилось толпы оптимизаторов, которые думают, что этим «уникальным инструментом» «оптимизируют код» через шаблоны и инлайны, забывая бенчмаркать фактическую производительность своего кода.

Назови мне системный язык, не уступающий возможностям С++ и Rust, при этом позволяющий компилировать кодовые базы сравнимой сложности намного быстрее? Правда интересно

Это намного более глубокий вопрос, чем ты изначально думал, когда его задавал. Ну типа ты смотришь на 90-е/начало нулевых, которое сформировались под гнетом C++ и Java, и говоришь мне «вот видишь, миллионы мух не могли ошибаться, по другому быть не могло». Но именно в те годы как раз по другому быть могло, можно было бы выбрать иное будущее. Просто не нашлось такого локомотива, который бы вытащил более адекватное решение — потому что, внезапно, всем пофик, все зарабатывают денежку, а не занимаются изысканиями на благо индустрии в целом. Сейчас и вовсе идет тенденция к снижению качества и наращиванию эффективной стоимости эксплуатации — не только в IT, а вообще в куче отраслей. Бизнесу не нужна эффективность, потому что она дает мало прибыли. Много прибыли дает трудоемкая работа. Например, крутить провода в Нью-Йоркском метро — без шуток, это одна из самых доходных должностей в штатах по соотношению «доходы-затраты».

Если посмотреть, на чем взлетел C++, то это будут тупо GUI, то есть, всякие там офисные софтины, игори, CAD/CAM. Если прямо отвечать на вопрос для этой ниши, то это паскаль: 100-200 тыс строк в секунду — это нормальная такая скорость компиляции для паскаля. Другое дело, что 1 к 1 сравнивать эти языки нельзя. Первая и основная претензия заключается в том, что кодовые базы «сравнимой сложности» не должны быть писаны на «системном языке» — такой подход и является тяжелым наследием крестов, давшем нам кучу глючных монстров, которые вроде как можно написать на крестах, но лучше этого никогда не делать изначально.

Альтернативы для GUI начали развиваться в районе середины-конца нулевых (WPF, UWP, JavaFX), но этот процесс произошел слишком поздно и слишком медленно, и по итогу веб сожрал всех раньше, чем смогли оформиться более адекватные альтернативы. С другой стороны, индустрия поубегала с C++/Rust на Node.js/Go/Python, чтобы, опять-таки, не «компилировать кодовые базы сравнимой сложности», а использовать уровни абстракции, и таким образом получать предсказуемые сроки реализации и гарантии стабильности, а не как это было в крестах, когда PM-у приходилось каждый день ставить свечки иконе и засыпать с валидолом — потому что иначе он никак не мог получить гарантии сроков сдачи проекта. Некоторые возмущаются «почему это игра вылетает иногда?». После чтения сорцов X-Ray (сталкер) у меня возник вопрос «это вообще могло работать?». Причем, я слышал от игроделов аналогичные отзывы. И ситуация поменялась в заметно лучшую сторону, когда игры начали писать в Unity на C#. И да, компилируется код там намного быстрее.

Медленная компиляция - ок. Принято.

Заголовочные файлы не имеют никакого отношения к удобству обзора кода

Не принято. Субъективно. Мне удобно. Есть другие, кому удобно.

в индустрии были десятки альтернативных способов организации интерфейсов разработки

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

И особенно сильно мешает понимать код наследование

Каким образом заголовочники мешают понимать наследование?

что нынче уже наследования нет в тех же Rust и Go

Ну и ладно. Нету и нету. Мне совершенно однозначно ложить болт на все доказаьельства того, что в некоторой парадигме какая-то фича лишняя или ненужная. В C++ наследование есть, его используют. Тебе не нравится - не используй. Только голову не епи.

И ситуация поменялась в заметно лучшую сторону, когда игры начали писать в Unity на C#

А как же UE?

А как же тот факт, что некоторые студии покупают Unity с исходниками и правят их под себя (кстати unity частично на C++)?

А как же тот факт, что AAA игры часто идут на собственном движке (который часто на C++)?

Для меня костыли удобны исключительно как средство изучения интерфейса

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

который позволяет быстро сразу в ide посмотреть сигнатуры функций, параметры, перегрузки, объявления классов, наследования

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

Каким образом заголовочники мешают понимать наследование?

В данном случае не «заголовки мешают», а «наследование мешает». А еще перегрузки мешают, и тем более мешают поскольку они в C++ неотключаемы, в отличие от того же мерзопакостного паскаля, где неявная попытка перегрузки функции является синтаксической ошибкой. Добрая половина всех ошибок компилятора C++ — это «не удалось выбрать перегруженную функцию», даже если ошибка не имеет отношения к перегрузке, потому что прежде всего конструкторы всегда перегружены. Достаточно написать в заголовке и реализации разные сигнатуры с минимальными отличиями — и вуаля, у тебя уже «перегрузка», и ты сидишь сравниваешь сигнатурки.

К слову, потому в Go нет перегрузок функций.

В C++ наследование есть, его используют. Тебе не нравится - не используй. Только голову не епи

Тебя кто-то заставляет на лор-е общаться? Если да, то мигни левым глазом.

И ситуация поменялась в заметно лучшую сторону, когда игры начали писать в Unity на C#

А как же UE?

А что UE? Если ты посмотришь на список игорей:
https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games
то заметишь, что в списке нет, например, RTS. Как минимум RTS требует серьезного уровня абстракции для описания логики игрового мира, и эту абстракцию в случае UE пришлось бы писать самому.

Разрабы UE прежде всего сделали упор на готовый графен+физика в FPS/RPG/VR ролик за пять минут в редакторе. Остальное их не особо волнует. И ради этого разрабы UE выдают с каждым годом больше и больше C++ кода, и вот уже они просто не могут его полноценно поддерживать, потому сорцы UE открываются. Они так-то и начали свое детище с того, что написали собственную STL.

Но, справедливости ради, в UE есть СБОРЩИК МУСОРА! Все-таки, какой-то кусок настоящей платформы они заложили.

А как же тот факт, что некоторые студии покупают Unity с исходниками и правят их под себя (кстати unity частично на C++)?

Unity на C/C++ с перекосом в сторону Си. Когда его адаптировали под Assassin's Creed, то он чуть ли не под ноль был переписан. Техдолг беспощаден. Но общая тенденция в сторону «платформа, а не писать всё на C++» очевидна.

А как же тот факт, что AAA игры часто идут на собственном движке (который часто на C++)?

Чаще всего они при разработке своей платформы просто делают те ошибки, которые опытные разрабы движков уже давно не делают. Взять тот же X-Ray, которые разрабы, очевидно, собирались продавать аля UE/Cry/Unity/Gamebryo, но получилось настолько плохо, что по итогу контора закрылась и движок опенсорснули. Вот конкретно в X-Ray прописаны сталкер-специфичные костыли, которые для платформы бесполезны, и потому по итогу как у платформы у него ценность околонулевая.

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

А зачем сейчас?
Переходить на другой язык, становиться недоджуном, получить понижение в зп. Ради отсутствия хедеров. Не настолько веская причина для меня. Вот если наступит СиПлюсПлюсКапец - то и буду учить новый (для меня он наступит когда исчезнут вакансии).

Нет, ты делаешь это инструментом, который за тебя находит в заголовках именно объявления, а не вызовы/использования идентификаторов

Совершенно верно.

Что характерно, в индустрии было валом языков, позволявших таки находить объявления простым текстовым поиском — без заголовоков, без индексаторов. Так в чем тогда помогают заголовки?

Нет, ну вот смотри. Вот допустим компиляторы C++ научатся обходиться без хедеров, будет аля import QString. И будут библиотеки распростроняться без хедеров, только одни бинарники. И откуда ide сможет отобразить инфу о сигнатурах/интерфейсах? Т.е. вместе с либой должен идти файл с описанием функций/классов, или как?

Наследование/перегрузки

Если обсуждение хедеров еще можно свести к объективному, то обсуждение парадигм их фичей - это очень субъективно, как спорить о цветах. Поэтому не со мной.

Тебя кто-то заставляет на лор-е общаться? Если да, то мигни левым глазом.

Да потому что начали про хедеры, а ты съехал на перегрузки и наследование.

А что UE? Если ты посмотришь на список игорей: https://en.wikipedia.org/wiki/List_of_Unreal_Engine_games то заметишь, что в списке нет, например, RTS. Как минимум RTS требует серьезного уровня абстракции для описания логики игрового мира, и эту абстракцию в случае UE пришлось бы писать самому.

И что, с того? Rts - нет, есть другие.

Но общая тенденция в сторону «платформа, а не писать всё на C++» очевидна.

Ну это логично, хочется меньших телодвижений.

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

Ну это если первый опыт написания, а ведь могут и уже опытные свое пилить.

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

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

Если отвечать со стороны прикладной ценности: код на Go при сравнимой производительности пишется раза в два быстрее, чем на крестах. И в 2022 уже никого не впечатляют басни про «кресты могут немного быстрее работать». В любом случае, C/C++ объективно является узкой нишей, именно потому, что писать на нем долго и опасно.

Вот допустим компиляторы C++ научатся обходиться без хедеров, будет аля import QString. И будут библиотеки распростроняться без хедеров, только одни бинарники. И откуда ide сможет отобразить инфу о сигнатурах/интерфейсах? Т.е. вместе с либой должен идти файл с описанием функций/классов, или как?

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

Неочевидный факт, но далеко не всегда либа написана на том же языке, на котором собираются писать клиентский код. Вот у меня либа на фортране, я тебе дам фортрановые заголовки — много ты сможешь на своих крестах наимпортироваться? Нет, тебе нужно оттранслировать заголовки на другой язык.

Далее, те же Java и Delphi генерируют бинарные модули, по которым IDE может очень эффективно читать интерфейсы модулей. Я подчеркиваю, что основная сложность трансляции модулей C/C++ заключается именно в парсинге, особенно в C++ синтаксис семантикозависимый, это даже не контекстозависимость, в нём создание отдельного разборщика синтаксиса принципиально невозможно. По итогу в C++ идут к тем же прекомпилированным заголовкам, но сильно окольными путями.

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

Наследование/перегрузки

Если обсуждение хедеров еще можно свести к объективному, то обсуждение парадигм их фичей - это очень субъективно, как спорить о цветах. Поэтому не со мной.

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

Но общая тенденция в сторону «платформа, а не писать всё на C++» очевидна

Ну это логично, хочется меньших телодвижений

Да, я тоже об этом: разрабам хочется ожидаемых сроков релизов, ожидаемой стабильности, а «может быть» и «подождите, я компилирую». Индустрия вроде как все эти годы пыталась сделать готовые решения, но по факту готовости в этих решениях довольно мало.

Если бы ты в короновирус перешел на Go, то мидлом бы получал как крестовый сеньор

А вот это вообще не факт. И вакансий меньше на порядок, по крайней мере в РБ. И прежде стань еще мидлом, если работу не найдешь. А кроме того на C++ и десктоп и embeded и игори и всякие CV и высоконагруженные. Поэтому про «узкая ниша» ты гоушникам рассказывай.

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

Ты не очень меня понял видимо. Мне плевать на споры о личных пристрастиях. Считаешь ты перегрузки или наследование полезным или нет, мне фиолетово. Спорить про это я не стану.

Да, я тоже об этом: разрабам хочется

Я не понял, это аргумент против плюсов? Видимо из твоих уст - да. Ну хз вообще то. UE норм для игорей? Норм. Есть вакансии на него? Есть. На плюсах там пишут? Да (ты конечно можешь вспомнить про блюпринты, но на них AAA игры как правило не делают). UE платформа в твоем понимании? Похоже да. Ну вот есть разработка на C++ в рамках платформы.

CV

В айтишной среде принято сокращение CV = curriculum vitae = резюме. Если ты хотел упомянуть компьютерное зрение, то его и упоминай.

на C++ и десктоп и embeded и игори и всякие CV и высоконагруженные

Я сам пишу сервера на крестах, но лично у меня сегодня есть большие сомнения по поводу оптимальности этого выбора — Go вполне себе вытягивает очень большие нагрузки. На десктопную разработку предложений по C++ очень мало, часто это какое-нибудь наследие. Игровая индустрия сдулась, на крестах игры уже почти не пишут, всё чаще нужны мобильные игры на готовых движках. Для машинного обучения, как ни странно, достаточно питона в большинстве случаев. В embedded часто требуется голый Си, как ни странно.

Поэтому про «узкая ниша» ты гоушникам рассказывай

На Go пишутся все сетевые сервисы, а это нынче о-о-очень широкая ниша.

В айтишной среде принято сокращение CV = curriculum vitae = резюме. Если ты хотел упомянуть компьютерное зрение, то его и упоминай.

Да, да. Расскажи мне про айтишную среду. Я знаю. Но некоторые вакансии указываю CV именно в значении компьютерного зрения. Вообще открой википедию и посмотри, сколько всего может это значить.

На десктопную разработку предложений по C++ очень мало, часто это какое-нибудь наследие. Игровая индустрия сдулась, на крестах игры уже почти не пишут, всё чаще нужны мобильные игры на готовых движках.

Однако там чуть чуть, там чуть чуть - так и набирается. Во всех этих сферах пока вакансии на плюсы есть. И в сумме по РБ по всем этим сферам вакансий больше чем на go. Может в РФ тоже.

На Go пишутся все сетевые сервисы, а это нынче о-о-очень широкая ниша.

Все - это такое эфемерное понятие, от которого мне ни жарко ни холодно. Лично на меня имеет влияние (пожалуй наиглавнейшее) количество вакансий.

Вот по Минску в linked показывает два десятка вакансий по запросу golang, часть из которых еще требует работу на python. Мне это счастье надо? По плюсам в десять раз больше. А зп для ~5 лет опыта что там, что там одинаковая.

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

Открыл. Первый пункт знаешь какой?

Однако там чуть чуть, там чуть чуть - так и набирается. Во всех этих сферах пока вакансии на плюсы есть. И в сумме по РБ по всем этим сферам вакансий больше чем на go. Может в РФ тоже

Да, в сумме, действительно, больше: С и C++ — $3-5k, 670 вакансий, Go — $3.5-6k, 310 вакансий. При том, что по расту 70 вакансий и оплата как за Go. А это, на секундочку, языки, старшему из которых 50 лет и на которых писалось почти всё, против свежеиспеченного языка. Ну типа да, C/C++, как кобол, еще очень долго не уйдут с рынка, но объективно рынок от них уходит ударными темпами.

Открыл. Первый пункт знаешь какой?

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

С и C++ — $3-5k, 670 вакансий, Go — $3.5-6k, 310 вакансий

Я не знаю, где ты там смотришь.

Linkedin, запрос: golang, локация: russia - 64 результата, Linkedin, запрос: c++, локация: russia - 974 результата,

Linkedin, запрос: golang, локация: belarus - 31 результат, Linkedin, запрос: c++, локация: belarus - 428 результата,

Понятно, что часть - это не целевые вакансии. Но все же.

но объективно рынок от них уходит ударными темпами

Вот это объективность - наше все. Ударный темп - это как? Лет за 50?

Вот зарекался вам конкретно не отвечать, но не удержался. Вы батенька, мягко говоря, пи…бол: словеслов много, а смысла мало. Продолжайте пилить сферического коня в вакууме. И оставьте уже реальное производство профессионалам, они как нибудь разберутся какой инструмент использовать (при всех их достоинствах и недостатках). Выйдете хотя бы на пол-ляма убитых енотов в год на сотрудника - стучите - возьму свои слова обратно. Потом можно будет обсуждать хороши плюсы как инструмент или нет. А до тех пор - в сад.

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

Я почему-то очень часто вижу подобные заявления от русских программистов. Как твой опыт может обнулиться с переходом на новый инструмент? Если ты за X лет научился только жонглировать плюсами и, не знаю, стряпать какие-то формочки на Qt например, то твоей сеньорности грош цена. В этом случае наоборот стоит вкладываться в саморазвитие и диверсифицировать знания. Имея богатый арсенал средств ты сможешь эффективно решать проблемы, в противном случае останешься принеси-подай кодером.

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

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

По итогу в C++ идут к тем же прекомпилированным заголовкам, но сильно окольными путями.

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

Размер IFC для import std; при сборке 64 битным компилятором и дебажной сборки /MDd /Od равен 26.4 MB

Размер прекомпилированных заголовков при тех же параметрах: 256.8 MB

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

Я сторонник идеи что можно знать всё ни о чём, или ничего обо всём. Если инструмент работает и востребован - зачем дёргаться?

Если ты за X лет научился только жонглировать плюсами и, не знаю, стряпать какие-то формочки на Qt

Не думаю что в кассу.

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

Всё в этом мире относительно.

Я сторонник идеи что можно знать всё ни о чём, или ничего обо всём. Если инструмент работает и востребован - зачем дёргаться?

Ты ставишь ложные акценты, говори как есть: если тебе платят, то у тебя нет мотивации дергаться. Так же было с кодерами на коболе, фортране, аде, лиспе: они так же с пеной у рта доказывали, что нет ничего лучше, чем знакомый им инструмент, да еще и квалифицированный кодер на нем впридачу — а некоторые даже тут до сих пор доказывают, больше про лисп, хотя есть отдельные кадры, топящие за кобола, и я даже встречал в бугорных интернетах фанатов ады. «Всяк кулик своё болото хвалит».

На самом деле, западная модель экономики даже поощряла сверхузкую специализацию. Другое дело, что старая модель экономики нынче рушится, и вполне возможно, что мастера на все руки внезапно окажутся востребованы. Хотя, трезво оценивая ситуацию, я бы говорил о том, что спрос на программистов в целом будет снижаться, из-за чего узкие специализации будут вымирать и вытесняться в сторону менее узкой, но всё же специализации, а особенно будет продолжать расти спрос на «сборщиков кубиков лего», строители в мире постапокалипсиса из тех блоков, которые «остались после войны» — то, что нынче называется «архитектор», но название — это уже вопрос вкуса и субъективщины, для кого-то бывают сантехнические архитекторы и менеджеры по уборке.

Ты ставишь ложные акценты, говори как есть: если тебе платят, то у тебя нет мотивации дергаться.

Именно так. А у вас по другому?

Так же было с кодерами на коболе, фортране, аде, лиспе: они так же с пеной у рта доказывали, что нет ничего лучше, чем знакомый им инструмент

Нет. Начну издалека. Чего фундаментального изменилось в мире Unix/Posix за последние несколько дцать лет? Я видел много технологий / продуктов которые рождались и умирали, и каждый раз было обещано «но вот же вот оно». И где вот это вот всё сейчас? C/C++ являются фундаментальными хотя бы потому что более менее понятно в какой asm оно разворачивается. Пока не произойдут тектонические сдвиги в железе (квантовые вычисления, я уж не знаю) - оно никуда не уйдёт. С моей точки зрения - вкладывать время в изучение чего-то ещё (а мы помним - время это наш самый главный ресурс, правда?) - в пустую. Уверен, кто-то это видит по другому, но свой выбор я уже сделал. И как показывает практика - не сильно ошибся.

Ты ставишь ложные акценты, говори как есть: если тебе платят, то у тебя нет мотивации дергаться.

Именно так. А у вас по другому?

Да, у меня по другому. И у очень большого числа людей по другому — иначе мы бы не знали никакого опенсорса. Проблема денег актуальна только пока их мало, но с определенной границы дохода человек получает возможность не «выживать, коротая дни до гроба», а жить, «делать то что хочется». И в том числе писать опенсорс.

Чего фундаментального изменилось в мире Unix/Posix за последние несколько дцать лет?

Это ты пишешь человеку, создавшему тред: Какие вы можете назвать революционные технологии ПО, созданные в последние 20 лет?

C/C++ являются фундаментальными хотя бы потому что более менее понятно в какой asm оно разворачивается

В случае C++ я бы не спешил с выводом про «понятно в какой asm оно разворачивается».

Я видел много технологий / продуктов которые рождались и умирали, и каждый раз было обещано «но вот же вот оно»... Пока не произойдут тектонические сдвиги в железе (квантовые вычисления, я уж не знаю) - оно никуда не уйдёт

Я тоже считаю, что диктатура C вызвана железом, другое дело, что я подхожу к этому вопросу не с твоей стороны «я выбор сделал удачно, а дальше мне пофик», а со стороны «традиционно инертная и косная IT индустрия топчется на месте, отвергая любой прогресс, но прогресс возможен». На самом деле прогресс все-таки есть, ты не заметил, поскольку ограничил свою сферу интересов, но индустрия очень медленно, неохотно, и неэффективно переходит к SIMD для нейросетей и распределенным вычислениям, оно же «микросервисы» — просто потому, что всё остальное стоит как вкопанное и почти не развивается, технологии писания под обычный ЦПУ за последние 10-15 лет совсем не изменились. Но GPGPU считает в 100 раз быстрее ЦП! Даже если с обоих сторон SIMD-ы, потому что у проца 200 гигафлопсов, а у видеокарты 20'000 гигафлопсов.

технологии писания под обычный ЦПУ за последние 10-15 лет совсем не изменились. Но GPGPU считает в 100 раз быстрее ЦП! Даже если с обоих сторон SIMD-ы, потому что у проца 200 гигафлопсов, а у видеокарты 20'000 гигафлопсов.

Эффективные программы под GPGPU пишутся на том же C++, внезапно (и немного на Фортране, но это уж совсем деды). К чему был весь этот полёт мысли?

поскольку ограничил свою сферу интересов,

Откуда дровишки? Можно поподробней о том что вы знаете о сфере моих интересов?

но индустрия очень медленно, неохотно, и неэффективно переходит к SIMD для нейросетей и распределенным вычислениям,

Какая именно индустрия?

Но GPGPU считает в 100 раз быстрее ЦП!

Не удержался: сейчас кончу. А экспрессии то сколько…

Даже если с обоих сторон SIMD-ы, потому что у проца 200 гигафлопсов, а у видеокарты 20’000 гигафлопсов.

И что? На GPU вы сможете быстро обсчитывать очень узкий круг задач, лишний branch и «ау». Мужики вон плисами заморачиваются (проходили, знаем) там где это реально критично. Но, кмк, с вами это бессмысленно обсуждать - у вас же go / rust / you name what other fashionable language ppl came up with в приоритете.

Эффективные программы под GPGPU пишутся на том же C++, внезапно (и немного на Фортране, но это уж совсем деды). К чему был весь этот полёт мысли?

Они настолько же пишутся на C++, насколько и на питоне. То есть, дергаются внешние функции. Но по-хорошему, если ты не хочется терять производительность на прерываниях и перекидывании памяти с видюхи и обратно, то писать на C++ не получится, как и на питоне.

Так как от основной конкретной темы уже отклонились, то позволю себе мысли на тему сложности C++. В книге «Мифический человекомесяц» предлагалось создавать бригады из десяти человек для разработки сложного ПО. И один из этих людей назывался «языковед». Этот человек разбирался во всех тонкостях используемого языка программирования. Один из десяти. Предполагалось, что этого достаточно.

Я в жизни таких бригад не встречал, как и не видел вакансию «языковед». Но есть ощущение, что многие языки, в том числе и C++ создаются в расчёте на такие бригады с языковедом.

Параллельно с этим создавались языки типа PHP или раннего Python, которые не требуют наличия языковеда. Например, я знал одного успешного фрилансера на PHP который не мог сказать, чем строгая динамическая типизация отличается от нестрогой. Его больше волновало как создать сайт, который понравится заказчику.

Если у тебя в коде хитроумные иерархии абстрактных классов и шаблон на шаблоне - то ты языковед. Это неплохо, но для достижения успеха этого обычно мало. Нужен ещё человек, который понимает, что требуется заказчику. И такой человек в одиночку может выдать что-то полезное (хотя код будет далеко не идеальным), а языковед - нет.

Какая именно индустрия?

Нейросетки вообще на всё, что попадет под руку, пытаются использовать, вплоть до умных утюгов. А «распределенные вычисления» — это нынче почти весь вебовый бэкэнд.

На GPU вы сможете быстро обсчитывать очень узкий круг задач, лишний branch и «ау»

Давай подумаем для начала, какие вычисления у нас не параллелизуются? Год назад у меня был здесь аналогичный срач, челу понравился фильтр калмана, как пример рекуррентного алгоритма, но фильтру калмана нужно порядка тысячи циклов вычислений в секунду. Смартфон выдает 60 кадров в секунду, всё остальное параллелизуемо. Парсинг JSON? Параллелизуем. Да, gzip сжатие не параллелизуемо, поскольку нарушает границы байтов. Но SSL умеренно параллизуем, поскольку AES оперирует 16-байтными блоками, и никто не мешает делать шифрования с большими размерами блоков, не говоря уже про независимые соединения.

Мужики вон плисами заморачиваются (проходили, знаем) там где это реально критично

FPGA хороши, но малопопулярны, потому по цене за одну штуку выходит дорого из-за низкого спроса, хотя по энергоэффективности они уделывают GPGPU на многих задачах.

Но, кмк, с вами это бессмысленно обсуждать - у вас же go / rust / you name what other fashionable language ppl came up with в приоритете

В профиль бы посмотрел, что ли...

Они настолько же пишутся на C++, насколько и на питоне. То есть, дергаются внешние функции. Но по-хорошему, если ты не хочется терять производительность на прерываниях и перекидывании памяти с видюхи и обратно, то писать на C++ не получится, как и на питоне

Господи, какую же дикую херь ты пишешь. На CUDA C++ (что есть надмножество C++) пишутся сами кернелы, которые ничего не прерывают, и никаких лишних пересылок не делают. А на Python да, дёргаются либы

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

ПО для SpaceX разработано на С++ (комментарий)

И вверх по ветке дискуссии. Попозорюсь немного в Ваших глазах, но хоть будете знать кому пытаетесь донести про GPU и пр… Этот товарисч искренне верует в лунный заговор.

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

Кстати да. в среде системщиков принято мастурбировать на глубину понимания тонкостей инструмента и забывать, что прежде всего нужно решить задачу и понравиться заказчику. В том числе у меня есть симптомы этой болезни, поскольку я сам повелся на это обсуждение. Тем временем индусы в Facebook и Amazon успешно сдают решения ни о чём, поскольку умеют «понравиться заказчку».

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

фрилансера на PHP который не мог сказать, чем строгая динамическая типизация отличается от нестрогой

https://herotomorrow.tumblr.com/post/121650258593/useing-youre-types-good-a-l...

На CUDA C++ (что есть надмножество C++) пишутся сами кернелы, которые ничего не прерывают, и никаких лишних пересылок не делают. А на Python да, дёргаются либы

Скорее множества, которые имеют пересечение со стандартным C++. Не так давно множество CUDA C++ было настолько куцым, что больше походило на Си, чем на C++: не было настоящих вызовов функций (они инлайнились, рекурсия не допускалась), виртуальных методов, new/delete, исключений. Да, сейчас уже и это завезли, но писать ядра CUDA на STL — это безумие, согласись? Это не состыковывается с «эффективные программы под GPGPU пишутся на том же C++». А если я не могу использовать ни одно старое готовое решение — какая разница, называется ли этот язык C++, Фортран, или Паскаль? Я могу лишь догадываться, зачем в NVidia решили натягивать сову на глобус (маркетинг).

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

Или о твоей ограниченности — Numba позволяет писать ядра на питоне. Гы-гы.

bugfixer

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

Финтех… какая гадость.

Мнения разнятся.

обслуживая индустрию с околонулевой прикладной ценностью.

Мой поршик с удовольствием выслушает ваше мнение по вопросу.

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

Мой поршень поспорит с вашим поршиком!

обслуживая индустрию с околонулевой прикладной ценностью.

Мой поршик с удовольствием выслушает ваше мнение по вопросу

Да, согласен, был неточен: конечно же финансовые организации имеют прикладную ценность для их организаторов (как и МММ покойного Мавроди), являясь утонченной формой отъёма перераспределения ресурсов. Ты в банде, с чем я тебя и поздравляю. Без шуток, я бы так не смог.

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

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

А если я не могу использовать ни одно старое готовое решение — какая разница, называется ли этот язык C++, Фортран, или Паскаль? Я могу лишь догадываться, зачем в NVidia решили натягивать сову на глобус (маркетинг)

1. Модуль на CUDA C/C++ можно слинковать/встроить в любую другую программу, в том числе дёргать из любого другого языка, ибо это стандарт. Чем активно пользуются. Ну была бы CUDA на питоне - подумай, сколько быто геморроя принесло бы при интеропе

2. Весь HPC и до них писали на C/C++ и фортране. Что упрощает то самое переиспользование кода, которого якобы нет. Они органично встроились в экосистему

Скорее множества, которые имеют пересечение со стандартным C++

Насчёт тех фишек C++, которые актуальны в CUDA, а какие нет, я перед тобой сейчас распинаться не буду. Напиши сначала что-нибудь под платформу, о которой ты вещаешь, а потом обменяемся опытом ;)

Или о твоей ограниченности — Numba позволяет писать ядра на питоне. Гы-гы.

Выбор инструмента за тобой

Модуль на CUDA C/C++ можно слинковать/встроить в любую другую программу, в том числе дёргать из любого другого языка, ибо это стандарт. Чем активно пользуются. Ну была бы CUDA на питоне - подумай, сколько быто геморроя принесло бы при интеропе

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

Ну была бы CUDA на питоне - подумай, сколько быто геморроя принесло бы при интеропе

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

Весь HPC и до них писали на C/C++ и фортране. Что упрощает то самое переиспользование кода, которого якобы нет. Они органично встроились в экосистему

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