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

Pzz>>Так что представления о качестве его софта из его слов не выведешь.
_>Проблема не в том, что кто-то пишет код с использованием ненадёжных, небезопасных подходов и практик.
_>Проблема — когда такие подходы продвигаются, как правильные, а сторонники практик, облегчающих написание надёжного кода, объявляются "истинными врагами". А человек, заявляющий "у меня длиннее", уж наверняка будет навязывать своё видение в команде.

А кто в этой дискуссии не категоричен?

_>Я знаю специалистов, на голову, а то и не одну выше меня, при этом defensive programming, эти все ассёрты, санитайзеры, юнит-тесты, повышенные уровни предупреждений, const-correctness, [nodiscard]], RAII, отказ от using-директив и пр. им "мешают творить".

Наше ремесло обрасло неимоверным количеством ритуалов, в которые все верят, будто их Моисей на каменных скрижалях написал.

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

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

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

Пойми меня правильно, я не против code review и т.п. Но мне странно видеть, как соблюдение ритуалов ставится выше здравого смысла.

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

_>Могу ли уважать такого человека, может, даже в чём-то и восхищаться? Да.
_>Захочу ли я с ним работать? Нет. Это будет боль или для него, или для меня, или для обоих. Я не настолько умён, чтобы отказываться от помощи инструментов. И большинство программистов — тоже.

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

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

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

M>>Да вот ещё, терпеть тебя. Нам просто на тебя наплевать. Просто мы теперь многое о тебе узнали, как и о качестве твоего софта. Ну и стало ясно, что твоё мнение немногого стоит, ты можешь лютую дичь нести с важным видом.

Pzz>Знаешь, мне приходилось встречать людей, которые рассуждают, как Альфа, но при этом в состоянии надёжно работать. У них какие-то свои методы обеспечения надёжности, отличные от общепринятых.

Весьма возможно, что он пишет очень-очень мало кода. Не, его код может быть очень нужным и важным, и никто другой его не напишет, так как он, но тем не менее, это очень специфично, и хорошо, если работает в 1% случаев.


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

В сишечке const был всегда (ну почти):

Ключевое слово const появилось в языке C в версии ANSI C (C89), которая была стандартизирована в 1989 году.

Что-то мне не кажется, что вы настолько древние, что успели сформироваться как профессионалы, до 89го года.


Pzz>Так что представления о качестве его софта из его слов не выведешь.

Весьма вероятно, что 99% "его" софта написано не им, а он только отвечает за какие-то компоненты, и его не трогают, пока оно вроде как работает и вроде не особо глючит

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

Pzz>>Знаешь, мне приходилось встречать людей, которые рассуждают, как Альфа, но при этом в состоянии надёжно работать. У них какие-то свои методы обеспечения надёжности, отличные от общепринятых.

M>Весьма возможно, что он пишет очень-очень мало кода. Не, его код может быть очень нужным и важным, и никто другой его не напишет, так как он, но тем не менее, это очень специфично, и хорошо, если работает в 1% случаев.

А может вовсе и не мало кода. С его слов это никак не следует.

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

M>В сишечке const был всегда (ну почти):

Я люблю const. Не надо меня агитировать за const. В гошечке я скучаю по сишному const. Не понимаю, почему он туда не попал.

M>

M>Ключевое слово const появилось в языке C в версии ANSI C (C89), которая была стандартизирована в 1989 году.

И до сих пор используется не всегда последовательно. Например, strerror, getenv возвращают неконстантную строку. Функции типа strtol берут константную строку, но указатель на место, после которого не получилось распарсить — char **.

Не то, чтобы таких мест много, но время от времени на них натышаешься. В компиляторах времен начала 90-х таких "подарков" было больше.

Pzz>>Так что представления о качестве его софта из его слов не выведешь.

M>Весьма вероятно, что 99% "его" софта написано не им, а он только отвечает за какие-то компоненты, и его не трогают, пока оно вроде как работает и вроде не особо глючит

Можно долго гадать, чего он там и в каком количестве пишет

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


Pzz>А может вовсе и не мало кода. С его слов это никак не следует.

С таким подходом сложно написать крупную систему. Не ну может он конечно уникум.


M>>В сишечке const был всегда (ну почти):

Pzz>Я люблю const. Не надо меня агитировать за const. В гошечке я скучаю по сишному const. Не понимаю, почему он туда не попал.

Да я вроде и не особо агитирую, я просто констатирую факт, что если культура писать без const привилась у человека, то это очень древний человек


