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

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

S>Потому что для языковых конструкций нет изоляции как таковой, они или используются повсеместно, или не должны использоваться вообще. Не, изобрести новую общеупотребительную конструкцию шансы конечно есть, примерно как придумать полезный extension-метод для object. Одна проблема: затраты/выигрыщ по сравнению с метапрограммированием на атрибутах выглядят совсем уж непристойно

Мне тоже не кажется правильным врубать какой-то синтаксис на весь проект\solution. Сделать аналог using namespace для каждого файла. И пусть там хоть brainfuck будет. Но это опять-таки требует какого-то уж слишком умного парсера шарпа, если мы туда все засовываем. Какие-то рамки нужны.

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

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

Тогда у меня есть опыт пилотирования самолетов, так как я наблюдал как дети воздушного змея запускают.

S>Так вот, с DSL всё было оччень зашибись — поддерживалось, записывалось и читалось понятнее, чем в коде, тут полностью за. С "макросами" было столько проблем, что день когда их наконец выпилили был праздником у всей команды.

Прямо как в том анекдоте.

- Да, фигня этот ваш Карузо!
— А, где ты его слышал?
— Да, Васка, из четвертого подъезда, напел.

У нас в проекте 90% кода генерируется макросами. Полет нормальный.

S>1. Ошибка была в том, что "макросы" добавлялись по всему проекту целиком. Если кто-то добавлял макрос для своей локальной задачи — он рано или поздно использовался не по назначения кам-то ещё, при изменении макроса всё сыпалось. И хорошо ещё, если при компиляции.

Давай на конкретных примерах. Что за макросы? Как их использовали не по назначению? Какие последствия были?

S>2. Макросы в том виде, что были — были добавлены абсолютно зря (точнее, как я понял, они достались в наследство от какого-то легаси-проекта то ли на плюсах, то ли на простом C). В реальности не было ни одного случая, когда то же самое не решалось бы разметкой атрибутами и реврайтерами.

Мясорубки повара использовали совершенно зря. Нужно было только измельчить мясо.

А, что такое, по-твоему, макросы, как не "разметка и переписывание"? Что такое эти твои реврайтеры? И почему разметка макросами не есть ДСЛ (т.е. расширение или реинтерпретация) синтаксиса?

S>Зато примеров использования макросов просто потому, что можно — было выше крыши.

Значит тебе не составит труда озвучить хотя бы парочку.

S>Часть вещей, которая элементарно решалась средствами шарпа была сделана на макросах, в результате макросы регулярно расползались по соседним проектам.

Не вижу связи. Если что-то можно было без ущерба решить средствами шарпа, то не фига было использовать макросы. Это бесспорно. Но причем тут "расползались"?

Функции и классы у вас по проектам тоже расползаются? Если, да, то вызывает ли это те же проблемы?

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

S>там были ещё проблемы, но по сравнению с первыми двумя они были совсем мелочью.

Описывай. Пока что я вижу только общие слова по отношению к опыту поверхностного наблюдения за не пойми чем. А у меня, вот, совершенно обратный опыт опровергающий твой. Так в чем проблема, в макросах как в подходе, или в кривом инструменте? У меня сомнений нет, что в инструменте.

VD>>Ну, и твои подозрения, что расширения синтаксиса это что-то сложное, страшное и опасное ничем не отличаются от подозрений оп поводу того, что "var" сделает код программ нечитабельным.
S>Чтоб не спорить впустую — можешь привести реальный полезный пример расширения синтаксиса?

Вообще-то два из них ты описал в своем ответе. Если ты думаешь, что атрибуты по которым генерируется код — это не новый синтаксис, то ты глубоко ошибаешься. Но примеров может быть масса. Например, у нас, в Немерле, есть все о чем вы можете только мечтать последние 10 лет. Все это реализовано на базе макросов. База выражений Немерла микроскопична. Язык соедржит локаольные функции паттерн-матчинг, объявление переменных, именованные блоки (нечто вроде локального ретурна), просто блоки (в фигурных скобках) и набор базовых операторов ("+", "-", "*" и т.п.). Все остальное раелизовано на макросах. А реализовано в разы больше чем вы можете ждать от шарпа в ближайшие 10 лет. Даже банальный foreach — это макрос который поддерживает кучу дополнительных возможностей (от индексов элементов, до встроенного паттернматчинга). Практически любое улучшение языка (новые фичи) можно получать в виде библиотеки. При этом к ним применимы все фичи библиотек: распространение в виде отдельного бинарного модуля (сборки), возможность подключения этой сборки к нужным проектам (фичи будут доступны только в этих проектах), возможность использования фичи в конкретном файле проекта (синтаксические расширения открываются как и методы-расширения имен с помощью using-ов), возможность замены версий банальной сменой ссылки на сборку.

