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

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

В данном случае я писал конкретно про макрос late, а не про макросы вообще.

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

LCR>А, то есть ты ищешь фичу, которую МС в принципе может включить, но не включает из вредности? Боюсь, таких фич нет. Разве что незначительный синтаксический сахар.

Ну дак весь топик посвещен теме "Почему МС не включает ту или иную фичу. Или включает, но медленно". Мой ответ на вопрос: для МС приоритетно прикладное развитие фреймворка, а не отдельно взятого языка.

V>>А ради чего все это?
LCR>Ради выявления как можно большего количества ошибок на этапе компиляции.

И добавления новых?

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

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

VD>>А теперь попытайся с помощью своего кода загрузить тот самый Ёксель, открыть им файл с диска и распечатать страничку.

V>Ты сомневаешься, что тот класс можно доработать так, чтобы он ком загружать умел?

Не сомневаюсь, только он окажется дай бог хотя бы таким же сложным, как макрос; а то и превзойдет его на порядок. Отлаживать его будет не проще.

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

V>Меня не интересует техническая реализация решения — запрограммировать не проблема, это дело техники, прошу прощения за тафталогию. Сложность не в этом.
Это самая очевидная позиция. Лично меня всегда пугает перспектива оказаться в роли "спешного пилильщика тупой пилой". А вдруг мы просто не видим чего-то менее очевидного?
VD>>Простой пример. Ты знаком с XSLT?

V>Замечательно, но только при условии, что программы, написанные на разных языках, не будут смешиваться друг с другом. "Котлеты отдельно, мухи отдельно".
Вот этот момент мне не до конца понятен. По моему опыту, всё как раз наоборот. Я имею примерно 20 лет опыта работы с СУБД; из них примерно 10 — с SQL.
И все эти 10 лет были в том или ином виде посвящены борьбе с границами между языком клиента и языком сервера. Предметная область-то одна! А мне приходится искусственно проводить границы. При этом компилятор клиента ничего не знает про сервер и помочь мне не может, а сервер ничего не знает о клиенте.

И тут появляется Linq, и становится понятно — вот оно! Всё, нет границы между языками манипуляции данными. Я получаю статический контроль всего и поддержку рефакторинга! Что, это плохо? Нет, это именно как оно и должно быть.

Помедитируй над этим примером. Лично у меня есть великое искушение обобщить такой подход и на другие, традиционно изолированные области:
— web client/web server (некоторые шаги в эту сторону делает ASP.NET MVC Framework и мне это очень нравится)
— сборка инсталляторов
— вообще управление сборкой и тестированием проектов

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

V>>Меня не интересует техническая реализация решения — запрограммировать не проблема, это дело техники, прошу прощения за тафталогию. Сложность не в этом.
S>Это самая очевидная позиция. Лично меня всегда пугает перспектива оказаться в роли "спешного пилильщика тупой пилой". А вдруг мы просто не видим чего-то менее очевидного?

ИМХО, здесь самое главное — это идентифицировать проблему, а уж найти решение — это уже дело техники. Современные языки программирование достаточно мощны, чтобы справиться с большенством из них. "Нерешаемая" проблема динамического обращения к свойствам и методам это наглядно продемонстрировала.

S>Вот этот момент мне не до конца понятен. По моему опыту, всё как раз наоборот. Я имею примерно 20 лет опыта работы с СУБД; из них примерно 10 — с SQL.
S>И все эти 10 лет были в том или ином виде посвящены борьбе с границами между языком клиента и языком сервера. Предметная область-то одна! А мне приходится искусственно проводить границы. При этом компилятор клиента ничего не знает про сервер и помочь мне не может, а сервер ничего не знает о клиенте.

S>И тут появляется Linq, и становится понятно — вот оно! Всё, нет границы между языками манипуляции данными. Я получаю статический контроль всего и поддержку рефакторинга! Что, это плохо? Нет, это именно как оно и должно быть.