M>>

M>>Ключевое слово const появилось в языке C в версии ANSI C (C89), которая была стандартизирована в 1989 году.

Pzz>И до сих пор используется не всегда последовательно. Например, strerror, getenv возвращают неконстантную строку. Функции типа strtol берут константную строку, но указатель на место, после которого не получилось распарсить — char **.

Тяжелое наследие:

В 1969—1973 годы на основе Би был разработан компилируемый язык, получивший название Си.

В 1973 году вышла третья редакция Unix со встроенным компилятором языка Си.

Подозреваю, K&R тоже про const не особо сначала подумали, а потом наелись говна и решили добавить, и спустя 15 лет оно вошло в стандарт.

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

strtol — весьма вероятно, что предполагалась возможность модифицировать буфер, если знаешь, что передал туда неконстантную строку. char* кастится к const char без предупреждений, обратно — не так. А товарищи не любили явно кастить


Pzz>Не то, чтобы таких мест много, но время от времени на них натышаешься. В компиляторах времен начала 90-х таких "подарков" было больше.

Ну, перечисленное — это изначально были юниксовые сисколы, а не просто какой-то компилятор


M>>Весьма вероятно, что 99% "его" софта написано не им, а он только отвечает за какие-то компоненты, и его не трогают, пока оно вроде как работает и вроде не особо глючит

Pzz>Можно долго гадать, чего он там и в каком количестве пишет

С таким подходом много и качественно очень сложно сделать

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

Pzz>И до их появления как-то же люди умудрялись программы писать.

Я на асме Z-80 не одну тетрадку 96 листов всяких подпрограмм и библиотечек написал, только вот в продукт оно так и не выросло


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

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


Pzz>Я так понимаю, у Альфы в проекте куча предупреждений сыпется. Вряд ли все евонные, иначе он бы просто подстроил опции компилятора под себя. Похоже, там и без него изрядный бартак стоит.

Я без проблем решал эту проблему


Pzz>В общем и целом, если из кода лезут предупреждения изо всех мест, какой смысл их держать в компиляторе разрешенными, если их никто не чинит?

Смысл есть сделать это хотя бы для своего кода

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

Pzz>>А может вовсе и не мало кода. С его слов это никак не следует.

M>С таким подходом сложно написать крупную систему. Не ну может он конечно уникум.

Ну а как люди пишут крупные системы на JS или Питоне? Там с проверками еще сильно хуже.

M>Подозреваю, K&R тоже про const не особо сначала подумали, а потом наелись говна и решили добавить, и спустя 15 лет оно вошло в стандарт.

Мне кажется, там уж комитет подключился.

Вообще, лет 20 назад в UNIX было полно программ, написанных на K&R C. Т.е., никаких тебе const, никаких прототипов функций...

M>Unix изначально был однозадачный, и, возможно, создатели что-то знали о размерах буфера strerror, getenv, и могли его использовать. Потом фичу порезали, но для совместимости с говнокодом сигнатуры остались как есть.

В каком смысле он был однозадачный? В том, что решал одну задачу: создавал предлог Ричи и Томпсону заныкать стоявшую в конторе "ничейную" PDP-ку и невозбранно играть на ней в Startrack?

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

M>strtol — весьма вероятно, что предполагалась возможность модифицировать буфер, если знаешь, что передал туда неконстантную строку. char* кастится к const char без предупреждений, обратно — не так. А товарищи не любили явно кастить

У товарищей ps работал путём чтения ядерной памяти из /dev/kmem. Народ тогда был не то, что ныне

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

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

M>В этом ничего смешного. Опенсорсный считается протестированным сообществом, и потому достаточно качественным, а также — это чисто внешняя зависимость, и никто её развивать не будет. А свой код таки предполагается, что будет развиваться. Так что подход вполне логичный.

Качество там ОЧЕНЬ разное.

Например, libtiff, написанный в одни руки Самуилом Лёфлером, соавтором ядра BSD UNIX и совершенно замечательной книжки про это ядро — это лютый треш (а ядро, кстати, вполне ничего, не считая местами ну очень уж тонких игр с синхронизацией там, где можно было бы сделать по-простому, не пожалев нескольких тактов процессора на явное использование какого-нибудь уместного примитива синхронизации).

Pzz>>Я так понимаю, у Альфы в проекте куча предупреждений сыпется. Вряд ли все евонные, иначе он бы просто подстроил опции компилятора под себя. Похоже, там и без него изрядный бартак стоит.

