(не знаю, туда ли я пишу)

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

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

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

CK>(не знаю, туда ли я пишу)

....

Вот сейчас разгоняют Golang. Разрабам с рассуждениями, подобными Вашим, как раз стоит переходить на Golang. Там не получится написать сложно, это специально упрощённый ЯП для тех, кто не может или не хочет писать сложно. Это С++ для двоечников. Если для проекта нужно простота кода, пишите на Golang или python. Менеджерам, боящимся появления сложного кода в проекте, тоже стоит наставивать на использовании в проекте чего-то вроде Golang, это будет гарантия, что сложного кода в проекте не появится, независимо от того, "умные" там разрабы или посредственности. Но если проект всё таки пишется на С++, и дальше будет развиваться на том же самом, стоит писать именно на C++, используя все имеющиюся в нём возможности (если оно там есть, почему это не использовать?), а не ограничивая себя в возможностях только из-за страхов перед какими-то возможными сложностями в понимании кода, которые могут возникнуть у разрабов, которые недостаточно квалифицированы и/или трудолюбивы. Всё предельно просто.

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

S>Вот сейчас разгоняют Golang. Разрабам с рассуждениями, подобными Вашим, как раз стоит переходить на Golang. Там не получится написать сложно, это специально упрощённый ЯП для тех, кто не может или не хочет писать сложно. Это С++ для двоечников.

наверное приятно ощущать себя не двоечником?
проблема в том, что объективная реальность несколько отличается от этого. В объективной реальности, программист — просто обслуживает интересы бизнеса. Бизнес заинтересован в качестве, предсказуемости и поддерживаемости. Он не заинтересован получить проект, в который почти никто не может вносить правки, т.к. он сложный.

S>Но если проект всё таки пишется на С++, и дальше будет развиваться на том же самом, стоит писать именно на C++, используя все имеющиюся в нём возможности (если оно там есть, почему это не использовать?), а не ограничивая себя в возможностях только из-за страхов перед какими-то возможными сложностями в понимании кода, которые могут возникнуть у разрабов, которые недостаточно квалифицированы и/или трудолюбивы. Всё предельно просто.

"Проект", это в первую очередь люди, процессы и предматная область. Выразительность языка — дело десятое. У нас каждый кусок кода проходит ревью много раз. Вот представь, что ты пишешь сложный код (сложность которого именно в самом коде, как обычно бывает со сложным кодом, в конечном итоге он делает простую вещь). Этот код попадает на ревью и требует от ревьюера кучу времени и усилий. Этот цикл повторяется несколько раз, пока вносятся правки. Чем сильнее ты не совпадаешь с командой, тем больше чужого времени ты тратишь. Потом этот код попадает на финальное ревью, у нас его обязательно делают люди из другой команды (иногда из другого офиса, в другом часовом поясе). Поэтому умножай время потраченное на первое ревью на 10 Люди все достаточно квалифицированны для понимания любого кода на С++, но тут речь не столько про фичи, сколько про сложность. Если ты принимаешь решение сделать А, поэтом это приводит к тому что тебе нужно сделать Б, потом В и тд, то ревьюер вправе поставить под вопрос решение А, т.е. весь твой дизайн.

При всем при этом, мы еще не касались сложности, вызванной предметной областью (т.е. объективно существующей). Умнож сложность, которую ты привнес своим кодом на ту, что должна неизбежно появиться и попробуй прикинуть время, нужное для того, чтобы твой код попал в прод :D

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

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

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

S>проекте используется что-то сложное и богатое в плане возможностей, вроде C++. Если где-то на C++ пишут как на golang-е, то зачем там C++? Пишите сразу на golang.

С++ это С++98(С с классами), а не то, что из него потом сделал Страуструп. Новому языку следовало бы дать новое имя.

CK>Среди людей нашей профессии почему-то очень популярны следующие цепочки рассуждений: "я пишу сложный код, значит я умный", или "другие не могут понять мой код, знаичт я умнее их, они профнепригодны" и тд.
В наше время я с таким не сталкивался.
Мне так везло, что мы в команде друг-другу помогали разгрести...