Тут возможны два варианта использования DSL'я
Первый (для меня, наверное, самый важный) — это когда у нас есть некая система сама в себе, и мы выставляем наружу DSL для людей, не являщихся программистами, которые в понятных им терминах предметной области смогут описывать нужное им поведение. Например, бизнес-аналитик на чем-то более человечном и приземленным, нежели BPEL, описывает нужный ему бизнес-процесс и сам же его запускает.

Второй вариант — это DSL для программистов. То есть когда прогаммисты сами для себя придумывают свои собственные новые языки программирования. По-этому, твой пример с Linq vs SQL+XPath не совсем в тему, так как это общеизвестные языки. А что касается дээселей, то тут можно вспомнить пример из жизни. Иногда, люди специально придумывают себе язык. Нпример, бейсболисты. Но у них есть на это существенные основания: 1) не надрывать горло; 2)держать план в тайне от соперников. Но в повседневной жизни люди обычно не придумывают новые языки, так как это усложняет общение. Я не говорю, что макросы и метопрограммирование бесполезны. Я хочу сказать, что их значимость для прикладных программистов сильно переоценена некоторыми посетителями этого форума и именно по-этому они не понимают действия Майкрософта.

S>Помедитируй над этим примером. Лично у меня есть великое искушение обобщить такой подход и на другие, традиционно изолированные области:
S>- web client/web server (некоторые шаги в эту сторону делает ASP.NET MVC Framework и мне это очень нравится)
S>- сборка инсталляторов
S>- вообще управление сборкой и тестированием проектов
Хм.. Какой подход обобщить? Что ты имеешь ввиду?

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

V>>Ты сомневаешься, что тот класс можно доработать так, чтобы он ком загружать умел?

VE>Не сомневаюсь, только он окажется дай бог хотя бы таким же сложным, как макрос; а то и превзойдет его на порядок. Отлаживать его будет не проще.

Согласен, но дело не в этом. Выше утверждалось, что для программиста существуют только три варианта: 1) копипастить макароны; 2) использовать метопрограммирование; 3) ждать, пока МС реализует dynamic в компиляторе. Я показал, что это неверно.

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

V>Тут возможны два варианта использования DSL'я
V>Первый (для меня, наверное, самый важный) — это когда у нас есть некая система сама в себе, и мы выставляем наружу DSL для людей, не являщихся программистами, которые в понятных им терминах предметной области смогут описывать нужное им поведение. Например, бизнес-аналитик на чем-то более человечном и приземленным, нежели BPEL, описывает нужный ему бизнес-процесс и сам же его запускает.
Для меня это как раз маловажный вариант использования. Вся проблема любого ЯП — в том, что он формальный. Умение формализовать задачу из предметной области — редкое умение. Именно оно отличает программиста от непрограммиста, а не запись в трудовой книжке.
Поэтому реально важнее второй вариант: вместо того, чтобы отдать программирование в руки непрограммистов, лучше дать инструмент улучшения производительности труда программистам.

V>Второй вариант — это DSL для программистов. То есть когда прогаммисты сами для себя придумывают свои собственные новые языки программирования. По-этому, твой пример с Linq vs SQL+XPath не совсем в тему, так как это общеизвестные языки.
Что такое "общеизвестные языки"???
Пример как раз в тему. Пока ты его не поймешь, дальше двигаться в беседе не получится.
Поясню историю на пальцах, по шагам:
1. Обработка данных на стандартных языках общего назначения (см. напр. file of record в Паскале). Чудовищный кошмар: низкая производительность, низкая надежность. Очень плохая производительность труда программистов.
2. Берем специальный императивный язык для управления данными, встраиваем в него убогие возможности общего назначения (см. dBase, Сlipper). Чудовищный кошмар: низкая производительность, низкая надежность. Плохая производительность труда программистов.
3. Придумыаем специальный декларативный язык для управления данными, подразумевая принципиальное двуязычие разрабатываемой системы (SQL+*). Нормальный кошмар: высокая производительность, высокая надежность готовой системы. Приемлемая производительность труда программистов.
4. Встраиваем декларативные средства по управлению данными в императивный язык (Linq). Безграничный восторг: высокая производительность, высокая надежность, в том числе и при внесении изменений в систему, охренительная производительность труда программиста.
Как видим, отдельный DSL недостаточно хорошо нам помогаетю