Linq и многое другое тоже реализованы макросами.

Короче, можешь взять C# 1.0 и C# 6.0. Большая часть фич C# 6.0 реализуется с помощью макросво Немерла. А Найтра позволит релизовывать 100% фич даже C# 7.0.

S>Потому что для AOP я с ходу десяток примеров приведу, для расширения синтаксиса — только мелочёвка типа счётчика в foreach или foreach ... else. Ну несерьёзно это

Ты придумал себе термин "AOP" и споришь о терминах. Твой AOP — это ни что иное как ограниченный пример макросов. Примеров на этот твой AOP я тебе тоже придумаю множество, но ежу понятно, что чем шире возможности, тем больше проблем можно решить.

Ну, и как я уже говорил, все это есть ни что иное как встраивание ДСЛ-ей. Просто ты думаешь, что если синтаксис твоего ДСЛ-я записан в виде атрибутов, то это уже как бы и не изменение языка, да и, вообще, не язык. А это не так. Ты придумываешь синтаксические расширения и укладываешь их синтаксис в синтаксис атрибутов. Какой-то класс задач решается этим. Но процентов 80% не решается. В прочем, у Шарп нет и не ясно появится ли даже куцая урезанная версия макросов реинтерпретирующих синтаксис.

Ты почему-то все упиравшийся в синтаксис (AVK, кстати, тоже) меж тем основная проблема макросов не в том поддерживают ли они синтаксис или нет, а в том как они позволяют перехватывать действия в компиляторе, какие они предоставляют средства для разбора добавляемых конструкций (не важно будут ли они выражены атрибутами или полноценным синтаксисом), и какие они предоставляют средства для генерации кода который будет реализовывать логику этих конструкций (по факту ДСЛ-ьных). Вот этого всего и не будет. Не будет точек входа в компилтяор. Не будет полноценных средств анализа не шарпного кода, не будет удобных средств генерации кода. Будут какие-нибудь внешние тулы с ручным разбором и и реинтерпретацией АСТ-а и ручной генерацией текста на базе строковой интерполяции снабженной кучей приседаний и удвоением всех фигурных скобок, так как они конфликтуют с синтаксисом тех самых "дыр" (об этом же авторы языка тоже не подумали). В итоге сложность реализации и поддержки достигнет уровня на котором орел вроде тебя скажет: "день когда их наконец выпилили был праздником у всей команды...".


S>Не, вот как раз насчёт DSL по делу — я всегда за. А вот попытка скрестить ужеежа и запихнуть расширения синтаксиса туда, где они особо не нужны — ничего кроме скептицизма не вызывает

Тогда тебе осталось понять, что твой АОП и атрибуты — это чистой воды расширение синтаксиса. То что он при этом совпадает с синтаксисом атрибутов не устраняет того факта, что это ДСЛ. Это очень похоже на то как некоторые реализуют свой язык в ХМЛ-е думая, что при этом у них будет стандартный синтаксис. Ничего подобного. Язык есть язык. У него будет совой надсинтаксис. Только с очень убогими базовыми элементами — тегами и атрибутами. Тагая же фигня и тут. Ты делаешь тот же ДСЛ, но загоняешь его синтаксис в подмножество атрибутов. Где-то это прокатывает, где-то — нет.


VD>>медленность этого процесса обусловлена медленностью эволюции сознания пользователей языка. Я только добавлю, что дело не только в пользователях, но и авторах. Эволюция их сознания так же тормозит процесс.
S>"У любой сложной проблемы всегда есть простое неправильное объяснение"

Тут больше подходит другое высказывание: Любую сложную проблему можно заболтать. Тот кто хочет — ищет решение, кто не хочет — ищет отмазки почему проблему не надо решать.

S>Другой планеты у нас нет, поэтому или делаем то, что действительно полезно для _большинства_ пользователей, или фейлимся, или получаем очень классный, но очень узкоспециализированный язык. Других вариантов я что-то не видел

Вы просто не хотите разобраться в имеющейся альтернативе. Те кто разобрались этих глупостей не повторяют. И сказки про про классные решения не более чем самовнушение. По жизни большинство решений получается так себе. И живут только за счет отличной реализации тулига (IDE, фремворков), бржнда стоящей за ним компании и ее пиарщиков.

По факту же Немерл, как язык, на протяжении 10 лет во всем на голову превосходит Шарп. Но ты даже не удосужился с ним как следует разобраться. Зато рассказываешь нам о каких-то страшных проблемах макросов написанных кем-то на коленке.