M>Я без проблем решал эту проблему

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

Pzz>>В общем и целом, если из кода лезут предупреждения изо всех мест, какой смысл их держать в компиляторе разрешенными, если их никто не чинит?

M>Смысл есть сделать это хотя бы для своего кода

Есть. Если говно из заголовков не лезет.

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

Pzz>А кто в этой дискуссии не категоричен?
Я! и не спорь!

Pzz>При всём при том, многие из них родились совсем недавно. И до их появления как-то же люди умудрялись программы писать.
Pzz>Например, к тому времени, когда придумали code review, я написал уже не один десяток тысяч строк вполне работоспособного софта. А сейчас код без ревью считается говнокодом.
Количество кода и программистов выросло, а качество программистов — наоборот, это нужно учитывать в практиках.

Pzz>Самое смешное, что многие программы, написанные по корпоративным стандартам, содержат хренову кучу опенсорсного кода. Который запросто может быть написан, следуя совсем другим процессам. И никого это не парит, когда речь идет о внешнем коде, но вот внутренний — будьте добры все ритуалы соблюсти.
Тот опенсорс, который я тащу в проект — это обычно что-то сильно более протестированное в силу пользовательской базы, чем моё (буст, к примеру, или fmtlib). Себе я доверяю меньше, поэтому предпочитаю, чтобы мой код коллеги смотрели, не ради ритуала, а чтобы поймать мою невнимательность, да и познакомиться с тем, что изменилось. При этом я вполне могу позволить себе пушнуть в мастер без ревью, и, обожемой, даже переписать историю уже пушнутой ветки (и даже мастер)! Ща меня заплюют, наверное

Pzz>Пойми меня правильно, я не против code review и т.п. Но мне странно видеть, как соблюдение ритуалов ставится выше здравого смысла.
Я тут полностью с тобой. Туда же отнесу разновсяческие Clean Code и прочие Solid, если они исполняются ритуально и догматично.

Pzz>При этом я не хочу быть услышан, как человек, который выступает за полную анархию в разработке. Правила нужны, особенно в командной игре. Но надо понимать, что можно договориться, с учётом реалий конкретной команды, о правилах "не по учебнику", и это будет прекрасно работать.
+. Но от Альфы я увидел скорее "мне не нужны правила, у меня длинней" (и в разрезе толерантности к предупреждениям, и по поводу const, и что-то ещё, общее ощущение вот такое).

Pzz>Я так понимаю, у Альфы в проекте куча предупреждений сыпется. Вряд ли все евонные, иначе он бы просто подстроил опции компилятора под себя. Похоже, там и без него изрядный бартак стоит.
Я воспринимаю мнение Альфы так (пусть поправит, если ошибочно): "у нас в проекте куча предупреждений, поэтому мы не видим среди мусора нужное, но меня это устраивает". Ну вот не увидел я в его текстах сожаления о том, что оно так. Мне это непонятно.

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

Если утилита каждый запуск пишет простыни в stderr, но тебе этот вывод неинтересен — перенаправь его в /dev/null, зачем на него глядеть-то?

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

M>>В этом ничего смешного. Опенсорсный считается протестированным сообществом, и потому достаточно качественным, а также — это чисто внешняя зависимость, и никто её развивать не будет. А свой код таки предполагается, что будет развиваться. Так что подход вполне логичный.

Pzz>Качество там ОЧЕНЬ разное.

Pzz>Например, libtiff, написанный в одни руки Самуилом Лёфлером, соавтором ядра BSD UNIX и совершенно замечательной книжки про это ядро — это лютый треш (а ядро, кстати, вполне ничего, не считая местами ну очень уж тонких игр с синхронизацией там, где можно было бы сделать по-простому, не пожалев нескольких тактов процессора на явное использование какого-нибудь уместного примитива синхронизации).

Даже если это не так, как возможно, в твоём примере, всё равно никто этот условный libtiff ни чинить, ни развивать не будет


Pzz>>>Я так понимаю, у Альфы в проекте куча предупреждений сыпется. Вряд ли все евонные, иначе он бы просто подстроил опции компилятора под себя. Похоже, там и без него изрядный бартак стоит.

M>>Я без проблем решал эту проблему

Pzz>Это — организационная проблема. Она не всегда решается тем, что ты создаешь патч, который решает техническую часть проблемы.

Причем тут патч, когда это решается разными настройками компилятора для разных частей проекта?


