на code review

код ревью это хорошо но нужно чтобы в этом процессе человек участие принимал по минмуму и тем более не делал это ручками.

но оно и надо не каждый день.

лично мне эта фича нужна прямо таки, каждый день.

но есть же ведь шред?

Статистический анализатор кода

PVS Studio например

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

и контроль ресурсов

Вот например жава может в контроль памяти, потому что в ней есть гц. А в контроль памяти С++ не может, потому что я могу написать int* v = new int[20]; v = NULL; и контроль потерян. Вместе с контролем памяти ломается попытка контроля всего остального.

а надежность это вопрос скорее техник разработки и тестирования.

так в этом же всё и дело, сколько эта разработка и тестирование занимает.

За деревьями леса автора так и не нарисовал, к сожалению. Причины лежат немного выше конкретных примеров — в идеологиизаложенной авторами С++ и комитетчиков.

Самая первая причина — возраст и зоопарк стандартов(цэ, цэ с классами, 03, 11, 14, 17, 20). Вводя n фич к языку из m фич мы получаем n * m вариантов взаимодействия новых фич со старыми, в С++, перегруженным фичами, эта область взаимодействия вряд ли просматривается полностью комитетчиками, а рядовыми программистами полностью. Учитывая что плюсики это язык в который всё вбрасывают и ничего не выбрасывают, область теневая там достаточно больших размеров.

Вторая причина — отсутствие максимального усложнения написать программу неправильно. Язык, программы на котором претендуют на надёжность должен исключать наиболее широкие классы ошибок. С++ этого делать даже не пытается, а в некоторых местах подначивает к ошибкам. В частности, любые попытки рассуждать о поведении программы ломаются если у вас есть в программе хотя бы одно UB, потому что это самое UB может сотворить что угодно без любой возможности это формально предсказать. Вместе с этим в С++ компиле нету UB-чекера. Вместе с этим в С++ нет ещё много каких чекеров — от детектора блокировок до прувера того что память не потекла, и это фатальный недостаток. Как следствие — discipline driven development(борьба с языком) это просто единственная возможная стратегия написать что — то возможное.

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

Это основные причины — очень много чего — их следствия.
И да языки, в которых эти все недостатки редуцированы до минимума — есть.

Вектор — элемент векторного пространства. Давать его таким образом как вы — невозможно. Следовательно, слово вектор сюда категорически не годится.

Ох любят слово вектор тулить куда надо и не надо.

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

Ну, в таком случае, делаете очень полезное дело.

Ещё бы это под пингвина портировать, винда в разработке на чём то кроме MS технологий малополезна.

это что-то новенькое.

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

www.askdifference.com/seniour-vs-senior, так тоже можно.

Олег Нижник писал, думаю это будет чуть более простым и понятным. habr.com/ru/post/325874

Ровно до тех пор, пока тебе не доверили программить действительно сложные объекты и процессы.

Прикол в том что моему тулингу по барабану сколько там переменных в конфиге, что 100 что 1000. Время компиляции будет дольше, да и всего то.

и ты можешь сделать или по канонам бюрократии, раскидав всё на 100500 абстракций, и собирая потом баги десятилетиями

Это в вашей джавке где у разрабов рантайм головного мозга и «сложные системы типов для задротов» это основная парадигма разработки. Мой тулинг позволяет держать всё в куче даже если оно распилиено.

раскидав всё на 100500 абстракций,

что данные и управляющий код

это с точки зрения погромиста одно и то же. Int, Int => Int, Kleisli[F, Foo, Bar] это просто термы, у них жизненный цикл это с момента написания погромистом до момента стирания. Одержимость вот этим вашим «а как оно там себя поведёт рантайме» явный признак того что абстракции вашей системы погроммирования не просто протекают, а фонтанируют. Объект/класс это ровно такой же терм как и все остальные, и он тоже никак себя не ведёт.

но для человека оно лежит в одном месте

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

бюрократы над своими системами правильных правильностей

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

Подивися свої класи з іменами *settings*

таких нету, звиняй, а если ты про конфиги,то во первых это простая АДТ без наследования побитая на секции для удобства девопсинга, а во вторых, пюрконфиг и никакого

найбільші маразми

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

Наличие единичного/нулевого объекта во множестве делает его значительно лучше и удобнее.

Тратить на розбирание «по предложениям»

я сделал за тебя, верхний коментарий.

Бо якщо починати розкидати функціонал по лісу абстракцій, то для читабельності коду знадобиться документації вчетверо більше ніж сам код. А от підтримка її цілісності — то адище, на відміну від коду, який легко рефакториться.

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

з точки зору ООП, та читабельності коду, заради якого власне ООП і створене.

готов поспорить про то что ООП лучше всего с этим справляется, в том тулинге в котором его используют.

Ключове правило: клади все до купи, ПОТІМ рефактори

ПОТОМ СТРАДАЙ выясняя какого хрена у тебя в этом классе из 80 полей и 300 методов случается фигня.

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