Здравствуйте, VTT, Вы писали:
ARK>>Иначе — это, например, отказаться от ссылок на родителя. VTT>И как в таком случае будет выглядеть иерархия виджетов, хотя бы примерно? VTT>Информация о том, кто чей родитель должна же где-то храниться и быть доступна этим виджетам, чтобы обеспечить возможность прохождения событий (вызовов методов) вверх и вниз по иерархии.
Просто без ссылки на родителя. Что-то сделали, выставили нужное состояние/флаги и все. Не надо родителя дергать, он сам решит, когда ему что делать. Вверх по иерархии вызывать не надо. Только вниз.
VTT>Во-первых правило "одной мутабельной ссылки" для rc указателей работает только в рантайме. VTT>Если ресурс уже сдох или им владеет кто-то еще, то будет panic. VTT>Это вроде как безопасней чем разыменование нулевых указателей, но и вредно, так как контроль все равно лежит исключительно на разработчиках (которым они явно пренебрегают).
Ну, это вроде как хак для злобных буратино. По крайней мере эти штуки можно найти простым поиском по тексту.
VTT>Россыпи unwrap в расте похожи на настоящий антипаттерн.
С этим соглашусь. Но я бы предпочел явные россыпи unwrap неявным залежам NPE или неявной порче памяти в С/C++.
VTT>Во-вторых неявное копирование (или его отсутствие) в расте — это тихий ужас. VTT>Проявляется и при обычных вызовах методов типа foo(value) — нет никакой возможности определить, перемещается ли объект, или копируется. VTT>И во всяких хитрых вызовах, которые могут неявно сделать copy on write, типа make_mut.
Я что-то немного утерял нить разговора. Ну предположим, и что? Разве в С++ или C# в этом плане ситуация лучше? По-моему, гораздо хуже. Вот например, это же прекрасно — https://stackoverflow.com/questions/32009694/why-implicit-conversion-of-bool-to-string-isnt-an-error. А раз так, то какой смысл это упоминать?
ARK>>ИМХО, совершенно не обязан, ссылками можно и нужно обмениваться, а не прикапывать у себя. VTT>Чтобы обмениваться с кем-то ссылками, придется держать ссылки на тех, с кем хочется обмениваться.
Эээ, это зачем? Вот есть метод, у него на входе ссылка и на выходе ссылка. Никого он не держит.
VTT>И если постоянно обмениваться ссылками, то это как раз усложнит управление жизненным циклом.
Этот тезис необходимо обосновать. Мне кажется наоборот — что жизненный цикл в таком случае упрощается. Впрочем, формальных доказательств этого у меня нет.
VTT>Ну вот не надо винить одно исключение (причем вроде как корректно выброшенное) во взрыве ариан. VTT>Взрыв произошел из-за целой цепочки программных, технических и организационных недоработок, которые наложились друг на друга в роковой последовательности.
Согласен, но тем не менее это иллюстрирует тот факт, что исключения могут быть весьма разрушительны.
Была бы ситуация лучше, если бы вместо исключений были явно торчащие из кода сигналы ошибок (с формально доказанной "сердцевиной")? Трудно сказать. Во всяком случае исключения скрыты и их не видно, что явно безопасности не прибавляет.
VTT>Вообще приравнивать исключение (читай языковой механизм) к неконтролируемому рандому UB — это нонсенс.
С точки зрения оценки риска возможного ущерба — разницы нет. И то, и то потенциально может привести к катастрофе (не обязательно взрыв ракеты, но и, например, утечка конфиденциальных данных). Лично я именно это подразумеваю под безопасностью, а совсем не обязательно порчу памяти.
Здравствуйте, VTT, Вы писали:
EP>>Не путай макросы C++ и гигиеничные макросы типа Lisp/Nemerle. VTT>Я их не путаю. Детали реализации макросов, будь то просто подстановка текста, как в препроцессоре С, или более изощренные средства, не столь важны.
Таким образом C++ templates и C# generics — тоже макросы, только более изощренные. Сейчас представить каждое без соответствующего — врядли представляется возможным (например я бы не стал писать на C# без generics, а то время когда это делал — вспоминаю просто с ужасом). При чём в большинстве языков — проблема обобщения так или иначе решается (это намек в сторону Java и D).
В C++ — наряду вместе с шаблонами ходят парой и текстовые макросы, при чём, сомневаюсь, что без последних жизнь реально возможна (как минимум это способ параметризировать код при вызове компилятора). В C# кстати такое тоже есть, хотя и более ограниченно, и кстати тоже вполне используется.
Получается, что:
VTT> Ненужность макросов, как некого встроенного способа для кодогенерации в обход других языковых механизмов, всем известна.
Звучит как минимум странно. Мне вот известно, что "макросы" очень нужны, при чём — чем они изощреннее — тем лучше.
Здравствуйте, VTT, Вы писали:
VTT>Другая отталкивающая особенность языка — это макросы. VTT>Просто наглый способ прятать крякозябры. VTT>Причем отделаться от него практически невозможно.
Честно говоря, не совсем понял претензию. Кто мешает запретить на уровне соглашений проекта макросы? Или мешают именно стандартные? Чем?
Опять же, как нужно? Тупо писать больше мусорного кода? Макросы в расте пусть и корявы, но всё-таки явно лучше сишных — хотя бы из-за наличия гигиены.
VTT>Вполне толково расписано.
Похоже мы читали разные тексты. Я увидел претензии в духе "почему я не могу обращаться в интерфейсе к данным наследников" и "не осилил найти стандартную функцию forget".
VTT>Заявления про безопасность раста — брехня.
Такие заявления — брехня.
Здравствуйте, VTT, Вы писали:
VTT>Зато использования (прямого или косвенного) unsafe блоков в нем избежать практически невозможно.
Во первых, чем это плохо? В языках без явных unsafe блоков точно так же присутствуют "небезопасные моменты" (и всякие UB), просто они ещё и не сразу видны. Как по мне, явный unsafe — это преимущество: им можно (нужно) уделять больше внимания на ревью и т.д.
Во вторых, невозможность избежать явного использования unsafe несколько преувеличена.
VTT>В большинстве современных языков, таких как go, D, C#, Java, Haskell, макросы отсутствуют.
В Go даже шаблонов/дженериков нет, так себе пример для подражания. Зато из коробки есть кодогенерация (go generate) — чем она принципиально отличается от макросов? Тем что работает через "комментарии" и отдельную тулзу?
В D имеются продвинутые шаблоны, миксины и прочее CTFE. Результат по разрушительности мощности не сильно отличается.
Про Template Haskell, я так понимаю, ты тоже не слышал?
Для C# есть Roslyn, да и Nemerle не просто так появился.
VTT>Там, где макросы живут по историческим причинам (прежде всего в C/C++), их использование рекомендуется ограничить.
Это разные макросы.
Здравствуйте, VTT, Вы писали:
VTT>Даже один блок unsafe сразу переводит весь код в unsafe, т.е. прерывает цепочку накладываемых на код ограничений.
Ага, конечно. И джава ничуть не безопаснее С ведь где-то в глубине нативный код имеется.
Здравствуйте, fddima, Вы писали:
F> Таким образом C++ templates и C# generics — тоже макросы, только более изощренные. Сейчас представить каждое без соответствующего — врядли представляется возможным (например я бы не стал писать на C# без generics, а то время когда это делал — вспоминаю просто с ужасом). При чём в большинстве языков — проблема обобщения так или иначе решается (это намек в сторону Java и D). F> В C++ — наряду вместе с шаблонами ходят парой и текстовые макросы, при чём, сомневаюсь, что без последних жизнь реально возможна (как минимум это способ параметризировать код при вызове компилятора). В C# кстати такое тоже есть, хотя и более ограниченно, и кстати тоже вполне используется.
Не хило у вас все перемешано...
F>Мне вот известно, что "макросы" очень нужны, при чём — чем они изощреннее — тем лучше.
Пользуйтесь как можно больше.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, DarkEld3r, Вы писали:
DE>Честно говоря, не совсем понял претензию. Кто мешает запретить на уровне соглашений проекта макросы? Или мешают именно стандартные? Чем?
"Тут так принято". Это же не с/с++ где царит полнейший плюрализм.
DE>Опять же, как нужно? Тупо писать больше мусорного кода?
Ну собственно основная претензия к макросам и заключается в том, что они представляют собой способ прятать весь boilerpalte "под ковер".
Извольте писать помощников, рефакторить и гранулировать код надлежащим образом.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
DE>>Опять же, как нужно? Тупо писать больше мусорного кода? VTT>Ну собственно основная претензия к макросам и заключается в том, что они представляют собой способ прятать весь boilerpalte "под ковер". VTT>Извольте писать помощников, рефакторить и гранулировать код надлежащим образом.
Макросы в том числе помогают убрать тот boilerplate, который невозможно убрать/отрефакторить/etc другими средствами языка.
Ты же говоришь так, как будто для всех use-case'ов макросов есть альтернативы не уступающие по характеристикам.
Языки постоянно расширяются, в них добавляются новые реально полезные и необходимые фичи. Макросы позволяют реализовывать необходимые фичи как только появится потребность, не дожидаясь новой версии языка (есть конечно границы, но макросы существенно расширяют горизонт).
Если бы было так как ты говоришь, мол достаточно гранулировать и рефакторить "надлежащим образом" — то в языки и не добавлялись бы новые фичи
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Макросы в том числе помогают убрать тот boilerplate, который невозможно убрать/отрефакторить/etc другими средствами языка.
Они ничего не убирают, весь этот boilerplate так и остается там, где его оставили.
EP>Ты же говоришь так, как будто для всех use-case'ов макросов есть альтернативы не уступающие по характеристикам.
А какие у них есть характеристики? Короче записать? Не ошибиться в копипасте?
EP>Языки постоянно расширяются, в них добавляются новые реально полезные и необходимые фичи. Макросы позволяют реализовывать необходимые фичи как только появится потребность, не дожидаясь новой версии языка (есть конечно границы, но макросы существенно расширяют горизонт).
Давать пользователям возможность самим расширять синтаксис, мимикрируя конструкции, которые в будущем могут в похожей форме прийти в язык — крайне недальновидное решение.
Хотя для языков, прежде всего ориентированных на продуктивность — вполне обычное.
EP>Если бы было так как ты говоришь, мол достаточно гранулировать и рефакторить "надлежащим образом" — то в языки и не добавлялись бы новые фичи
К сожалению, чаще всего "фичи" добавляются просто в стремлении быть "данамично развивающимся языком", а не из рациональных соображений.
Во многих языках даже наоборот, скорее пора выкидывать фичи.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
VTT>Не хило у вас все перемешано...
Изложил все исключительно в вашей терминологии.
F>>Мне вот известно, что "макросы" очень нужны, при чём — чем они изощреннее — тем лучше. VTT>Пользуйтесь как можно больше. обобщения в виде generics, templates используются чуть менее чем везде где они доступны. Даже в C умудряются создавать общий код, но это реже и плата в рантайме понятна. Дурачка включать не надо.
Я был бы рад такому языку который бы мог компилировать мои мысли в понятные для других ЯП программы. Но таких пока не предвидится, так что все таки предпочитаю пользоваться тем немногим что есть.
Здравствуйте, VTT, Вы писали:
EP>>Ты же говоришь так, как будто для всех use-case'ов макросов есть альтернативы не уступающие по характеристикам. VTT>А какие у них есть характеристики? Короче записать?
Да. Причём "короче" может быть качественным понятием, а не количественным. Например генерация автомата из императивного по форме кода а-ля stackless await.
VTT>Не ошибиться в копипасте?
Да, этого мало?
EP>>Языки постоянно расширяются, в них добавляются новые реально полезные и необходимые фичи. Макросы позволяют реализовывать необходимые фичи как только появится потребность, не дожидаясь новой версии языка (есть конечно границы, но макросы существенно расширяют горизонт). VTT>Давать пользователям возможность самим расширять синтаксис, мимикрируя конструкции, которые в будущем могут в похожей форме прийти в язык — крайне недальновидное решение.
Это разруливается namespace'ами.
Да и например в Lisp вызов макроса по форме аналогичен вызову функции, так что тут пересечения с будущими возможными фичами не больше чем в случае с обычными функциями.
EP>>Если бы было так как ты говоришь, мол достаточно гранулировать и рефакторить "надлежащим образом" — то в языки и не добавлялись бы новые фичи VTT>К сожалению, чаще всего "фичи" добавляются просто в стремлении быть "данамично развивающимся языком", а не из рациональных соображений. VTT>Во многих языках даже наоборот, скорее пора выкидывать фичи.
Могу назвать реально полезные фичи в новых версиях всех mainstream языков. Наличие же плохих фич не говорит о том что на расширение в полезных направлениях нет спроса.
Здравствуйте, VTT, Вы писали:
EP>>Макросы в том числе помогают убрать тот boilerplate, который невозможно убрать/отрефакторить/etc другими средствами языка. VTT>Они ничего не убирают, весь этот boilerplate так и остается там, где его оставили.
В каком смысле? Этот boilerplate не нужно писать руками.
С тем же успехом можно сказать что современные языки ничем не лучше ассемблера, так как в итоге всё равно в него компилируются
Здравствуйте, VTT, Вы писали:
VTT>Во-вторых неявное копирование (или его отсутствие) в расте — это тихий ужас. VTT>Проявляется и при обычных вызовах методов типа foo(value) — нет никакой возможности определить, перемещается ли объект, или копируется.
Хм... ну так предполагается, что трейт Copy реализовывается исключительно для типов для которых эта разница не имеет значения. Конечно, можно умышленно подложить грабли, но это претензия сродни тому, что можно сделать кривой конструктор копирования. Вот только в ситуации с конструктором его можно ещё и забыть сделать, а в расте надо наоборот сделать дополнительные неправильные действия. Как по мне, разница всё-таки есть.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Да. Причём "короче" может быть качественным понятием, а не количественным. EP>Например генерация автомата из императивного по форме кода а-ля stackless await.
А где пример-то?
VTT>>Не ошибиться в копипасте? EP>Да, этого мало?
Ну опять же, укорачивать и прятать копипасту за макросами не должно быть самоцелью.
Допустим, некоторые случаи действительно не получится сделать более толковыми языковыми средствами.
Но если таких случаев выходит многовато — то это скорее говорит об ущербности языка.
А если таких случаев выходит немного — то это недостаточная причина прикручивать макросы.
Даже в многострадальном с++ с его архаичным препроцессором практически единственная ситуация, где использование порождающих макросов еще как-то оправдано — когда надо в одном месте заиметь имя типа / метода и аналогичный текстовый литерал.
EP>Это разруливается namespace'ами. EP>Да и например в Lisp вызов макроса по форме аналогичен вызову функции, так что тут пересечения с будущими возможными фичами не больше чем в случае с обычными функциями.
Какой ужас...
EP>Могу назвать реально полезные фичи в новых версиях всех mainstream языков. Наличие же плохих фич не говорит о том что на расширение в полезных направлениях нет спроса.
Вообще говоря, фичи могут быть и хорошими, но при этом избыточными.
Это прежде всего относится к введению встроенных средств вместо (паралельно) аналогичных библиотечных и различному "укорочивающему" синтаксическому сахару. Например nullable типы в c#.
В mainstream языках можно смело начинать потихоньку избавляться от излишков.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Здравствуйте, VTT, Вы писали:
EP>>Да. Причём "короче" может быть качественным понятием, а не количественным. EP>>Например генерация автомата из императивного по форме кода а-ля stackless await. VTT>А где пример-то?
Например computation expression в Nemerle:
https://github.com/rsdn/nemerle/wiki/Computation-Expression-macro
The C# await/async implementation and the Nemerle asynchronous programming approach have much in common, but with a big difference: await/async requires language support, but asynchronous programming in Nemerle is implemented with monads, which are part of the standard library, not the language itself.
VTT>>>Не ошибиться в копипасте? EP>>Да, этого мало? VTT>Ну опять же, укорачивать и прятать копипасту за макросами не должно быть самоцелью.
Вполне достойная самоцель. Многие языковые фичи только и делают что уменьшают boilerplate
VTT>Допустим, некоторые случаи действительно не получится сделать более толковыми языковыми средствами.
Не надо допускать — это объективный факт. Есть реальный спрос на мета/макро-прогарммирование — C++, D, Rust, Nemerle, Lisp (веб-программирование на Clojure), T4, и даже со всех углов слышны воодушевлённые придыхания о Roslyn'е от, казалось бы, программистов корпоративных систем и прочих опердней.
VTT>Но если таких случаев выходит многовато — то это скорее говорит об ущербности языка.
Так и есть — макросы очевидно не от хорошей жизни появляются — любой язык общего назначения в чём-то ущербен. И рано или поздно натыкаешься на эту ущербность. В идеальном языке не было бы никакой необходимости в макросах — в нём уже были бы средства для выражения любой проблемы на языке предметной области.
И лучше иметь возможность обойти эту ущербность библиотечными средствами, а не ждать пока введут новую фичу в язык, её реализуют на всех требуемых компиляторах, и они через несколько апдейтов систем дойдут до конечных программистов приложений. Программистам библиотек ещё хуже — для расширения клиентской базы приходится использовать старые компиляторы.
VTT>А если таких случаев выходит немного — то это недостаточная причина прикручивать макросы. VTT>Даже в многострадальном с++ с его архаичным препроцессором практически единственная ситуация, где использование порождающих макросов еще как-то оправдано — когда надо в одном месте заиметь имя типа / метода и аналогичный текстовый литерал.
Да ладно, зачем тогда по-твоему появились штуки типа Boost.Preprocessor? В нём фичи типа циклов реализованы огромными усилиями, вопреки архаичности препроцессора.
Конкретный пример использования — BOOST_FUSION_DEFINE_STRUCT — описываешь структуру один раз, и автоматом получаешь любой возможный обход, в том числе для вполне земной сериализации.
Также можно использовать для генерации тех же автоматов из императивного кода, но в таких случаях уже серьёзно не хватает возможностей препроцессора.
EP>>Это разруливается namespace'ами. EP>>Да и например в Lisp вызов макроса по форме аналогичен вызову функции, так что тут пересечения с будущими возможными фичами не больше чем в случае с обычными функциями. VTT>Какой ужас...
В чём ужас?
EP>>Могу назвать реально полезные фичи в новых версиях всех mainstream языков. Наличие же плохих фич не говорит о том что на расширение в полезных направлениях нет спроса. VTT>Вообще говоря, фичи могут быть и хорошими, но при этом избыточными.
Для обсуждаемой темы — не суть важно. В языках постоянно не хватает каких-либо хороших фич, макросы и прочее метапрограммирование позволяют на порядки сократить барьер их реализации — с изменения компиляторов до написания библиотеки в рамках текущей версии языка.
Здравствуйте, Evgeny.Panasyuk, Вы писали:
EP>Например computation expression в Nemerle: EP>
EP>https://github.com/rsdn/nemerle/wiki/Computation-Expression-macro
EP>The C# await/async implementation and the Nemerle asynchronous programming approach have much in common, but with a big difference: await/async requires language support, but asynchronous programming in Nemerle is implemented with monads, which are part of the standard library, not the language itself.
Статья хардкорная, понять, где же там извлекают пользу из макросов (а ее там извлекают или просто монаидические Computation-Expression существуют в ввиде макросов?) мне не удалось.
Автор явно забыл, что слово "просто" надо использовать пореже.
Оффтопик:
Most likely everyone who has understood monads wrote an article about them.
эти "пониматели монад" чем-то смахивают на веганов
EP>Вполне достойная самоцель. Многие языковые фичи только и делают что уменьшают boilerplate
Речь шла о том, макросы в расте что как раз boilerplate не уменьшают, а только прячут.
VTT>>Допустим, некоторые случаи действительно не получится сделать более толковыми языковыми средствами.
EP>Не надо допускать — это объективный факт. Есть реальный спрос на мета/макро-прогарммирование — C++, D, Rust, Nemerle, Lisp (веб-программирование на Clojure), T4, и даже со всех углов слышны воодушевлённые придыхания о Roslyn'е от, казалось бы, программистов корпоративных систем и прочих опердней.
Не стоит смешивать мета-программирование, препроцессоры, всякую разную кодогенерацию и макросы.
EP>Так и есть — макросы очевидно не от хорошей жизни появляются — любой язык общего назначения в чём-то ущербен. И рано или поздно натыкаешься на эту ущербность. В идеальном языке не было бы никакой необходимости в макросах — в нём уже были бы средства для выражения любой проблемы на языке предметной области. EP>И лучше иметь возможность обойти эту ущербность библиотечными средствами, а не ждать пока введут новую фичу в язык, её реализуют на всех требуемых компиляторах, и они через несколько апдейтов систем дойдут до конечных программистов приложений. Программистам библиотек ещё хуже — для расширения клиентской базы приходится использовать старые компиляторы.
Вы о чем вообще? Я бы сказал, что макросы уже практически вымерли.
Причем потребность в них отпала наверное как раз от хорошей жизни.
VTT>>А если таких случаев выходит немного — то это недостаточная причина прикручивать макросы. VTT>>Даже в многострадальном с++ с его архаичным препроцессором практически единственная ситуация, где использование порождающих макросов еще как-то оправдано — когда надо в одном месте заиметь имя типа / метода и аналогичный текстовый литерал.
EP>Да ладно, зачем тогда по-твоему появились штуки типа Boost.Preprocessor? В нём фичи типа циклов реализованы огромными усилиями, вопреки архаичности препроцессора. EP>Конкретный пример использования — BOOST_FUSION_DEFINE_STRUCT — описываешь структуру один раз, и автоматом получаешь любой возможный обход, в том числе для вполне земной сериализации.
На макросах и целые мета-языки появились, но это совершенно не оправдывает использование макросов.
Boost.Preprocessor по большей части уже давно не нужен.
А фьюжн я и раньше не стал бы использовать. Внешний кодогенератор (как в qt например) для информации о типах (если уж без нее не обойтись) и то лучше.
Вообще-то я выше уже привел единственный кейс, где от макросов еще остается какой-то прок и который как раз покрывается в фьюжн.
EP>Также можно использовать для генерации тех же автоматов из императивного кода, но в таких случаях уже серьёзно не хватает возможностей препроцессора.
Зачем генерировать автоматы из императивного кода?
Чем вас не устраивают автоматы, написанные в императивной манере?
Почему нельзя обойтись без макросов?
EP>>>Это разруливается namespace'ами. EP>>>Да и например в Lisp вызов макроса по форме аналогичен вызову функции, так что тут пересечения с будущими возможными фичами не больше чем в случае с обычными функциями. VTT>>Какой ужас...
EP>В чём ужас?
В том, что лисп по сути уже давно воспринимается как какое-то маргинальное явление.
Достаточно странно приводить его как пример оправдания существования макросов.
Если уж хотелось привести такой пример — так можно было вспомнить ассемблеры какие-нибудь.
Вот там да, надо чтобы весь boilerplate был на месте, но записывался покороче. Без макросов никуда.
EP>В языках постоянно не хватает каких-либо хороших фич, макросы и прочее метапрограммирование позволяют на порядки сократить барьер их реализации — с изменения компиляторов до написания библиотеки в рамках текущей версии языка.
По мне, так во многих языках скорее избыток фич.
Говорить дальше не было нужды. Как и все космонавты, капитан Нортон не испытывал особого доверия к явлениям, внешне слишком заманчивым.
Но таких пока не предвидится, так что все таки предпочитаю пользоваться тем немногим что есть.