CK>Самое печальное, что это влияет на рабочие отношения. Чувак, который тащится от сложности и тащит ее в общий проект и превознемогает, чаще всего не понимает что он делает что-то не то, при этом еще относится снисходительно к коллегам, которые так не делают. На фоне таких людей мы с остальными коллегами выглядим статистами (по крайней мере для таких людей). По факту, подобные адепты сложности почти не добавляют ничего в проект, постоянно что-то превознимогают, но потом оказывается, например, что несколько дней работы ушло коту под хвост только ради какой-то ерунды, которая никому не нужна. Как с такими быть?
Ну, Зуев в знаменитой статье про писание компилятора описывает как раз такого чувака.
А про фигню, которая никому не нужна, еще Брукс писал в Мифическом человеко-месяце — это 60-е годы...

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

LVV>А про фигню, которая никому не нужна, еще Брукс писал в Мифическом человеко-месяце — это 60-е годы...

Пусть оставят плюсовикам нишу разработки системообразующих универсальных либ, предоставляющих наружу простой интерфейс, aka boost libs, и клепают бизнес модели на python с поключением к нему С++-ных либ. Но если кто лезет в разработку на C++-соответствуй. Если какой чувак полезет в разрабы, скажем, boost::fusion, и, первым делом, начнёт возмущаться, что там написано сложно и не так, как ему хотелось бы, то его просто пошлют подальше, чтоб работать не мешал.

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

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

