Вы знаете, Ваша необоснованно резкая реакция на вполне спокойные доброжелательные вопросы визави мне видятся как раз примером такой глупости, про которые Вы говорите...
По существу обсуждения: мне кажется, по мелким бытовым ситуациям мелкие глупости мало на что влияют, и предотвращение их дороже последствий от них. А крупных глупостей, которые можно было предотвратить поверхностным обдумыванием, по моим наблюдениям, большинство людей в своей жизни совершает немного. В основном серьёзные ошибки связаны с неопределённостью ситуации или с затратностью правильного варианта...
Да, и это как раз фишка языка - минимизировать количество способов выстрелить себе в ногу. Часто считают, будто Rust характерен только системой владения памятью, но на самом деле использование безопасных подходов для работы с памятью - это всего лишь один из элементов (хоть, безусловно, и самый заметный) общей стратегии.
Так, ещё в Rust нет goto. А ведь оно тоже, наверное, "иногда надо, иногда нет"?
Я думаю, коллега подразумевал, что "нормальное наследование" - проблемная штука. Как goto, типа. Вспомните Банду четырёх, в частности: "Favor object composition over class inheritance". Такое наследование - удобный инструментарий, чтобы "выстрелить себе в ногу", и написать код, который сложно поддерживать и развивать.
В ранних версиях Rust'а было наследование в том смысле, который Вы вкладываете. От него сознательно отказались.
А так, наследование в духе интерфейсов в Rust'е есть.
"Деконструктор"? Вы, наверное, имели в виду "деструктор"? Ну, конечно же, RAII - это не сборщик мусора, но автоматическое освобождение ресурса по выходу связанных с ним идентификаторов из области видимости - это самое близко к сборке мусора, что я смог найти, размышляя над Вашей шуткой.
То, что под сборкой мусора Вы подразумевали алгоритм, выявляющий ошибки программиста, простите, не догадался, и даже после Вашего объяснения эта Ваша мысль мне кажется слишком сильно натянутой на глобус совой...
А единственный явный плюс у RUST, который выделяют это Borrow Checker . Ну то есть снова кто-то не осилил указатели и пошёл писать очередной сборщик мусора, но продвинутый.
У меня для Вас то ли страшная, то ли прекрасная новость: Borrow Checker - это не сборщик мусора ни в каком виде - ни продвинутый, ни отсталый. Его задача - не давать некорректно работать с памятью, а не мусор собирать.
А RAII в Расте есть, конечно, куда ж без него, только прямого отношения к Borrow Checker это не имеет. RAII и в C++ есть...
Во-первых, "Бить по морде на кодревью" это не то же самое что "автоматически отклонять компилятором". Если нет автоматического отклонения, можно что-то пропустить. Ну, для этого, конечно, есть всякие линтеры и прочее, которые обеспечивают выполнение требований по стилю кода, но это менее эффективно, чем прямое отклонение компилятором.
Во-вторых, всем приходится изобретать свои "велосипеды", придумывая, какое подмножество языка разрешать, а какое запрещать. Это порождает фрагментацию экосистемы - и в смысле кода, и в смысле навыков сотрудников (устраивающийся на работу должен будет знать все варианты, которые могут прийти в голову собеседующему, например). Это же касается и использования внутренних библиотек, компенсирующих какие-то недостатки стандарта - про это в статье упомянуто, см. "// антипаттерн: «мне надоело писать static_cast»"; локальные руководства по стилю тоже порождают подобное, в общем-то, хоть и в меньшей мере.
В-третьих, эти локальные требования по стилю кода не решают вопрос неудачных названий и конструкций.
Так что опыт Rust с его редакциями, на мой взгляд, для C++ мог бы быть полезен.
Упоминая Rust, почему-то не вспоминают, как там решена задача обеспечения обратной совместимости. А ведь в контексте этой статьи это как раз самое интересное!
Там используются так называемые "редакции": это не имеющие полной совместимости сверху вниз версии языка. Просто для программы указывается, на какой редакции языка она написана. Для отдельных компонентов можно указать другую редакцию. Поэтому устаревшие конструкции из языка выпиливаются или модернизируются, не ломая совместимость с махровым легаси.
Если программист пишет на современном Расте (Rust 2024), ему в подавляющем большинстве случаев не нужно знать, что там было в Rust 2015.
В целом, вполне себе возможная стратегия и для будущих вариантов C++, в общем-то, на мой взгляд...
А подскажите, пользователь РуСтора даёт информированное согласие на такое использование его данных о геолокации? Есть ли где-нибудь обязательство не использовать их для других целей? Есть ли возможность в настройках убрать эту опцию?
Ох. Будущее ближе, чем кажется. Я, когда писал, примерно такое и прогнозировал на будущее, а оказывается - уже... Ужас. Я допускал, что смотрю излишне пессимистично - а оказывается, излишне оптимистично...
Вообще говоря, Вы, если бы были автором, могли бы потребовать прекращения продаж - скомпенсировав все связанные с этим убытки. С введённым в гражданский оборот уже ничего не сделать, да, но хочется надеяться, ещё не дошло до того, чтобы и за это судить...
Увы, остаётся только взять жилетку и тихо плакать в неё.
А ещё больше хочется плакать от того, что пролиферирующие анальные зонды - повсюду. Банковские приложения самых разных банков; магазины приложений Гугла, Хуавея и Самсунга тоже собирают больше, чем нужно пользователю. И т.д..
Как бы использование GrapheneOS и F-Droid не стало квалифицироваться как "склонен к побегу" (из цифрового концлагеря) с де-факто поражением в правах.
С другой стороны, какой смысл о чём-то говорить после того как почти все мы добровольно и с песнями стали носить с собой персональных шпионов в виде смартфонов...
И иероглифы - тоже не полная чушь. " 城破在即，城里的妇女问她们的丈夫" переводится Яндекс.Переводчиком как "город был готов взорваться, и женщины в городе спросили своих мужей".
Вы правы, стоит показать и обсудить. Я не очень удачно выразился. Я не имел в виду, что нужно молчать в тряпочку. Я подразумевал, что регулярное гыгыгыкань "а, какие лохи, а, какая тупая дыра" в отношении достаточно рядового недостатка (которым, как выяснилось, в целом обладает и Telegram) приведёт к избыточной реакции. Какой-нибудь начальник какому-нибудь менеджеру укажет на это гыгыгыканье, скажет исправить, и тот организует исправление с большим запасом, закрыв, обфусцировав, поставив микроскопические таймауты и параноидальное отслеживание фингерпринтов, которые будут создавать кучу проблем пользователям, но зато себя этот менеджер на будущее прикроет полностью, и начальнику отчитается.
Но к Вас у меня претензий нет. Вы правильно написали, и тон в статье выдержали корректный. Я за то, чтобы делиться информацией и обсуждать. Спасибо!
Это Вы говорите про результирующий код программы. Там, да, во многих случаях абстракции системы типов не приводят к разрастанию программы. Но коллега говорит о размере и сложности компилятора, а не скомпилированной программы. Компиляторы 60-х были куда проще современного компилятора Rust.
Вот опять Вы выразились так, что уверенно понять Вас невозможно.
Вам режет безграмотное употребление английских слов вместо принятой в русском языке передачи названий? Ну, тогда чего Вы со мной спорите!
Или Вам режет глаз грамотная передача названий и Вы предпочитаете "The Pleiades" вместо Субару, и "Long March" вместо Чанчжэн из-за англофильства или чего-то подобного?
Или Вам режет глаз, когда кто-то пишет о том, что ему не нравятся ошибки, допущенные в русском языке? Ну так и высказали бы корректно мысль, что на данную ошибку можно и закрыть глаза, не париться особо, а не придумывать, будто визави что-то путает. А в конце и вовсе до чуть завуалированного хамства опустились. Фе!
Вы знаете, Ваша необоснованно резкая реакция на вполне спокойные доброжелательные вопросы визави мне видятся как раз примером такой глупости, про которые Вы говорите...
По существу обсуждения: мне кажется, по мелким бытовым ситуациям мелкие глупости мало на что влияют, и предотвращение их дороже последствий от них. А крупных глупостей, которые можно было предотвратить поверхностным обдумыванием, по моим наблюдениям, большинство людей в своей жизни совершает немного. В основном серьёзные ошибки связаны с неопределённостью ситуации или с затратностью правильного варианта...
Да, и это как раз фишка языка - минимизировать количество способов выстрелить себе в ногу. Часто считают, будто Rust характерен только системой владения памятью, но на самом деле использование безопасных подходов для работы с памятью - это всего лишь один из элементов (хоть, безусловно, и самый заметный) общей стратегии.
Так, ещё в Rust нет goto. А ведь оно тоже, наверное, "иногда надо, иногда нет"?
Я думаю, коллега подразумевал, что "нормальное наследование" - проблемная штука. Как goto, типа. Вспомните Банду четырёх, в частности: "Favor object composition over class inheritance". Такое наследование - удобный инструментарий, чтобы "выстрелить себе в ногу", и написать код, который сложно поддерживать и развивать.
В ранних версиях Rust'а было наследование в том смысле, который Вы вкладываете. От него сознательно отказались.
А так, наследование в духе интерфейсов в Rust'е есть.
"Деконструктор"? Вы, наверное, имели в виду "деструктор"? Ну, конечно же, RAII - это не сборщик мусора, но автоматическое освобождение ресурса по выходу связанных с ним идентификаторов из области видимости - это самое близко к сборке мусора, что я смог найти, размышляя над Вашей шуткой.
То, что под сборкой мусора Вы подразумевали алгоритм, выявляющий ошибки программиста, простите, не догадался, и даже после Вашего объяснения эта Ваша мысль мне кажется слишком сильно натянутой на глобус совой...
У меня для Вас то ли страшная, то ли прекрасная новость: Borrow Checker - это не сборщик мусора ни в каком виде - ни продвинутый, ни отсталый. Его задача - не давать некорректно работать с памятью, а не мусор собирать.
А RAII в Расте есть, конечно, куда ж без него, только прямого отношения к Borrow Checker это не имеет. RAII и в C++ есть...
Ну, по-моему, это всё же несколько другое.
Во-первых, "Бить по морде на кодревью" это не то же самое что "автоматически отклонять компилятором". Если нет автоматического отклонения, можно что-то пропустить. Ну, для этого, конечно, есть всякие линтеры и прочее, которые обеспечивают выполнение требований по стилю кода, но это менее эффективно, чем прямое отклонение компилятором.
Во-вторых, всем приходится изобретать свои "велосипеды", придумывая, какое подмножество языка разрешать, а какое запрещать. Это порождает фрагментацию экосистемы - и в смысле кода, и в смысле навыков сотрудников (устраивающийся на работу должен будет знать все варианты, которые могут прийти в голову собеседующему, например). Это же касается и использования внутренних библиотек, компенсирующих какие-то недостатки стандарта - про это в статье упомянуто, см. "
// антипаттерн: «мне надоело писать static_cast»"; локальные руководства по стилю тоже порождают подобное, в общем-то, хоть и в меньшей мере.В-третьих, эти локальные требования по стилю кода не решают вопрос неудачных названий и конструкций.
Так что опыт Rust с его редакциями, на мой взгляд, для C++ мог бы быть полезен.
Упоминая Rust, почему-то не вспоминают, как там решена задача обеспечения обратной совместимости. А ведь в контексте этой статьи это как раз самое интересное!
Там используются так называемые "редакции": это не имеющие полной совместимости сверху вниз версии языка. Просто для программы указывается, на какой редакции языка она написана. Для отдельных компонентов можно указать другую редакцию. Поэтому устаревшие конструкции из языка выпиливаются или модернизируются, не ломая совместимость с махровым легаси.
Если программист пишет на современном Расте (Rust 2024), ему в подавляющем большинстве случаев не нужно знать, что там было в Rust 2015.
В целом, вполне себе возможная стратегия и для будущих вариантов C++, в общем-то, на мой взгляд...
Более того: нет полной уверенности, что и случай-то удачный...
φ² + φ⁻² = (φ + 1) + 1 / ( φ + 1 ) = ( (φ + 1)² + 1 ) / ( φ + 1 ) = ( φ² + 2 φ + 1 + 1) / ( φ + 1 ) = ( φ + 1 + 2 φ + 1 + 1 ) / ( φ + 1 ) = (3 φ + 3 ) / ( φ + 1 ) = 3А подскажите, пользователь РуСтора даёт информированное согласие на такое использование его данных о геолокации? Есть ли где-нибудь обязательство не использовать их для других целей? Есть ли возможность в настройках убрать эту опцию?
Вы не только нейросеть, конечно, но биологическая нейросеть является Вашей очень существенной частью, очевидно.
Ох. Будущее ближе, чем кажется. Я, когда писал, примерно такое и прогнозировал на будущее, а оказывается - уже... Ужас. Я допускал, что смотрю излишне пессимистично - а оказывается, излишне оптимистично...
Вот бы туда добавить другие сторы - от Гугла, Хуавея, Сяоми, Самсунга, да и Аврору и даже F-Droid - было бы просто сказочно!
А есть прецеденты такого рода? Было бы интересно почитать мотивировку...
Вообще говоря, Вы, если бы были автором, могли бы потребовать прекращения продаж - скомпенсировав все связанные с этим убытки. С введённым в гражданский оборот уже ничего не сделать, да, но хочется надеяться, ещё не дошло до того, чтобы и за это судить...
Увы, остаётся только взять жилетку и тихо плакать в неё.
А ещё больше хочется плакать от того, что пролиферирующие анальные зонды - повсюду. Банковские приложения самых разных банков; магазины приложений Гугла, Хуавея и Самсунга тоже собирают больше, чем нужно пользователю. И т.д..
Как бы использование GrapheneOS и F-Droid не стало квалифицироваться как "склонен к побегу" (из цифрового концлагеря) с де-факто поражением в правах.
С другой стороны, какой смысл о чём-то говорить после того как почти все мы добровольно и с песнями стали носить с собой персональных шпионов в виде смартфонов...
И иероглифы - тоже не полная чушь. " 城破在即，城里的妇女问她们的丈夫" переводится Яндекс.Переводчиком как "город был готов взорваться, и женщины в городе спросили своих мужей".
Вы правы, стоит показать и обсудить. Я не очень удачно выразился. Я не имел в виду, что нужно молчать в тряпочку. Я подразумевал, что регулярное гыгыгыкань "а, какие лохи, а, какая тупая дыра" в отношении достаточно рядового недостатка (которым, как выяснилось, в целом обладает и Telegram) приведёт к избыточной реакции. Какой-нибудь начальник какому-нибудь менеджеру укажет на это гыгыгыканье, скажет исправить, и тот организует исправление с большим запасом, закрыв, обфусцировав, поставив микроскопические таймауты и параноидальное отслеживание фингерпринтов, которые будут создавать кучу проблем пользователям, но зато себя этот менеджер на будущее прикроет полностью, и начальнику отчитается.
Но к Вас у меня претензий нет. Вы правильно написали, и тон в статье выдержали корректный. Я за то, чтобы делиться информацией и обсуждать. Спасибо!
Это Вы говорите про результирующий код программы. Там, да, во многих случаях абстракции системы типов не приводят к разрастанию программы. Но коллега говорит о размере и сложности компилятора, а не скомпилированной программы. Компиляторы 60-х были куда проще современного компилятора Rust.
Вот опять Вы выразились так, что уверенно понять Вас невозможно.
Вам режет безграмотное употребление английских слов вместо принятой в русском языке передачи названий? Ну, тогда чего Вы со мной спорите!
Или Вам режет глаз грамотная передача названий и Вы предпочитаете "The Pleiades" вместо Субару, и "Long March" вместо Чанчжэн из-за англофильства или чего-то подобного?
Или Вам режет глаз, когда кто-то пишет о том, что ему не нравятся ошибки, допущенные в русском языке? Ну так и высказали бы корректно мысль, что на данную ошибку можно и закрыть глаза, не париться особо, а не придумывать, будто визави что-то путает. А в конце и вовсе до чуть завуалированного хамства опустились. Фе!