Здравствуйте, Евгений Музыченко, Вы писали:
R>>Походу, мораль басни ты так и не понял
ЕМ>Да не про меня она. Там лису виноград явно привлекает, и она рада бы попробовать, подай его кто-нибудь на тарелочке, а мне одинаково противно что разбираться и в клубках "магических" шаблонов, и в средствах их частичного распутывания, и применять эти хитрозагнутые конструкции в готовом виде, копируя из примеров.
А, ну значит, "ёжики и кактус" тебе ближе.
--
Справедливость выше закона. А человечность выше справедливости.
Re[29]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Да не про меня она. Там лису виноград явно привлекает, и она рада бы попробовать, подай его кто-нибудь на тарелочке, а мне одинаково противно что разбираться и в клубках "магических" шаблонов, и в средствах их частичного распутывания, и применять эти хитрозагнутые конструкции в готовом виде, копируя из примеров.
Ну вообще странно. Если учесть количество времени, которое ты уделяешь разговорам про виноград. Так и не скажешь, что он тебе совсем безразличен.
--
Справедливость выше закона. А человечность выше справедливости.
Re[25]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>В ситуации с C++ это позволило бы давным-давно избавиться от искусственно навязанной дихотомии "макросы намеренно убоги — они только для голого текста, надо их избегать" — "шаблоны — только для языковых конструкций, они странны и часто неудобны, но надо их предпочитать", при которой и на первом, и на втором приходится городить различные трюковые схемы для реализации даже достаточно простых конструкций, для которых идеально подошло бы нечто среднее, но с развитыми возможностями внутреннего управления.
Евгений, вы позволяете себе высказываться в духе "эти идиоты, сперва втащили в С++ макросы Си, а затем вместо доведения макросов до нужного г.Музыченко уровня, объявили макросы персонами нон-грата и стали развивать убогие шаблоны, в которых г.Музыченко не может разобраться, но хуже всего то, что эти самые идиоты за столько лет не удосужились сделать так, как понравилось бы г.Музыченко".
Ваши слова могли бы звучать убедительно, если бы вы могли сослаться на какие-то документы в прошлом (например, переписку со Страуструпом или пропозалы в комитет), в которых вы бы описывали что и как должно было быть сделано. Тогда да, тогда можно было бы с вашими предложениями ознакомиться и сделать выводы о том, какие же возможности комитет упустил. Тогда можно было бы говорить о том, что г.Музыченко предлагал, а эти самые идиоты не прислушались.
Но ведь этого не было.
Вот маниловщина с вашей стороны есть. Неспособность в конкретику. Обилии пустых словесов. Этого в избытке.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Это принципиально разделение между макропрограммированием и метапрограммированием/рефлексией.
ЕМ>Каковы исходные предпосылки этой принципиальности?
Чтобы называть вещи своими именами.
Если в терминологии возникает слишком много вольностей, например, кто-то обзывает паттерн проектирования "Facade" как "Bridge", то это ведет лишь к запутыванию.
Это точно так же, как если бы я сперва заявлял бы, что разрабатываю программы в функциональном стиле, а потом бы показал код в котором классы, наследование, виртуальные методы, мутабельное состояние в объектах и вот это вот все.
Здравствуйте, so5team, Вы писали:
S>Но никакими макросами они не являются.
Непонятно, почему вы так считаете. S>Или ваши познания на одном уровне с г.Музыченко и вы считаете C++ные шаблоны разновидностью макросов?
Нет, мои познания значительно ниже познаний г.Музыченко.
Я правильно понял, что к макросам в Dart у вас вопросов не возникло?
Можно считать утверждение, что "макросы не могут работать ни с каким уровнем выше лексического" опровергнутым?
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Sinclair, Вы писали:
S>>Но никакими макросами они не являются. S>Непонятно, почему вы так считаете.
Я-то на D и программировал, и документацию по D читал.
А вот почему вы темплейты из D считаете макросами -- вот это вопрос.
S>Я правильно понял, что к макросам в Dart у вас вопросов не возникло?
Никогда с Dart дел не имел, а изучать Dart для того, чтобы поддержать беседу с очередным балаболом и пропагандоном .NET-а в прошлом нет ни времени, ни желания.
S>Можно считать утверждение, что "макросы не могут работать ни с каким уровнем выше лексического" опровергнутым?
Здравствуйте, rg45, Вы писали:
R>А, ну значит, "ёжики и кактус" тебе ближе.
Да с чего бы? Они были бы ближе, если б я был наемным работником, или был связан договором подряда с определенными требованиями, под давлением начальства/заказчика был вынужден применять неприятные мне средства C++, и плакался бы об этом здесь. А так я их просто не применяю, и не вижу, где они могли бы мне помочь настолько, чтоб оправдать их изучение и возню с неизбежными в будущем нестыковками, поиском ошибок по невнятной диагностике и прочими неудобствами.
Re[30]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, rg45, Вы писали:
R>Если учесть количество времени, которое ты уделяешь разговорам про виноград. Так и не скажешь, что он тебе совсем безразличен.
Вы все перепутали. Время я уделяю в основном разговорам про то, как все это можно было сделать по-человечески. Сколько времени я на Вашей памяти уделял обсуждению тонкостей применения той или иной шаблонной конструкции сперва из boost, а потом — из std?
Re[26]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, so5team, Вы писали:
S>если бы вы могли сослаться на какие-то документы в прошлом (например, переписку со Страуструпом или пропозалы в комитет), в которых вы бы описывали что и как должно было быть сделано.
Я лет двадцать назад подумывал что-то подобное учинить, но к тому времени видел уже достаточно отзывов от людей, которые это делали. Все сводилось к тому, что комитет тогда четко придерживался позиции "ни шагу от линии партии", любая критика существующего положения считалась безусловной ересью, и более-менее благосклонно принимались лишь предложения, далекие от покушения на нее. А у меня к тому времени уже был некоторый опыт написания как багрепортов, так и предложений, причем в широком спектре — и по софту, и по законодательству. И если сообщение об очевидной ошибке или жалоба на очевидное нарушение закона еще имели шансы на успех, то предложения по совершенствованию в лучшем случае приводили к ответу "спасибо за ваше мнение, оно очень ценно для нас", а в худшем — тупо оставались без какой-либо реакции.
Так что я поразмыслил и пришел к выводу, что один только поиск людей, которые смогут и захотят понять идеи, может занять месяцы плотной переписки, а уж на какое-то продвижение можно рассчитывать минимум через годы. Чтоб заниматься такими вещами, нужно или гореть идеей, или стремиться к славе. К славе я не стремлюсь, и подобными идеями никогда не горел, у меня их всегда полно самых разных. Поэтому ограничился периодическим озвучиванием в сообществах и, как видите, они принимаются очень туго. Просто потому, что предлагают один раз, но серьезно, изменить подход вместо того, чтоб долго и упорно навешивать новые и новые частности на давно перегруженный синтаксис.
Re[31]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Евгений Музыченко, Вы писали:
R>>Если учесть количество времени, которое ты уделяешь разговорам про виноград. Так и не скажешь, что он тебе совсем безразличен.
ЕМ>Вы все перепутали. Время я уделяю в основном разговорам про то, как все это можно было сделать по-человечески. Сколько времени я на Вашей памяти уделял обсуждению тонкостей применения той или иной шаблонной конструкции сперва из boost, а потом — из std?
Ну то есть, если продолжить метафору, ты уделяешь время разговорам о том, каким мог бы быть виноград. И это всё еще разговоры про виноград. Который, якобы, тебе безразличен.
--
Справедливость выше закона. А человечность выше справедливости.
Здравствуйте, so5team, Вы писали:
ЕМ>>Каковы исходные предпосылки этой принципиальности?
S>Чтобы называть вещи своими именами.
Какими еще "своими"?
Вот термин "процессор" много лет определялся, как сочетание АЛУ и УУ, не имеющее ни памяти, ни интерфейсов со внешними устройствами. Потом постепенно привыкли к тому, что в процессор может входить и кэш-память, а теперь у Ryzen непосредственно из кристалла идут сразу линии PCIe, SATA и USB.
S>Если в терминологии возникает слишком много вольностей, например, кто-то обзывает паттерн проектирования "Facade" как "Bridge", то это ведет лишь к запутыванию.
Какая путаница возникает, когда микросхемы Ryzen называют "процессорами"? Какие негативные последствия она создает? Как нам нужно их называть, чтобы избежать путаницы? Какие позитивные последствия это повлечет?
S>Это точно так же, как если бы я сперва заявлял бы, что разрабатываю программы в функциональном стиле, а потом бы показал код в котором классы, наследование, виртуальные методы, мутабельное состояние в объектах и вот это вот все.
Во-первых, в функциональном стиле достаточно явно декларируется нежелательность наличия состояний и признается, что они нарушают "чистоту" стиля. Во-вторых, с этим нередко приходится мириться, и это опять-таки оговаривается в серьезных работах по ФП.
Сколько сумеете найти серьезных работ по ЯВУ, в которых "макропрограммирование" противопоставляется "метапрограммированию", а не является его частным случаем? Желательно более общего характера, чем на основе макросов C и шаблонов C++, а также языков, достаточно прямо унаследовавших это разделение. Желательно, чтоб авторы были знакомы с реализациями 60-х, а не ограничивали горизонт началом-серединой 80-х, как это нынче принято.
Re[17]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
ЕМ>Я почему-то очень сильно сомневаюсь, что Вы хотя бы более-менее понимаете, как работают "магические" шаблоны в той же Loki. Не в смысле общих принципов, а в смысле внесения туда осмысленных правок с сохранением работоспособности.
Локи не смотрел, но тут на сайте есть года от 2002го статья моего однофамильца Андрея Мартынова на тему сериализации XML. Там довольно неплохо всё шаблонами накручено, но тем не менее, я её перевёл на другой XML движек (там изначально MSXML), и довольно сильно расширил её возможности
M>>что тебе сешает сделать свой компилятор своего "C++"?
ЕМ>То, что это весьма затратный процесс, особенно при том, что мне нужна хорошая оптимизация кода на выходе, а времени на занятия, не приносящие денег, остается все меньше и меньше.
Оптимизацией может заниматься сишный компилятор, который можно использовать в качестве бекэнда
M>>Если выкинуть шаблоны
ЕМ>Я не смогу их выкинуть, ибо использую. Не на уровне магии, но все же.
M>>Примеры помогут, по-моему, мало кто понимает, как твои макросы должны работать
ЕМ>Тому, кто намертво залип на принципах вроде "любой макрос обязан полностью раскрываться на стадии лексического анализа", примеры не помогут.
Тем не менее, мы так и не увидели ни одного хотя бы концепта, с пояснениями, что, как и когда делается, одно балабольство, да "вы всё сами можете придумать, я вам достаточно рассказал"
Здравствуйте, Евгений Музыченко, Вы писали:
M>>А что это за зависимости
ЕМ>Оно ж в любом случае тащит часть поддержки RTTI, чтоб catch мог понять, значение какого типа выброшено в throw.
RTTI там как такового нет, там, как я слышал, есть только средства для сравнения типов, чтобы определять, что вылетело. Большую часть работы компилятор делать во время компиляции, из рантайма включается функция расткрутки стека да генерации исключений.
M>>По-моему, там всё довольно минималистично
ЕМ>Минималистичным оно могло бы быть, если б throw мог выбрасывать только значения интегральных типов (оптимально — указатель). Ну, или если б можно было сказать компилятору "мы будем выбрасывать только интегральные типы, и сами разберемся, что было выброшено по факту".
И кому твои интегральные типы нужны?
ЕМ>А так добавление SEH в минимальный main для VC++ дает прирост где-то в 3%, а добавление туда же исключений C++ (которые реализованы поверх SEH) — дополнительные 25%. По большому счету, это не так много, но это явное нарушение того самого принципа о плате и использовании.
Ну да, а если собирать с minCRT, то вообще и всё 2500% будет. Только в абсолютных величинах это слезы.
И никакого нарушения принципа нет — лишнее тебе — ну отключи исключения и радуйся
Здравствуйте, Евгений Музыченко, Вы писали:
M>>Разве C? А не Паскаль?
ЕМ>В виндовых SDK/DDK/WDK никогда не было объявлений интерфейсов для Pascal. Только для C/C++, MIDL и других стандартных средств от MS.
Хз, ходили байки, что первые (или первую, или даже пред-первую) винду писали на паскале. Но это просто байки.
M>>в объявлениях практически всех виндовых функций использовался макрос PASCAL
ЕМ>Макрос PASCAL раскрывался в сишный модификатор _pascal.
ЕМ>Это пошло еще с первых реализаций C/Pascal: в первом возможны функции с переменным количеством параметров, поэтому стек очищает вызывающий код, а во втором их нет, поэтому стек очищает вызываемая функция. Соответственно, модификаторы вроде _pascal были добавлены в C для подключения процедур/функций на Pascal. По объему кода второй вариант более компактен, поэтому в ABI последующих систем обоснованно решили использовать его, а модификатор был уже готовый.
Здравствуйте, Евгений Музыченко, Вы писали:
S>>если бы вы могли сослаться на какие-то документы в прошлом (например, переписку со Страуструпом или пропозалы в комитет), в которых вы бы описывали что и как должно было быть сделано.
ЕМ>Так что я поразмыслил и пришел к выводу, что один только поиск людей, которые смогут и захотят понять идеи, может занять месяцы плотной переписки, а уж на какое-то продвижение можно рассчитывать минимум через годы. Чтоб заниматься такими вещами, нужно или гореть идеей, или стремиться к славе. К славе я не стремлюсь, и подобными идеями никогда не горел, у меня их всегда полно самых разных.
В сухом остатке: вы не стали пытаться оказывать влияние на C++ и C++ развился без вас в том направлении, которое сочли перспективным люди, нашедшие в себе силы и время заняться этой работой.
Вы же ведете себя как собака, которая лает на проходящий мимо караван.
ЕМ>Поэтому ограничился периодическим озвучиванием в сообществах и, как видите, они принимаются очень туго. Просто потому, что предлагают один раз, но серьезно, изменить подход вместо того, чтоб долго и упорно навешивать новые и новые частности на давно перегруженный синтаксис.
Еще раз озвучу проблему: вы не можете в конкретику. А без конкретики ваша маниловщина выглядит как анекдот про "мыши станьте ёжиками" с характерным же ответом на вопрос "а как?"
Здравствуйте, Евгений Музыченко, Вы писали:
S>>Чтобы называть вещи своими именами.
ЕМ>Какими еще "своими"?
Своими, Владимир, своими. Т.е. теми, которые прочно связаны с конкретными явлениями.
S>>Если в терминологии возникает слишком много вольностей, например, кто-то обзывает паттерн проектирования "Facade" как "Bridge", то это ведет лишь к запутыванию.
ЕМ>Какая путаница возникает, когда микросхемы Ryzen называют "процессорами"? Какие негативные последствия она создает? Как нам нужно их называть, чтобы избежать путаницы? Какие позитивные последствия это повлечет?
Геннадий, для человека, который не смог привести ни один пример кода, вы задаете своим оппонентам слишком много вопросов. Нет стимула вам отвечать, Василий, т.к. вы не берете на себя труд хоть как-то подтверждать собственные изречения.
Кроме того, Висиссуарий, вы намеренно искажаете суть разговора игнорируя релевантные примеры, заменяя их не имеющими отношения к теме. Фу таким быть, Онуфрий.
Когда архитектор или тим-лид говорит программисту, что некая задача решается через паттерн "Facade", хотя подразумевается "Bridge", то это либо повлияет на код (будет получен переусложненный и неудобный вариант решения), либо будет потрачено время на выяснение того, что же на самом деле подразумевалось. Надеюсь, это понятно, Порфирий?
Хотя, если я правильно помню ваши рассказы о себе, Кондратий, вы же в командной разработке софта практически никогда не принимали участия. Поэтому, боюсь, мы сейчас разговариваем о вещах, которые вам, Терентий, неведомы.
We have invested significant time and resources to prototype macros over the past couple years. Unfortunately, each time we solved a major technical hurdle, we saw new ones pop up. At this point, we are not seeing macros converging anytime soon toward a feature we are comfortable shipping, with the quality and developer-time performance we want.
After considering the opportunity cost — in particular, the features we could be shipping to the community instead — we’ve made the difficult decision to stop our work on macros.
Причем в тексте товарищи пишут очевидные вещи (выделение мое):
Static introspection (e.g., macros) can take a couple forms. Most languages take a syntactic approach, with limited static reflection on the syntax of programs. We did not believe this was sufficient to achieve our goals. Instead, we aimed to build a macro system which supported deep semantic introspection on the program at compile time.
Что вело к негативным результатам:
Semantic introspection, unfortunately, turned out to introduce large compile-time costs which made it difficult to keep stateful hot reload hot. We’ve concluded we’re simply too far away from shipping macros with the developer-time performance we require. Our current implementation regresses both editing (e.g., static analysis and code completion) and incremental compilation (the first step of a hot reload). We are not confident we can adequately solve these problems in a reasonable timeframe.
Выглядит так, что люди попытались воплотить мечты г.Мызыченко в жизнь и попробовали таки скрестить макросы с компайл-тайм рефлексией. Но уперлись в непреодолимые в их условиях сложности. После чего решили свернуть попытки.
Re[17]: The Big OOPs: Anatomy of a Thirty-five-year Mistake
Здравствуйте, Евгений Музыченко, Вы писали:
M>>мне всегда проще было сделать что-то рекурсивно, чем итерационно.
ЕМ>Если алгоритм изначально рекурсивный — неудивительно.
Здравствуйте, Евгений Музыченко, Вы писали:
ЕМ>Ну, если стоит задача сделать формальную игру наподобие шахмат, где конь ходит только буквой "Г", и никак иначе, то Вы на верном пути. Если же хочется сделать одновременно несложный, удобный и универсальный инструмент, то придется отступить от строгой идеологии в пользу разумности.