Да причем тут простой ЯП? Можно писать на С++ простой и поддерживаемый код с использованием всех его фич (пример — https://github.com/scylladb/seastar/tree/master/). Речь про то, что люди пишут нечитаемое/не поддерживаемое говно, потому что не могут иначе (не хватает опыта и навыков), либо чтобы потешить свое ЧСВ. Говно можнно и на golang написать (примеров очень много).

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

CK>Да причем тут простой ЯП? Можно писать на С++ простой и поддерживаемый код с использованием всех его фич (пример — https://github.com/scylladb/seastar/tree/master/).

Многие стенающие о "С++ с классами, который мы потеряли" категорически не согласятся увидев, например, такой код:

future<> connection::read() {
    return do_until([this] {return _done;}, [this] {
        return read_one();
    }).then_wrapped([this] (future<> f) {
        // swallow error
        if (f.failed()) {
            _server._read_errors++;
        }
        f.ignore_ready_future();
        return _replies.push_eventually( {});
    }).finally([this] {
        return _read_buf.close();
    });
}

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

lpd>С++ это С++98(С с классами), а не то, что из него потом сделал Страуструп. Новому языку следовало бы дать новое имя.

Просто для справки: Страуструп единолично отвечал за C++ года до 1990-го, после чего над C++ стал работать комитет, и C++98 -- является продуктом работы комитета. Не говоря уже о последующих стандартах. В комитете же Страуструп один из лидеров, но вовсе не диктатор.

И еще для справки: знаменитая "Modern C++ Design" от Александреску, которая, можно сказать, окончательно закопала "С с классами", базировалась только на возможностях из C++98. Т.е. метапрограммирование на шаблонах (открытое, кстати говоря, в 1994-ом) и вот это вот все шаблонное безобразие в C++ можно было черпать в C++98 полной ложкой. Настоящий же "С с классами" закончился в 1988-ом, когда появилось первое описание C++ных шаблонов.

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

CK>Да причем тут простой ЯП?

Это называется "не стрелять из пушки по воробьям". Если выбран C++, значит там нужны те его возможности, которых нет в других ЯП (ООП можно и на чистом Cи без проблем организовать). А то понапихали C++ .... ...... ........, и всякие локальные проектики, которые могли бы без проблем быть реализованы на чём-то попроще, типа python или java, а теперь боятся как бы кто там, не дай бог, не начал использовать какие-то его возможности, которые, видите ли, не всем могут быть понятны.

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

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

lpd>>С++ это С++98(С с классами), а не то, что из него потом сделал Страуструп. Новому языку следовало бы дать новое имя.

S>Просто для справки: Страуструп единолично отвечал за C++ года до 1990-го, после чего над C++ стал работать комитет, и C++98 -- является продуктом работы комитета. Не говоря уже о последующих стандартах. В комитете же Страуструп один из лидеров, но вовсе не диктатор.

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

CK> Как с такими быть?
Имхо, не заморачиваться.
Сложный код сам по себе не плохо и не хорошо. Проблемы могут быть, когда возникает сложночитаемый и сложноподдерживаемый код. Но даже это может быть оправдано (например, когда дает необходимый прирост скорости работы)
Может быть и сложный код, который достаточно хорошо прокомменчен и задокументирован.

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

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

S>Там не получится написать сложно, это специально упрощённый ЯП для тех, кто не может или не хочет писать сложно.

Самые простые языки, по своим возможностям — это ассемблер и BrainFuck. Минимум наворотов, ничего лишнего.

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

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

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

S>Это называется "не стрелять из пушки по воробьям". Если выбран C++, значит там нужны те его возможности, которых нет в других ЯП (ООП можно и на чистом Cи без проблем организовать). А то понапихали C++ .... ...... ........, и всякие локальные проектики, которые могли бы без проблем быть реализованы на чём-то попроще, типа python или java, а теперь боятся как бы кто там, не дай бог, не начал использовать какие-то его возможности, которые, видите ли, не всем могут быть понятны.

Одним словом, ты предлагаешь нам перестать писать СУБД на С++ и перейти на python?
Еще раз, возможности все понимают, речь про написание неоправданно сложного говнокода на С++ (который легко может быть и без шаблонов), можно и с шаблонами понятно писать (выше пример был). Просто обычно, когда С++ программист идет в разнос, без шаблонов не обходится (как говорится to add insult to injury). Люди пишущие на других языках справляются с задачей написание нечитаемого говна ничуть не хуже.

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

S>Многие стенающие о "С++ с классами, который мы потеряли" категорически не согласятся увидев, например, такой код:
S>

future<> connection::read() {
S>    return do_until([this] {return _done;}, [this] {
S>        return read_one();
S>    }).then_wrapped([this] (future<> f) {
S>        // swallow error
S>        if (f.failed()) {
S>            _server._read_errors++;
S>        }
S>        f.ignore_ready_future();
S>        return _replies.push_eventually( {});
S>    }).finally([this] {
S>        return _read_buf.close();
S>    });
S>}

А что смущает, лямбды? Это конечно добавляет сложности (особенно в отладке), но если делать на конечных автоматах и колбэках, получится сильно сложнее, КМК. Ну и плюс, у них весь фреймверк построен на futures/promises, поэтому те кто над ним работают, должны хорошо с таким кодом уметь работать.

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

CK>А что смущает, лямбды?

Тех, кто знаком с современным C++ ничего не смущает. Речь о тех, кто вместо современного C++ с шаблонами, лямбдами и прочей функциональщиной, предпочитает видеть "С с классами".

CK>Это конечно добавляет сложности (особенно в отладке), но если делать на конечных автоматах и колбэках, получится сильно сложнее, КМК.

Так ведь это типичная коллбэчная лапша и есть

CK>Ну и плюс, у них весь фреймверк построен на futures/promises, поэтому те кто над ним работают, должны хорошо с таким кодом уметь работать.

В том-то и дело, что те, кто напишут сложный код на современном C++, скорее всего, будут уметь с ним работать. А для кого-то другого такой код будет выглядеть как оверинжениринг и попытка выпендриться.

CK>Как с такими быть?

Объяснить, что код пишется один раз, редактируется раз 5, а читается иногда сотни раз. Поэтому всю эффективность разработки можно убить, написав трудно читаемый код.

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

S>Здравствуйте, chaotic-kotik, Вы писали:

CK>>(не знаю, туда ли я пишу)

S>....

S>Вот сейчас разгоняют Golang. Разрабам с рассуждениями, подобными Вашим, как раз стоит переходить на Golang. Там не получится написать сложно, это специально упрощённый ЯП для тех, кто не может или не хочет писать сложно.
Посмотри какой костыль они изобрели вместо дженериков, встретив такое впервые, можно и не понять что хотел аффтар.