Pzz>>>В общем и целом, если из кода лезут предупреждения изо всех мест, какой смысл их держать в компиляторе разрешенными, если их никто не чинит?

M>>Смысл есть сделать это хотя бы для своего кода

Pzz>Есть. Если говно из заголовков не лезет.

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

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

Pzz>>При всём при том, многие из них родились совсем недавно. И до их появления как-то же люди умудрялись программы писать.
Pzz>>Например, к тому времени, когда придумали code review, я написал уже не один десяток тысяч строк вполне работоспособного софта. А сейчас код без ревью считается говнокодом.
_>Количество кода и программистов выросло, а качество программистов — наоборот, это нужно учитывать в практиках.

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

Pzz>>Самое смешное, что многие программы, написанные по корпоративным стандартам, содержат хренову кучу опенсорсного кода. Который запросто может быть написан, следуя совсем другим процессам. И никого это не парит, когда речь идет о внешнем коде, но вот внутренний — будьте добры все ритуалы соблюсти.
_>Тот опенсорс, который я тащу в проект — это обычно что-то сильно более протестированное в силу пользовательской базы, чем моё (буст, к примеру, или fmtlib). Себе я доверяю меньше, поэтому предпочитаю, чтобы мой код коллеги смотрели, не ради ритуала, а чтобы поймать мою невнимательность, да и познакомиться с тем, что изменилось. При этом я вполне могу позволить себе пушнуть в мастер без ревью, и, обожемой, даже переписать историю уже пушнутой ветки (и даже мастер)! Ща меня заплюют, наверное

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

Pzz>>При этом я не хочу быть услышан, как человек, который выступает за полную анархию в разработке. Правила нужны, особенно в командной игре. Но надо понимать, что можно договориться, с учётом реалий конкретной команды, о правилах "не по учебнику", и это будет прекрасно работать.
_>+. Но от Альфы я увидел скорее "мне не нужны правила, у меня длинней" (и в разрезе толерантности к предупреждениям, и по поводу const, и что-то ещё, общее ощущение вот такое).

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

Pzz>>Я так понимаю, у Альфы в проекте куча предупреждений сыпется. Вряд ли все евонные, иначе он бы просто подстроил опции компилятора под себя. Похоже, там и без него изрядный бартак стоит.
_>Я воспринимаю мнение Альфы так (пусть поправит, если ошибочно): "у нас в проекте куча предупреждений, поэтому мы не видим среди мусора нужное, но меня это устраивает". Ну вот не увидел я в его текстах сожаления о том, что оно так. Мне это непонятно.

Ну, я тоже примерно так услышал. Ну или не "устраивает", а "приходится с этим как-то уживаться". Организационно может быть трудно навести там порядок, мы ж не знаем его обстоятельств.

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

M>Даже если это не так, как возможно, в твоём примере, всё равно никто этот условный libtiff ни чинить, ни развивать не будет

Проблема в том, что он важен для печати, факсов и PDF. И у него нет альтернативы. А чинить да, никто не будет.

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

M>>Даже если это не так, как возможно, в твоём примере, всё равно никто этот условный libtiff ни чинить, ни развивать не будет

Pzz>Проблема в том, что он важен для печати, факсов и PDF. И у него нет альтернативы. А чинить да, никто не будет.

Так и в чем проблема? Работает, и ладно.

Насрать, в каком стиле там всё сделано, почему тот стиль должен как-то влиять на основной проект?

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


A>Ну вот например, они пропагандируют... ну например контроль типов.

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

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

Pzz>Боюсь, что эти сложившиеся практики способствуют снижению качества программистов. Не попасть бы нам в замкнутый круг, когда практики будут подстраиваться под плохих программистов, еще больше снижая их качество и т.д.
Мне так не кажется. К примеру, плохой программист напишет плохой код как и продуктового куска, так и юнит-теста, но всё-таки шансы, что он случайно юнит тест напишет такой, что поймает ошибку реализации или регрессию в будущем, есть.
Какие "модные" практики ты видишь такие, что ухудшают качество программистов? Именно практики как таковые, а не их догматическое и чисто формальное использование. Вот так, чтоб практику отменить — и программисты стали лучше.

