> Ворвусь как я в тред, если никто не против) Площадка публичная, почему кто-то должен быть против?))
> Можно ли считать, что "согласно стандарту C++ порядок вычисления аргументов функции не
> специфицирован" это баг, или просто недоработка?
> Я беру одинаковый код, но на разных компиляторах я получаю разный результат.
> Можно ли говорить о корректности кода и "стандартизованности" стандарта.
Стандарт такой, какой он есть. Если он кому-то не нравится - нужно вносить предложения по изменению (если таковой механизм доступен) или создавать альтернативу. "На разных компиляторах" в случае с С++ обычно выливается в "а на MSVC не так". Что как бы намекает, что проблема отнюдь не в стандарте...
> Но такие вещи как автоматизация позволяет тратить эти вещи на сложные задачи
> и не тратить на рутинные.
> Например автотесты или санитайзеры упрощают жизнь, ускоряют разработку и уменьшают шанс
> ошибится.
Смотря что вы подразумеваете под автотестами. Если некие автоматические проверки кода - то нет, на самом деле не упрощают. Потому что всегда остаётся вероятность, что в соответствующем ПО тоже есть ошибки (и я их, кстати, достаточно регулярно вижу). Поэтому всей автоматикой допустимо пользоваться уже после того, как вы провели тестирование самой программы на все возможные варианты её использования. Если в процессе тестирования что-то сработало не так, как ожидалось. В противном случае - нет. В том числе и потому, что присутствует психологический фактор - вы сами не заметите, как всё больше начнёте полагаться на автоматику, т.е. постепенно начнёте терять квалификацию. Кроме того автоматика нормально работает только в стандартных случаях, а программист нужен в том числе для того, чтобы придумывать нестандартные решения. Иначе его можно заменить той же автоматикой (что в общем-то и наблюдаем).
> Судя по всему, у вас очень большой опыт разработки.
> Но, к сожалению вас нельзя клонировать, скопировать и тд.
> А для производства больших проектов нужны сотни таких как вы.
Не то чтобы прям большой, но кое-какой имеется. И не так уж много людей нужно на самом деле. У вас скорее всего такое впечатление сложилось из-за геймдева. Над играми действительно работает много народу, но далеко не все они - программисты. Большинство там всякие художники, сценаристы, дизайнеры, аниматоры и т.д. Когда пишется что-то прикладное, то там обычно много людей не нужно. Особенно, если им обеспечить нормальные условия труда и грамотно распределить задачи.
> Да, но для этого нужно очень большая дисциплина (что в опенсорсном проекте
> вообще редкость).
> Я видел как люди уходили из открытых проектов просто по причине "я
> не хочу ждать пока на пулл реквесте пробегут автотесты! я же
> профи, ты что не доверяешь мне?!"
А без дисциплины - никуда. Окружающей реальности нет дела до наших проблем. Потому что она неживая. И действует по своим законам. Мы или можем ей противостоять, и под неё подстраиваться, либо умираем. Подобные проблемы на самом деле сегодня актуальны вообще во всех сферах человеческой деятельности. Просто потому, что мы подошли к условной кризисной точке в своём развитии. И либо мы изменим своё отношение буквально ко всему, либо вымрем. C'est la vie.
> Как и в расте.
> Магическое слово unsafe открывает дверь в волшебный мир "делаю что хочу")
Так зачем в таком случае плодить лишние сущности, если всё и так есть?)) Хотя в случае с Rust как раз понятно - зачем. Но, повторюсь, я не против него как такового - от появления ещё одного ЯП никому ни холодно, ни жарко. Нравится кому-то - пусть пользуются, это их личное дело. Я в данном случае против технически неоправданных решений, которые к тому же затрагивают большое количество людей по всему миру. И против попытки нажиться на общественном достоянии (Линукс уже им дефакто стал).
> Ну, меня тут еще интересуют другие вещи: среднее время работы до критичной
> ошибки, как быстро в коде разберется новый человек и тд.
> Возможно это связано с тем что я работал в больших проектах с
> немаленькими командами.
Всё это вопросы организации рабочего процесса. Если вы усложняете программу только потому, что у вас люди не в состоянии работать с кодом, то это говорит о том, что вам лучше заняться чем-то другим, а не программированием. Или гнать организатора рабочего процесса в шею за полную профнепригодность.
> Предположу, что в некоторых проектах это работает. Особенно если весь код написал
> сам.
> А в некоторых нет. Т.к ты можешь делать свой модуль, а в
> это время еще десять человек пилят пяток других.
> И ты их код увидешь или на код ревью, или когда полезешь
> там что-то исправлять.
Опять же - это вопрос организации рабочего процесса. Ну и инкапсуляцию придумали как раз вот для таких случаев. Если вы пишите некий отдельный модуль программы или библиотеки, то вам, как программисту, должны поставить чёткую задачу: на входе будут такие-то параметры, на выходе должен получиться такой-то результат. Дальше вы всё это реализуете полностью автономно. Если вам для написания модуля требуется видеть чужой код - это признак неправильной архитектуры программы или неграмотного руководства проектом. Или и того и другого сразу.
> Гораздо хуже, когда программист не видит UB)
> Т.к запомнить все особенности всех компиляторов.
> Можно конечно говорить "нам нужны люди с 20 годами опыта, вот тогда
> и приходите", но работает это плохо.
Зачем вам запоминать всё? Документацию как раз и придумали на такие вот случаи. Не знаю, как и чему учили вас, нас же учили так: "Ты можешь чего-то не знать. Но где это можно найти - ты знать обязан". Правда я по образованию ни разу не программист)) Что, впрочем, не отменяет верность описанного выше принципа для любых ситуаций.
> Но к сожалению в ядре у нас, не современный С++, с умными
> указателями и прочими благами цивилизации, а С11, причем на него они
> перешли только ЕМНИП в 22году.
Да не вопрос - если посмотрите, с чего всё началось, то я о том и говорил в общем-то. Мне реально странно видеть, что в ядре Линукс не используют С++. На заре появления языка вполне возможно, что для этого были объективные причины. Но в текущих реаиях с технической точки зрения подобное решение выгляди неоправданным. Опять же - я могу чего-то не знать. Но всё, что я видел по этому поводу от непосредственных участников проекта, выглядит, как глупое упрямство. Причём, не обязательно ведь переписывать всё и сразу. С++ благодаря своим свойствам позволяет сделать процесс постепенным.
> К сожалению он для совсем прикладных приложение не очень подходит, тк UI
> на нем писать непросто.
Вот собственно ещё один недостаток языка. Вполне объективный.
> Люди всегда мечтают от серебрянной пуле, даже если она немного ржавая)
Ну... Я об этом уже написал выше. Немного перефразирую сказанное - людям пора повзрослеть. И понять наконец, что магии не существует. Любые преимущества достигаются за счёт того, что в чём-то другом проседание. У всего есть свои преимущества и недостатки. Да, С/С++ позволяют допускать ошибки. Однако об этом известно (точнее - должно быть известно) любому, кто начинает с ними работать. И такое поведение необходимо учитывать. Но взамен мы получаем существенное снижение нагрузки на процессор и память как в процессе компиляции, так и в процессе работы программы. А также очень гибкий инструмент, позволяющий делать буквально всё, что угодно практически на любом оборудовании. И это главное. Недостатки Rust тут уже обсуждали, и не раз, поэтому повторяться не буду. Суть в том, что его применение с технической точки зрения - неоправданно. А все проблемы, которые он якобы решает, могут быть устранены уже имеющимися средствами, причём без особых на то усилий - достаточно лишь понимать, что происходит, и иметь желание сделать всё правильно.
> ... для чего нужно воспитать целые поколения программистов, заставить их следовать стилю
> и надеяться что стиль подойдет под задачу.
Заставить кого-то делать что-то невозможно в принципе. Можно лишь чётко и внятно объяснить человеку, почему нужно поступать так или иначе. Чтобы он сам захотел делать вещи правильно. Или убить. Собственно именно поэтому я тут словоблудием и занимаюсь - до второго варианта доводить не хотелось бы)) Надеяться тоже ни на что не нужно. Нужно решать поставленную задачу в рамках имеющихся средств. Предварительно выработав общий план работ.
> По стравнению с ASM любые языки высокого уровня генерировали "лишние" инструкции.
> Но на них почему-то перешли. Особенно если время компиляции стоит N денег,
> а 10 часов поиска EXC_BAD_ACCESS стоят M денег, и при этом
> N < M.
Всё очень просто. Ассемблеров больше одного - они индивидуальны для каждой архитектуры процессоров. И в такой ситуации появление некой абстракции в виде языков более высокого уровня как раз вполне оправданно. Потому что позволяет разделить задачи: если делать всё по уму, то создатель процессора той или иной архитектуры должен вместе с ним выпустить спецификацию команд, а также компилятор для того или иного языка высокого уровня. Какого именно - тут опять же по уму нужно всем собраться и решить, что мы используем. Потому что любой ЯП высокого уровня - это просто текст, который преобразуется компилятором в команды. Компилятор можно настроить как угодно, поэтому здесь нужно смотреть на удобство и лаконичность именно текста. На мой взгляд С++ - в данном случае вполне оптимальный вариант. Но это уже решать не только мне. При этом спецификация всего этого дела должна быть полностью открытой, чтобы любой мог создать нечто своё - вдруг получится лучше? Но при этом решение об использовании нового ЯП, как стандарта, должно приниматься ВСЕМИ УЧАСТНИКАМИ ПРОЦЕССА. Как программистами, так и пользователями. Потому что это затронет всех.
> Напомню что СИ был разработан как потомок языка Би (который разработали AT&T,
> корпорация кстати) и был сделан в лаборатории Bell Labs (тоже корпорация)
> для абсолютно денежного интереса.
> И в этом (для меня) нет ничего плохого.
> Ада писалась по заказу Министерства обороны США. И плохим это ее не
> сделает
Здесь нужно разбираться индивидуально по каждому случаю. Но при этом стоит учитывать несколько факторов. Первое - С/С++ стандартизированы на международном уровне, что сильно затрудняет любые попытки подмять всё это дело под себя для получения исключительно личной выгоды. Второе - для С/С++ существует открытый компилятор, который опять же с юридической точки зрения будет практически невозможно подмять под себя. О его качестве можно спорить, не суть, главное - он есть. Т.е. кому-либо будет достаточно сложно создать монополию. По крайней мере легально. Почему монополизация в условиях капитализма - это плохо, надеюсь, объяснять не нужно?
> А раст для меня похож на токарник с ЧПУ, он умеет часть
> вещей делать автоматически, но если нужно - можно управлять им в
> ручном режиме.
> И сейчас программист - это почти как слесарь или инжинер в 70-80
> (куча народу работает над )
> На дороге человек тоже может ехать аккуратно, но ему зачем-то вешают знаки,
> светофоры и даже ставят отбойники.
> А техника безопасности, например электрики (которая ПУЭ) вообще написана кровью.
> Так что я за вещи, которые позволят сделать код надежнее.
Надёжнее код может сделать только одно - повышение квалификации программистов. Никаких других путей для этого не существует.
