А инженер на это ответит, что не нужно бездумно механически вычищать антипаттерны в местах, которые даже близко не являются нагруженными/генерирующими техдолг/иным образом причиняющими ущерб.
Систему новую и более лучшую, чем демократия, не нашли. Новых и более лучших (в зависимости от обстоятельств) языков программирования со времён C++ придумано достаточно -- аналогия некорректна. Применение широко известных цитат к какому-либо другому явлению (как сделали вы) заявляет об уверенности автора в его суждении.
Сказав "С++ это язык именно программирования, именно для программистов, а не для физиков, лириков. Программисты должны понимать откуда взялся, что значит, и почему он именно static, например" (выделение моё) вы проводите соответствие: пишет на C++ -- программист, не на C++ -- не программист. При том, что второе может быть верно, и языки "для физиков" тоже есть, вы утверждаете, что нет языков программирования, при работе с которыми "программисты должны понимать откуда взялся, что значит, и почему он именно static, например", и забываете тех, кто знает теорию, но может на C++ и не писать.
резко
Забыл слово "уверенно". Подбирал по значению "не оставляя простора для возражений, градаций; деля на 'настоящих' и 'ненастоящих'".
Не нужно думать раз язык что-то позволяет, то ним так и пользуются
Язык должен допускать как можно меньше возможностей сделать что-то не так -- это одно из свойств, определяющих, насколько язык хорошо или плохо спроектирован. Подумайте, почему на разных проектах используют линтеры, более строгие флаги компилятора, почему в Python завезли аннотации типов и инструменты для статического анализа, а вместо JavaScript во многом сейчас пишут на TypeScript.
Вот и аргумент "никогда так не делайте". Этот фрагмент кода опровергает 'примитивно, означает что всё прозрачно и понятно, "Если вам нужно сделать шаг вперёд, вы просто его делаете, вам не нужно делать кульбит", С++ как раз про это'; также показывает неочевидность синтаксиса -- кто подумает, что (x) и x это семантически разные вещи.
примитивно, означает что всё прозрачно и понятно, "Если вам нужно сделать шаг вперёд, вы просто его делаете, вам не нужно делать кульбит", С++ как раз про это
Это, может быть, про Си, но не про C++:
decltype(auto) foo() {
int i = 1;
return (i); // UB
// return i; // Нет UB
}
Обычно на все трудности С++ ответом является: программист должен это знать/никогда так не делайте и т.п., но эти аргументы верны для любого языка программирования вообще, так как представляют себе "бесконечно опытного" программиста и игнорируют необходимость обучения и то, что дизайн языка бывает более или менее качественным.
Вот функция читает с файла, если не смогла прочитать, возвращает код ошибки, она не пытается сама завершить весь процесс и т.п.
Ответственно заявляю, что в Rust именно такой подход и принят, и поддерживается он сильно в большей степени, чем в C++, так как в Rust изначально были Result и Option, синтаксический сахар, pattern matching и прочее, до чего C/C++ с errno и его аналогами и out-параметрами как до Луны, а std::optional и std::expected поддерживаются слабо.
Вот сама идея функции: данные из вне могут быть, а могут и нет, выполняет некий код, и есть возможность вывода данных. Всё. Больше ни каких прикруток не нужных. Проще уже не сделать, а попытки псевдо-оптимизации путём прикручивания каких-то там состояний после выполнения функций, зачастую делают только хуже.
?
<...> ВСЁ. Что вы туда запихнуть пытаетесь? Если ничего, так зачем порождать миллион языков, которые что то там пытаются?
Если вы довольны С++, то вас никто не убеждает перейти на что-то другое, но не вступайте тогда в дискуссии, если не интересуетесь темой обсуждения.
Каждый, кто перепечатывает новости, где медийные личности что-то (в который раз уже) говорят, не беря на себя конкретных обязательств, держат аудиторию за дураков;
Каждый, кто серьёзно обсуждает подобные инфоповоды -- дурак.
Немного не-нейтрально, но достало уже, каждый божий день одно и то же.
Ну да, если простая обёртка выглядит криво, то функция со сложной логикой точно будет хорошо.
Гениально.
(Выделение моё) Не "точно" -- из "обёртка -- криво" не следует "сложная логика -- хорошо", но! из "обёртка -- криво" не следует "сложная логика -- криво". Если вы хотите сравнить качество двух языков, то сравнивайте их на наборе примеров и использований, которые соответствуют их применениям в реальности.
"Во-вторых, ясное дело, что если вы будете вызывать из языка, где принято использовать другие, не Си-подобные приёмы, тонкую обёртку над сишной функцией, у вас будет некрасивый обвязочный код."
"Во-вторых, ясное дело, что если вы будете вызывать из языка"
что вызывать то?
(Выделение моё)
"где принято использовать другие, не Си-подобные приёмы"
А почему? Си-язык, возник для удобств, что бы на ассемблере не строчить, и ни кто после ассемблерных мнемоник не хотел перегружать язык кучей лишних символов. То есть си-стайл уже сам по себе имеет девиз "Просто и логично" , но нет надо ведь всё испортить
Не "просто и логично", а скорее "примитивно". Язык программирования обязан не только отражать намерения разработчика в машинный код, но и обеспечивать, по мере своих сил, поддерживаемость, безопасность кода и т.п.
Защищать Rust легко, так как это новый язык, у которого была возможность учесть весь опыт других языков, но вы к этому аргументу не аппелируете.
но нет надо ведь всё испортить
Это вы про C++?~
"тонкую обёртку над сишной функцией, у вас будет некрасивый обвязочный код"
Ну да, конфета плохая не из-за производства, а из-за фантика, я вас понял.
Это я повторно ответил, потому что вы теперь отпираетесь и говорите что я вас не так понял.
Некрасивый обвязочный код, сугубо из-за того что сам язык такой
Что было: в коде на Rust функции из C++ вызываются некрасиво; Ваше обобщение: в коде на языке X функции из языка Y вызываются некрасиво => X -- плохой язык.
Проведите мысленный эксперимент, в котором вы из C/C++/любого другого языка вызываете код на Rust/Python/Java/любого другого языка, и поймите, почему такой подход неверен.
Ну то есть, вы буквально говорите, что если не си-подобный приём, то будет не красиво.
Я такого не говорил ("Вот сразу видно любителей C++ и т.п. У них проблемы с логикой"), я писал, что вызовы из одного языка программирования функций из другого языка программирования обречены иметь бойлерплейт и прочий некрасивый код. Вы же из одного такого примера пытаетесь вывести, что весь Rust плохой, а C++ хороший.
ДА ПРИ ЧЁМ ТУТ ПАМЯТЬ, ЧТО ВЫ К НЕЙ ПРИСТАЛИ, ЭТО ПРОСТО КАК ПРИМЕР.
Успокойтесь, к памяти никто не приставал, я даже этого слова не писал. Вместо WriteProcessMemory могло быть большинство других сишных функций, и все аргументы остались бы действительны.
У них проблемы с логикой
Это у вас проблемы, по одному нишевому примеру судить о всём языке.
Действительно, ведь 95% целевой аудитории занимаются только тем, что пишут в память других процессов на Win32.
Функция на Rust сразу даёт информацию об успешности завершения и возвращает информацию об ошибке, если есть, когда как в C++-версии это придётся делать вызываемому коду. Во-вторых, ясное дело, что если вы будете вызывать из языка, где принято использовать другие, не Си-подобные приёмы, тонкую обёртку над сишной функцией, у вас будет некрасивый обвязочный код.
Мне так нравится эта наивная вера некоторые разработчиков, которые уверенно заявляют, что они-то вот настоящие инженеры, которых не уволят из-за ИИ. А других обязательно уволят, потому что они липовые программисты, так как не знаю особенности рандома.
На деле рыночек порешает всех по своим правилам, которые заранее нам знать не суждено. Но последние года до бума айти в среднем по больнице скорее смузихлёб на JS зарабатывал куда больше по сравнению с "настоящим" инженером на C/C++
А какой менеджер дал @WaveLength не тот инструмент?
Яндекс.Заправкам много лет.
Пошли менять и прошли мимо.
Кагбэ у неё и другие конкуренты есть.
xxx: Пробовали вчера эти ваши электроинструменты, сверлили бетон, не вышло ни фига...
yyy: Вы же перфоратором сверлили, а не шуруповёртом?
Wesha: «Ты просто не ставишь пять линий после вишни — вот и не выигрываешь! ©
А инженер на это ответит, что не нужно бездумно механически вычищать антипаттерны в местах, которые даже близко не являются нагруженными/генерирующими техдолг/иным образом причиняющими ущерб.
Систему новую и более лучшую, чем демократия, не нашли. Новых и более лучших (в зависимости от обстоятельств) языков программирования со времён C++ придумано достаточно -- аналогия некорректна. Применение широко известных цитат к какому-либо другому явлению (как сделали вы) заявляет об уверенности автора в его суждении.
Сказав "С++ это язык именно программирования, именно для программистов, а не для физиков, лириков. Программисты должны понимать откуда взялся, что значит, и почему он именно static, например" (выделение моё) вы проводите соответствие: пишет на C++ -- программист, не на C++ -- не программист. При том, что второе может быть верно, и языки "для физиков" тоже есть, вы утверждаете, что нет языков программирования, при работе с которыми "программисты должны понимать откуда взялся, что значит, и почему он именно static, например", и забываете тех, кто знает теорию, но может на C++ и не писать.
Забыл слово "уверенно". Подбирал по значению "не оставляя простора для возражений, градаций; деля на 'настоящих' и 'ненастоящих'".
Он искуственный, да. https://habr.com/ru/articles/350186/comments/#comment_10693598
Язык должен допускать как можно меньше возможностей сделать что-то не так -- это одно из свойств, определяющих, насколько язык хорошо или плохо спроектирован. Подумайте, почему на разных проектах используют линтеры, более строгие флаги компилятора, почему в Python завезли аннотации типов и инструменты для статического анализа, а вместо JavaScript во многом сейчас пишут на TypeScript.
Вывод: если вы не имеете оснований считать, что исследовали тему, не высказывайте своё мнение так резко. /thread
Вот и аргумент "никогда так не делайте". Этот фрагмент кода опровергает 'примитивно, означает что всё прозрачно и понятно, "Если вам нужно сделать шаг вперёд, вы просто его делаете, вам не нужно делать кульбит", С++ как раз про это'; также показывает неочевидность синтаксиса -- кто подумает, что
(x)иxэто семантически разные вещи.Это, может быть, про Си, но не про C++:
Обычно на все трудности С++ ответом является: программист должен это знать/никогда так не делайте и т.п., но эти аргументы верны для любого языка программирования вообще, так как представляют себе "бесконечно опытного" программиста и игнорируют необходимость обучения и то, что дизайн языка бывает более или менее качественным.
Ответственно заявляю, что в Rust именно такой подход и принят, и поддерживается он сильно в большей степени, чем в C++, так как в Rust изначально были Result и Option, синтаксический сахар, pattern matching и прочее, до чего C/C++ с errno и его аналогами и out-параметрами как до Луны, а std::optional и std::expected поддерживаются слабо.
?
Если вы довольны С++, то вас никто не убеждает перейти на что-то другое, но не вступайте тогда в дискуссии, если не интересуетесь темой обсуждения.
Carbon уже есть. Не взлетел.
Скрытый текст
Также нету в топ-50 в https://innovationgraph.github.com/global-metrics/programming-languages.
Каждый, кто перепечатывает новости, где медийные личности что-то (в который раз уже) говорят, не беря на себя конкретных обязательств, держат аудиторию за дураков;
Каждый, кто серьёзно обсуждает подобные инфоповоды -- дурак.
Немного не-нейтрально, но достало уже, каждый божий день одно и то же.
(Выделение моё) Не "точно" -- из "обёртка -- криво" не следует "сложная логика -- хорошо", но! из "обёртка -- криво" не следует "сложная логика -- криво". Если вы хотите сравнить качество двух языков, то сравнивайте их на наборе примеров и использований, которые соответствуют их применениям в реальности.
(Выделение моё)
Не "просто и логично", а скорее "примитивно". Язык программирования обязан не только отражать намерения разработчика в машинный код, но и обеспечивать, по мере своих сил, поддерживаемость, безопасность кода и т.п.
Защищать Rust легко, так как это новый язык, у которого была возможность учесть весь опыт других языков, но вы к этому аргументу не аппелируете.
Это вы про C++?~
Что было: в коде на Rust функции из C++ вызываются некрасиво;
Ваше обобщение: в коде на языке X функции из языка Y вызываются некрасиво => X -- плохой язык.
Проведите мысленный эксперимент, в котором вы из C/C++/любого другого языка вызываете код на Rust/Python/Java/любого другого языка, и поймите, почему такой подход неверен.
Я такого не говорил ("Вот сразу видно любителей C++ и т.п. У них проблемы с логикой"), я писал, что вызовы из одного языка программирования функций из другого языка программирования обречены иметь бойлерплейт и прочий некрасивый код. Вы же из одного такого примера пытаетесь вывести, что весь Rust плохой, а C++ хороший.
Успокойтесь, к памяти никто не приставал, я даже этого слова не писал. Вместо WriteProcessMemory могло быть большинство других сишных функций, и все аргументы остались бы действительны.
Это у вас проблемы, по одному нишевому примеру судить о всём языке.
Только обычно логики 90%, а бойлерплейта 10% (условно), в вашем примере 0% и 100% соответственно.
Вы тут де-факто на Си пишете. Почему указатель + длина, а не std::span?
Мысль гласит, что это ради того, чтобы не было несколько способов делать одно и то же. К тому же, много новых языков уже выбрали такой способ:
https://habr.com/ru/articles/532660/comments/#comment_22487588 (также https://habr.com/ru/articles/532660/comments/#comment_22487564, https://habr.com/ru/articles/532660/comments/#comment_22488240)
Действительно, ведь 95% целевой аудитории занимаются только тем, что пишут в память других процессов на Win32.
Функция на Rust сразу даёт информацию об успешности завершения и возвращает информацию об ошибке, если есть, когда как в C++-версии это придётся делать вызываемому коду. Во-вторых, ясное дело, что если вы будете вызывать из языка, где принято использовать другие, не Си-подобные приёмы, тонкую обёртку над сишной функцией, у вас будет некрасивый обвязочный код.
via https://habr.com/ru/articles/1047890/comments/#comment_30177360
Интересно будет послушать ваш анализ Rust, почему он не "именно язык программирования для программистов".
Шедевр