Pzz>Опенсорс бывает разный. У libtiff огромная пользовательская база, и написан он вполне приличным и уважаемым человеком. А код там такой, что хочется его развидеть, пока глаза не отвалились.
Ну вот я его заверну аккуратно, чтобы ворнингами не сыпало, и буду пользоваться. Большая пользовательская база такой низкоуровневой хрени — это уже некая гарантия качества (на уровне предоставляемого функционала). Что там внутри меня мало интересует до тех пор, пока мне не нужно будет колупаться в исходниках.

Pzz>Ну, я тоже примерно так услышал. Ну или не "устраивает", а "приходится с этим как-то уживаться". Организационно может быть трудно навести там порядок, мы ж не знаем его обстоятельств.
Ну вот если бы хоть намёк на "приходится". Пока что я видел только аргументы в пользу "бусть будет, как было, мне норм".

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

R>А если это мнение не совпадает с твоим, значит, враги.

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

Пытаешься выяснить у человека обстоятельства, а он тупо отморозился и все. Остаешься в недоумении: а тему-то зачем открывать, если затем сходу в кусты и не отсвечиваешь?

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

Pzz>Ну а как люди пишут крупные системы на JS или Питоне? Там с проверками еще сильно хуже.

С какими именно проверками?
Так-то JS и Python -- это языки со строгой типизацией, в отличии от C или C++.
В них по ошибке строку невозможно выдать за double.

А именно крупные системы пишут с трудом и за счет тотального тестирования. Не зря же сама мода на unit-тестирование в индустрию пришла из extreme programming, который возник из опыта разработки большого проекта на динамически-типизированном SmallTalk.

Плюс к тому, в чисто-динамические в прошлом языки либо добавляют опциональные аннотации типов (как в Python), либо делают ответвления в сторону (как в TypeScript).

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

Pzz>>При всём при том, многие из них родились совсем недавно. И до их появления как-то же люди умудрялись программы писать.
Pzz>>Например, к тому времени, когда придумали code review, я написал уже не один десяток тысяч строк вполне работоспособного софта. А сейчас код без ревью считается говнокодом.
_>Количество кода и программистов выросло, а качество программистов — наоборот, это нужно учитывать в практиках.

Я бы добавил еще несколько факторов:

— в 1970-х и 1980-х количество кода, приходящегося на одного разработчика в проекте, было сильно поменьше нынешнего, да и сами проекты очень сильно выросли в объемах с тех пор;

— сейчас уровень переиспользования кода и объем использованных в проекте сторонних зависимостей кардинально увеличился. Грубо говоря и ты сам полагаешься на код, в который даже не заглядываешь никогда, и точно так же полагаются на твой код. Причем когда чужой код переиспользуется, то нередно он переиспользуется так, как автору и не снилось;

— за последние 40 лет было сильно размыто понятие "владелец" кода. Еще в начале-середине 1990-х, особенно на обломках СССР, нормальным было явление, когда за каждым членом команды был закреплен свой кусок кода, в который никто больше не заглядывал, то сейчас ситуация принципиально иная. Ты написал какой-то модуль, через неделю в нем уже куча правок от десятка коллег, а через месяц его куски растащили по другим местам проекта, а оставшуюся часть основательно переделали;

— программисты стали гораздо чаще менять места работы и переходить из одной предметной области в другую. Сегодня ты склеиваешь картинки и наносишь на них водяные знаки, завтра пишешь бэкенд для Интернет-магазина, послезавтра сапортишь in-memory database.

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

PS. Все перечисленное в дополнение к вашим доводам, а не попытка с вами поспорить.

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

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

S>Пытаешься выяснить у человека обстоятельства, а он тупо отморозился и все. Остаешься в недоумении: а тему-то зачем открывать, если затем сходу в кусты и не отсвечиваешь?

Только поулучается: "Мне стало скучно, поэтому пойду подниму эту же тему в другом месте".

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

A>Миссионеры бывают не только религиозные, миссионеры бывают так же и компьютерные.
A>И чаще всего они пропагандируют какую-нибудь дурь. (Я имею в виду не только христиан).

A>Ну вот например, они пропагандируют...

Из разговра с вами стало понятно, что ряд нововведений в С++ вы считаете бесполезными.

А вот каково ваше отношение к [[nodiscard]]?

Можно предположить, что "нормальные программисты" (tm) никогда не игнорируют возвращаемые функциями/методами значения. И посему [[nodiscard]] -- всего лишь бесполезный "синтаксический оверхэд" (c)

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

S>А вот каково ваше отношение к [[nodiscard]]?
Так очевидно же. nodiscard же только генерирует предупреждения в случае чего, а предупреждения "мы" игнорируем.