Нет никакого другого пути. Нет никаких других ниш. Все что можно на Шарпе — можно и на Немерле, но намного удобнее. Реализовал бы его МС и отпиарил бы как следует, никто в здравом уме даже сравнивать его с Шарпом не стал бы. Но МС идет своим, эволюционным путем. Через 12 лет после появления Немерла в Шарпе начали появляься простенькие фичи из Немерла. Еще через 10 лет он доживет и до макров. Лично у меня в этом сомнения нет. Они, скорее всего, будут чуть другие (такие же как у других, но другие).

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

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

S>В отличие от любого мелкого проекта, в мейнстриме работает закон больших чисел вместе с законом Мёрфи. Т.е. вместо "чотам думать, очевидно же" неплохо бы предусмотреть правильный синтаксис, расширяемость и поддержку кучи сценариев использования от оптимизаций для простых случаев и вплоть до локализации строк . Ну, или пару десятков лет поддерживать код напичканный последствиями ваших неправильных решений. Других вариантов (эмиграцию к эльфам и розовым пони не предлагать) увы нет.

К счастью они есть. Реализуем эти самые строки на базе макросов и имеем возможность:
1. Развивать их как библиотеку не ожидая выхода новых версий компилятора.
2. Положить библиотеку на НюГет и позволить кому угодна в дава клика получить эту функциональсность.
3. Использовать фичу в тех проктах в которых хочется (как библиотеку).
4. Выпускать новые версии библиотеки.
5. Создавать альтернативные решения.

S>Ну а как всю эту радость реализовать — это уже дело десятое, если не сотое. Тем более что с точки зрения разработчиков шарпа тут нет никакой разницы есть макросы/нет макросов. Они и так имеют полный доступ ко всем этапам обработки AST.

Разница как раз принципиальная — прибить гвоздями к языку или положить ее в библиотеку. Да и одно дело выпиливать что-то разбирая АСТ вручную, а другое с использованием высокоуровневого АПИ.

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

A>1) Я не увидел чтобы над той же локализацией кто-то там особо думал. Они о регулярных выражениях с \{} вещами вспомнили на середине. 2) Имея на подходе рослин (вот уже прям скоро), не видел там ни одного предложения подождать его сделать на макросах\AST чего угодно. Очень странно учитывая как они его позиционируют. Имхо они именно не знают про альтернативы, что грустно.

Они все знают. Даже в предложениях фич начали открыто указывать Немерл среди прочего.

Просто у них нет реального опыта и они рассуждают как Sinix.

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

S>Ну блин, это только в сказках можно сказать ХАЧУ и в шарпе тут же появятся макросы.

+1

В жизни между ХОЧУ и началом обсуждения возможности их реализации проходит 12 лет!

S>Изначально на этот релиз планы были только перетащить шарп и студию на рослин, без крупных добавлений. Это потом уже сроки поехали и появилось время на всякую мелочёвку.

Все еще прозаичнее. Кое кто внутри эту тему попедалировал, пообщался с кое-кем извне и протащили ограниченную версию строковой интерполяции (попутно придумав новое название для нее).

S>А до метапрограммирования ещё копать и копать.

За 12 лет можно было накопать больше. Проблема в том, что никто и не копал. Примерно 10 лет назад Хейльсберг про макросы сказал — "Это слишком большая пушка.". Вот сейчас с переходом на Рослин и увеличением давления извне и изнутри начали рассматривать подобную возможность. Думаю, эта идея еще несколько лет по варится и в МС решатся на ее реализацию.

S>Для начала неплохо бы определиться, какие именно макросы нужны.

Для начал неплохо бы определиться делать или нет. Если делать, то начать прорабатывать идеи, советоваться с комьюинити.

S>Будет ли достаточно простого AOP на атрибутах или клиенты хотят полноценный язык с dsl и гейшами.

Будет. Сказку про кашу из топора слышал? Вот с этим так же будет. Так что пусть решаются на самый простой вариант.

В прочем, пусть тормозят. Нам же лучше будет.

S>Если первое — повезло, если последнее — приплыли, нужен подопытный кролик экспериментальный диалект наподобие Cω.

Выдумал что-то и сделал выводы.

Блин. Потрать две недели. Разберись с тем же Немерлом. Увидишь, что все твои страшилки не более чем выдумки. Иначе не стоит обсуждать устрицы с теми кто их ел. (ц)

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

Другими словами — нужен дизайн. Ну, это не виданное чудо в нашей области . Тем более, что они просто таки первопроходцы. Первому языку с макросами более 50 лет, а язык с макросами для платформы дотнет существует уже 12 лет. За это время такой сложный процесс как дизайн было невозможно сделать.