V> А что касается дээселей, то тут можно вспомнить пример из жизни. Иногда, люди специально придумывают себе язык. Нпример, бейсболисты. Но у них есть на это существенные основания: 1) не надрывать горло; 2)держать план в тайне от соперников. Но в повседневной жизни люди обычно не придумывают новые языки, так как это усложняет общение.
Отличный пример. Только он про наоборот: в повседневной жизни люди всё время придумывают новые языки. Иногда время жизни этих языков ограничено временем совместно решаемой небольшим коллективом задачи; иногда язык формирует целый диалект профессионального сообщества.
Но при этом люди почти никогда не придумывают отдельных языков. Жаргон бесшовно встраивается в окружающий его язык "общего назначения". В противном случае его выразительность была бы чрезмерно ограничена.

V>Я не говорю, что макросы и метопрограммирование бесполезны. Я хочу сказать, что их значимость для прикладных программистов сильно переоценена некоторыми посетителями этого форума и именно по-этому они не понимают действия Майкрософта.
Я констатирую факт: значимость DSL для Майкрософт значительно выше, чем для тебя. При этом все их действия показывают, что именно встроенные в язык DSL считаются правильным медом(ТМ).


V>Хм.. Какой подход обобщить? Что ты имеешь ввиду?
Я имею в виду подход с встраиванием DSL в существующий язык общего назначения. Одно из возможных средств для этого — макросы и метапрограммирование.

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

V> Я показал, что это неверно.
Ты всего лишь показал, что на turing-complete языке запрограммировать можно всё, что угодно.

С тем же успехом можно было обобщить твои рассуждения на, скажем, генерик-типы.
Я бы говорил, что программиста есть ровно три варианта, а ты бы говорил, что List object'ов вполне приемлемый результат.

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

V>Вот сколько я занимаюсь программированием, ни разу не видел SRS в котором бы был FR "Lazy computations". С его бы это?

ИНИЦИАТИВА СНИЗУ.
(пьеса)

Действующие лица:

Paul Hudak
John Hughes
Simon Peyton Jones
Philip Wadler — глыбы, матерые человечищи.

Ходоки — заклинатели змей из Бангалора.

Сцена 1.

Октябрь 87-го. Hudak, Hughes, SPJ, Wadler пьют чай и обсуждают планы грядущей функциональной революции.

SPJ

Так дело не пойдет, товарищи! Нам архиважна свежая струя пролетарских реквестов!

Сцена 2.

Входят ходоки.

1-й ходок

Народу нужен чистый, ленивый язык!

SPJ

Правильно мыслите, товарищи!

Hudak

Совершенно верно!

2-й ходок

Реквестируем монад и стрелок. Да побольше!

Hughes, Wadler (хором)

Сделаем!

3-й ходок

И не забудьте сделать так, чтобы ad-hoc полиморфизм был несколько менее ad-hoc.

Wadler

А это идея...

З А H А В Е С.

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

S> При этом все их действия показывают, что именно встроенные в язык DSL считаются правильным медом(ТМ).

Ну, это ты загнул. Есть ведь, к примеру, DSL Tools, есть всякие .dbml, .edml. Microsoft выбирает то, что в каждом конкретном случае оптимально.

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

AVK>Ну, это ты загнул. Есть ведь, к примеру, DSL Tools, есть всякие .dbml, .edml. Microsoft выбирает то, что в каждом конкретном случае оптимально.
Согласен. Видно, что далеко не все DSL они готовы приветствовать в шарпе
Тем не менее, на моей памяти это чуть ли не первый раз, когда в язык общего назначения добавляют такие штуки.

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

V>>Первый (для меня, наверное, самый важный) — это когда у нас есть некая система сама в себе, и мы выставляем наружу DSL для людей, не являщихся программистами, которые в понятных им терминах предметной области смогут описывать нужное им поведение. Например, бизнес-аналитик на чем-то более человечном и приземленным, нежели BPEL, описывает нужный ему бизнес-процесс и сам же его запускает.
S>Для меня это как раз маловажный вариант использования. Вся проблема любого ЯП — в том, что он формальный. Умение формализовать задачу из предметной области — редкое умение. Именно оно отличает программиста от непрограммиста, а не запись в трудовой книжке.