S>Про интеграцию с другими языками (дотнет шарпом вообще-то не заканчивается), работу с c# script/REPL (его активно пилят, к следующему релизу будет) и традиционно отстающий edit'n'continue я вообще молчу.

Если не натягивать сову на глобус, то проблем не будет. Все это с макрами никак не связано, так как макры работают во время компиляции.

S>Короче, по затратам это штука где-то между await и linq будет. А вот насчёт выхлопа я не уверен. Мы встроили тебе язык в язык, чтобы ты мог программировать пока ты программируешь, ага.

Выхлоп можно было сэкономить не хардкодя те самые await и linq. Их можно было бы в 10 раз быстрее сделать в виде макросв. Были бы библиотеками которые могли бы использовать те кому нужно и не ждать выхода новой версии языка.

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

VD>С их то баблом? Они зарядили бы 100500 евангелистов, которые бы за пол года убедили бы всех промайкросовтовских программистов, что МС совершил революцию в программировании...

Для начала им надо убедить себя. Сейчас прогресс идет как раз там, где все легко решается макросами. Я верю в то, что они тоже со временем придут к такому решению.

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

Z>Для начала им надо убедить себя. Сейчас прогресс идет как раз там, где все легко решается макросами. Я верю в то, что они тоже со временем придут к такому решению.

Хочется в это верить, но уж больно алогичное сопротивление оказывается даже продвинутыми пользователями (программистами). Что уж говорить о середнячках и тем кому все по фиг?

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

VD>По факту же Немерл, как язык, на протяжении 10 лет во всем на голову превосходит Шарп. Но ты даже не удосужился с ним как следует разобраться. Зато рассказываешь нам о каких-то страшных проблемах макросов написанных кем-то на коленке.

В общем чтоб не спорить — давай закруглимся. Тем более что со многим согласен, да и с "расширение синтаксиса не нужно" я точно был не прав — hi_octane выше привёл примеры из разряда фиг оспоришь

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

VD>Замечательно. Главное, чтобы они над этим задумались. Так что имеет смысл их подтолкнуть к размышлениям.

То что ПК отменили, причем на довольно позднем этапе, когда эти самые ПК были реализованы в компиляторе на довольно высоком уровне (и даже Решарпер их уже поддерживал), как раз и свидетельствует о том, что они задумались.

AVK>>Мелочь одну — переписали с нуля JIT.
VD>Для того чтобы поддержать структурные типы ничего переписывать не надо.

Я этого и не утверждал. Ты, судя по всему, как обычно не вникаешь в то, что тебе пишут.

VD>>>Ну, и до кучи надо ввести замену этому убогому delegate — функциональный тип.
AVK>>Это, очевидно, практически невозможно из-за совместимости.
VD>Это очевидно только для тебя. И обосновать ты это не сможешь хотя бы потому, что данные типы уже существуют в двух дотнетных языках: Nemerle и F#.

Хреново, надо сказать, существуют.

S>Мы встроили тебе язык в язык, чтобы ты мог программировать пока ты программируешь, ага.

Наверняка не на всех так действует, но мне эта фраза какие-то перемычки в башке пожгла Стоит отвлечься от дел и сразу снова ржу

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

AVK>>>Мелочь одну — переписали с нуля JIT.
VD>>Для того чтобы поддержать структурные типы ничего переписывать не надо.

AVK>Я этого и не утверждал. Ты, судя по всему, как обычно не вникаешь в то, что тебе пишут.

Значит ты влез в разговор не разобравшись в том о чем в нем идет речь. Мы говорили о том, что для поддержки записей (которые они называют кортежами) нужно реализовать поддержку структурных типов в рантайме. На что было заявлено, что у них нет времени.

VD>>Это очевидно только для тебя. И обосновать ты это не сможешь хотя бы потому, что данные типы уже существуют в двух дотнетных языках: Nemerle и F#.

AVK>Хреново, надо сказать, существуют.

Хреново? Расскажи нам в чем заключается эта хреновость. А еще лучше, не спорь о вкусе устриц с теми кто их ел.

Единственная "хреновость" — это не стандартность. Было бы значительно лучше, если тип поддерживался в рантайме. Тогда все языки были бы совместимы между собой.

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

AVK>>Я этого и не утверждал. Ты, судя по всему, как обычно не вникаешь в то, что тебе пишут.
VD>Значит ты влез в разговор не разобравшись в том о чем в нем идет речь.