Вообще-то, бизнес-аналитик для того и нужен, чтобы формализовать задачу. Работа у него такая.

V>>Второй вариант — это DSL для программистов. То есть когда прогаммисты сами для себя придумывают свои собственные новые языки программирования. По-этому, твой пример с Linq vs SQL+XPath не совсем в тему, так как это общеизвестные языки.
S>Что такое "общеизвестные языки"???

Общеизвестные языки — это такие языки, знание которых можно можно выставить в качестве требования к вакансии, и новому сотруднику не придется их учить на месте.

S>4. Встраиваем декларативные средства по управлению данными в императивный язык (Linq). Безграничный восторг: высокая производительность, высокая надежность, в том числе и при внесении изменений в систему, охренительная производительность труда программиста.
S>Как видим, отдельный DSL недостаточно хорошо нам помогаетю

Напомню, что DSL расшифровывается, как Domain Specific Language. Linq — это язык запросов общего назначения и его домен полностью покрывается доменом языка программирования общего назначения. Linq не несет с собой никакого специфического домена в язык программирования общего назначения, по-этому он не является DSL-ем. А вот если бы Майкрософт встроил бы в си-шарп язык описания бизнес-процессов, то вот это уже был бы встроенный DSL.

S>Отличный пример. Только он про наоборот: в повседневной жизни люди всё время придумывают новые языки. Иногда время жизни этих языков ограничено временем совместно решаемой небольшим коллективом задачи; иногда язык формирует целый диалект профессионального сообщества.
S>Но при этом люди почти никогда не придумывают отдельных языков. Жаргон бесшовно встраивается в окружающий его язык "общего назначения". В противном случае его выразительность была бы чрезмерно ограничена.

Профессиональные сообщества придумывают новые слова, а не новый синтаксис.

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

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

V>> Я показал, что это неверно.
S>Ты всего лишь показал, что на turing-complete языке запрограммировать можно всё, что угодно.

А к чему тогда было заявление, что единственный оставшийся вариант — это копипаст лапша-кода?

S>С тем же успехом можно было обобщить твои рассуждения на, скажем, генерик-типы.
S>Я бы говорил, что программиста есть ровно три варианта, а ты бы говорил, что List object'ов вполне приемлемый результат.

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

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

V>Знаешь, когда я пересаживался с С++ на первый сишарп, тоже по началу долго плевался на отсутствие типизированных коллекций. Но реально особых проблем с этим не было. Вообще не помню, чтобы InvalidCastException было проблемой. Потом, когда появились джинерики, я не могу сказать, что производительность труда сильно увеличилась. Ну да, стало немного удобнее, но не более того.
Ну, если тебе дженерики не увеличили производительность труда, то действительно, интересоваться макросами смысла нет.

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

V>Профессиональные сообщества придумывают новые слова, а не новый синтаксис.

Вам не нравится именно новый синтаксис?
Но ведь ваш EDSL для позднего связывания как раз вводит новый синтаксис вызова методов, а макрос late оставляет синтаксис вызова методов неизменным.

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

K>>В чем принципиальная разница с любой другой библиотекой?
V>В том, что отлаживается непосредственно программа, которая падает, а не программа, которая генерирует другую программу, которая падает. Чувствуешь разницу?

Если есть compile-time кодогенератор, можно отлаживать и кодогенератор и сгенерированный код отдельно. В случае с интерпретатором, который вы продемонстрировали, отлаживать код на EDSL можно только вместе c интерпретатором EDSL.
Вместо программы, которая генерирует другую программу, вы имеете программу, которая интерпретирует другую программу, какие недостатки есть в первом случае, а во втором отсутствуют?
Что касается разницы с любой другой библиотекой — в одном случае вы можете получить неправильные данные из сторонней библиотеки, в другом случае — неправильный код. Разница есть только в том случае, если считать, что есть разница между кодом и данными — а это вопрос дискуссионный, если не просто технический, касающийся реализации. Если уж на то пошло, в управляемый средах код и так уже является данными, но только в рантайме, а не в компайлтайме.

K>>Вот и prVovik встроил в язык мини динамический DSL. От макроса он отличается тем, что DSL у него не компилируемый, а интерпретируемый — в чем преимущество мне не понятно. Также автор отмечает облегчение при отладке. Это мне тоже не понять. Неужто отлаживать код на DSL вместе с интерпретатором этого DSL каждый раз это удобнее, чем отлаживать сгенерированный код?
K>>Где бенефиты-то?
V>И в чем проявляется компилируемость макроса, если доступ с проверками к свойствам и методам всеравно происходят в рантайме?

Мы начали с того, что вы утверждали, что ваш EDSL интерпретатор лучше, чем компилятор, а теперь уже приходим к тому, что нет разницы? Вообще, разница есть даже в этом случае, который и так динамический и разница, конечно, не велика.

V>Соответственно, толку от компайлтайма нет вообще никакого и работают они совершенно одинаково. Разница только маленьком количестве синтаксического сахара.

Т.е. ваше отношение к синтаксису зависит от того, насколько оно поддерживает вашу точку зрения? Так дело не пойдет.

Разница, как минимум, в двух вещах.
1) Вы не можете отлаживать код на своем EDSL не отлаживая при этом интерпретатор, а зачем программисту, использующему EDSL копаться во внутренностях интерпретатора мне не понятно.
2) Ваш EDSL интерпретатор вводит новый синтаксис вызова методов — макрос оставляет синтаксис неизменным.

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

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

M>>Законы эволюции на кривой кобыле не объедешь. Они объективны.

IT>Законы эволюции были объеханы примерно 30-50 тыщ лет назад на кобыле, называемой речь. Обмен информацией по сравнению с генами ускорился на многие порядки, в результате чего наш вид очень быстро стал доминировать на планете.

Хм... Начало доминирования вида, имнип, как бы раньше прихода второй сигнальной констатируют. Нет?

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

IT>Что касается Немерле, то в нём есть вещи, способные ускорить эволюционные процессы, теже макросы, о которых говорит Влад. Конечно, это ускорение не на порядки, а всего лишь в разы, но надежда есть.

Ускорить "эволюционные процессы" — это вряли... Ибо "законы эволюции на кривой кобыле не объедешь. Они объективны." (с). Да и с "НТП", имхо, напряг... т.к. макросы — даже в немерле — никак не тянут на то, чтобы стать "сигналом сигналов" (с) И.П. Павлов.

Другой уровень, знаете ли

---
С уважением, Сиваков Константин.

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

K>Если есть compile-time кодогенератор, можно отлаживать и кодогенератор и сгенерированный код отдельно. В случае с интерпретатором, который вы продемонстрировали, отлаживать код на EDSL можно только вместе c интерпретатором EDSL.
Ну да, нажать "Step Over" — это очень трудно.

K>Вместо программы, которая генерирует другую программу, вы имеете программу, которая интерпретирует другую программу, какие недостатки есть в первом случае, а во втором отсутствуют?

Такие что макрос можно отлаживать только во время компиляции, а ошибка может вылетать во время работы. Эти два момента сильно разнесены по времени.

K>Мы начали с того, что вы утверждали, что ваш EDSL интерпретатор лучше, чем компилятор, а теперь уже приходим к тому, что нет разницы? Вообще, разница есть даже в этом случае, который и так динамический и разница, конечно, не велика.

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

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

V>Ты, наверное, умеешь и диагноз по фотографиям ставить, не так ли?

В общем случае — нет. Но есть такие физиономии по которым диагноз виден невооруженным взглядом.

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

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

Плохая у тебя память. навскидку, к примеру, вспоминается добавление в Дельфи специальной поддержки СОМ — интерфейсы, делегация, позднее связывание, автоматичный рефкаунтинг. Да и foreach в шарпе по сути эдакий мини DSL.