Да нет, я то как раз разобрался. А ты не потрудился все таки в никнуть что и про что я писал. Прошлый раз итераций 5 понадобилось, чтобы ты наконец прочел исходное сообщение.

VD> Мы говорили о том, что для поддержки записей (которые они называют кортежами) нужно реализовать поддержку структурных типов в рантайме.

Я не на это отвечал. Потрудись таки прочесть собственную цитату, на которую был ответ.

AVK>>Хреново, надо сказать, существуют.
VD>Хреново? Расскажи нам в чем заключается эта хреновость.

В плохой совместимости со стандартной библиотекой и необходимости перехода от делегатов к функциональному типу и обратно.

VD> А еще лучше, не спорь о вкусе устриц с теми кто их ел.

Не хами. Тут еще неизвестно, кто из нас и в каком количестве ел устриц. И по поводу обсуждения квалификации в правилах имеется соотв. пункт, который для тебя никто не отменял.

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

AVK>Я не на это отвечал.

Но мы то об этом говорили. Отмазки что они там что-то переписывают не катят. 13 лет прошло. И переписывая даже проще что-то добавить. Плюс назвать переписыванием с нуля конвертацию 32-битной версии в 64-битную могут только бравые парни из МС.

AVK>В плохой совместимости со стандартной библиотекой и необходимости перехода от делегатов к функциональному типу и обратно.

Ты детали давай. Где плохая совместимость. С чем. Примеры приведи.

VD>> А еще лучше, не спорь о вкусе устриц с теми кто их ел.

AVK>Не хами.

Я хамлю? Ты заявляешь полнешую чушь, а я хамлю? Может разберешься в вопросе или хотя бы подумаешь для начала.

AVK>Тут еще неизвестно, кто из нас и в каком количестве ел устриц.

Ну, да. Ну, да...

Ну, так потрудись аргументировать свои голословные заявления. Раз ты эксперт, в обсуждаемой области, тебе не составит это труда.

AVK>И по поводу обсуждения квалификации в правилах имеется соотв. пункт, который для тебя никто не отменял.

Тут обсуждать нечего. Лепишь заявления с важным видом, а обосновать их не можешь.

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

AVK>>Я не на это отвечал.
VD>Но мы то об этом говорили.

Я процитировал твою фразу, на которую отвечал. А спор в стиле Сергинио, когда у тебя к4акие то свои образы в голове мне не интересен.

VD> Отмазки что они там что-то переписывают не катят.

Итак, ты опять не прочел на что я отвечал. Опять 5 итераций понадобится?

AVK>>В плохой совместимости со стандартной библиотекой и необходимости перехода от делегатов к функциональному типу и обратно.
VD>Ты детали давай. Где плохая совместимость. С чем. Примеры приведи.

Делегатов с новым типом. Берем, к примеру, Enumerable, а там одни делегаты. Что в твоем новом дивном мире с ними делать предполагается?

AVK>>Не хами.
VD>Я хамлю?

Да. И нарушаешь правила форума.

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

AVK>Делегатов с новым типом. Берем, к примеру, Enumerable, а там одни делегаты. Что в твоем новом дивном мире с ними делать предполагается?

С делегатами никаких проблем нет. Они являются подтипом функционального типа. Делегат совпадающий по сигнатуре с функциональном типом совместим с ним (может быть передан туда где ожидается функциональный тип). Под капотом функциональный тип может быть реализован через те же делегаты. Надо только ослабить некоторые проверки.

AVK>Да. И нарушаешь правила форума.

Факт отсутствия у тебя опыта, в конкретном вопросе, правилами не регулируются. Я же не говорю, что ты ламер? Я тебе указываю на то, что ты споришь о том в чем плохо разбираться. Причем споришь декларациями, не приводя никаких аргументов. Против такой демагогии невозможно возразить. Если бы ты попытался сформулировать свои претензии более конкретно, то и спорить бы не стал бы, скорее всего, так как понял бы, что никаких проблем введение более общего типа не вызовет.

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

_>Дык я сам против того чтобы они все попали в один язык суть в том чтобы под задачу какие-то возможности были а какие-то нет. В C++ мы же не инклудим сразу весь буст включая экспериментальные ветки, и не плачем когда обнаруживаем что (гипотетически) дефайны Server 2012 DDK конфликтуют с дефайнами WinPhone SDK. Вот макросы дают такую фишку как "фичи нужные по месту", и кроме них собственно больше никто не даёт.
Твой пример, кстати, не такой уж и гипотетичный: CefDOMNode methods conflicting with windowsx.h. Забавнее всего смотрится предложение переименовать методы. А вы тут говорите — метапрограммирование, АОП...