Здравствуйте, C.A.B, Вы писали:

CAB>>>Разве само МП не является "моделью вычислений"(с которой надо будет бороться)?
WH>>Нет.
CAB>Почему?

Метапрограммирование использует ту модель, которую ты используешь для собтсвенно решения задачи. Генеришь скажем код в ООП стиле — будет модель ООП. Генеришь код в функциональном стиле — будет модель функциональная. И тд. А вот так, что бы писать код и не использовать никакой вычислительной модели, такого не бывает, все базовые композиции — структурная, объектная, функциональная и тд нужно знать на зубок задолго до того, как берешься за метапрограммирование.
Причина этого явления в том, что конкретный вычислитель использует вполне конкретную вычислительную модель.

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

I>>Хороший дизайн в любой парадигме делать очень трудно. Вообще в любой. ООП здесь ничем особым не выделяется. Хоть ФП, хоть обобщенное, хоть макры — дизайнить апи модулей крайне непросто.
WH>Осталось понять, что делать дизайн на МП проще.
WH>Просто по тому, что нет навязанной вычислительной модели.

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

I>>Инверсия управления это так — вызывающий код становится вызываемым или так — обязанности из вызывающего кода кочуют в вызываемый или так — зависимости вызывающего кода кочуют в вызываемый. Собственно именно из за этой инверсии на ДСЛ так легко писать(тем кто в теме), — все что надо, из вызывающего ушло в вызываемый.
WH>Ничего не понял. Я знаю про IoC паттерн. Но как это всё к языкам относиться?
WH>Давай пример попроще.
WH>Где тут инверсия управления:

А что с чем сравнивать ? Вот если представить твой пример в виде ДСЛ, то получится например так, минимальный набор

Hello World!
Press any key to exit.
>

Теперь видно, что одна программа контролирует и время, и зависимости, и вызовы, а вторая — нет. Вот это и есть инверсия — вызывающий код стал вызываемым и тд. То есть, ДСЛ это true IOC.

I>>Ну так возьми в команду студента 2-3го курса и покажи как все круто. У меня в команде такие были, ООП им ничем не мешало.
WH>А почему ты думаешь, что МП им будет мешать?

Я знаю точно, что именно им мешает. В обычном программировании они видят код и этот код яляется собственно решением задачи. В метапрограммировании код уже не является решением задачи, он является решением задачи по генерации кода решения основной задачи. Даже с шаблонами, квазицитированием не все гладко — вместо того, что бы "посмотреть" нужно дополнять код из некоторого контекста. Соотственно продуктивность с МП у студентов много хуже чем без МП.
Вобщем любой meta-xxx требует, что бы xxx был прокачан до уровня "профи".

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

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

WH>>Хотя и тут ООП будет вставлять палки в колеса.
WH>>Посмотри, как можно сделать ДСЛ для ГУИ.
WH>>http://nemerlewebsamples.apphb.com/

WH>>Сравни с WPF на C#...

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

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

Когда зарелизимся, обязательно добавим побольше примеров, их создание много времени не занимает.
Потихоньку появляются люди, заинтересованные в том, чтобы помочь развитию проекта, но в любом случае рук не хватает. У всех участников много времени уходит на основную работу, поэтому на NemerleWeb не получается тратить столько времени, сколько хотелось бы.

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

T>Девелоперы не пишут на ИЛ, этот язык для прикладных и даже для фремворковых девелоперов чужой. Им нужно переводить все это в свой основной язык и поэтму все что я сказал про SRE абсолютно справедливо — результат ты или не увидишь вообще, или увидишь после н-приёмчиков.
Те вся проблема в том, что ИЛ слишком низкого уровня?

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

WH>>Осталось понять, что делать дизайн на МП проще.
WH>>Просто по тому, что нет навязанной вычислительной модели.
T>Этим можно пренебречь,
Ага, конечно.
Почитай флеймы на тему что от чего ножно наследовать.
Квадрат от прямоугольника или наоборот.

T>потому что проектирование взаимодействия само по себе крайне сложный процесс, непредсказуемый и нелинейный, и какой то вычислительной моделью можно спокойно пренебречь.
Нельзя. Ибо ты не можешь написать на языке то, что не ложится в его вычислительную модель.
И когда ты пишешь на C#, ты работаешь с его вычислительной моделью и не можешь сделать ничего другого.

T>Просто добавляется небольшой шажок, когда готовое взаимодействие нужно вписать по фиксированым правилам в конкретную систему. То есть, накопленого опыта уже достаточно, что бы любую систему за предсказуемое линейное время вписать в ОО-парадигму.
Вот только в результате этого шажка появляется куча не относящегося к делу кода.

T>А что с чем сравнивать ? Вот если представить твой пример в виде ДСЛ, то получится например так, минимальный набор
Отставить изобретать другие языки.
Покажи мне инверсию управления в приведенном коде.

T>Я знаю точно, что именно им мешает. В обычном программировании они видят код и этот код яляется собственно решением задачи.
А еще они видят кучу лапши из классов, паттернов накрученных над классами и прочего бреда.
Вот это всё очень сильно мешает.

T>В метапрограммировании код уже не является решением задачи, он является решением задачи по генерации кода решения основной задачи.
Это как это не является?
Вот это что такое?
https://github.com/rampelstinskin/ParserGenerator/blob/master/N2/N2.Grammar/GrammarParser2.n2
Это код решающий задачу разбора данного языка.

T>Даже с шаблонами, квазицитированием не все гладко — вместо того, что бы "посмотреть" нужно дополнять код из некоторого контекста. Соотственно продуктивность с МП у студентов много хуже чем без МП.
Проверял?

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

T>Метапрограммирование использует ту модель, которую ты используешь для собтсвенно решения задачи. Генеришь скажем код в ООП стиле — будет модель ООП. Генеришь код в функциональном стиле — будет модель функциональная. И тд.
Вот это источник твоего заблуждения.
Пока ты будешь так думать, ты ничего про ДСЛ не поймешь.

Тот код, который получается в результате переписывания, вообще никого не волнует.
Более того один и тот же ДСЛ можно переписывать в разные языки низкого уровня. Можно в хаскель. Можно в C#. Можно и в то и другое одновременно.

Главное в ДСЛ это вычислительная модель самого ДСЛ.
Всё остальное мелочи, не заслуживающие внимания.
И для того чтобы переписать код написанный на ДСЛ в C# тебе не нужно уметь делать ОО дизайн. О дизайне результата вообще думать не надо.
Ибо ты можешь генерировать любой говнокод.
Лишь бы работал.
А всё по тому, что генерируемый код не требует поддержки.
И всегда можно немного поправить генератор, после чего перегенерировать весь код.

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

T>Модель вычислений навязывает не ООП, а задача со своими требованиями и ограничениями. Сложность с дизайном в том, что это проектирование взаимодействия, а следовательно очень много элементов, которые влияют на конечное решение. Новичку просто невозможно взять в мозг все элементы.
Один из этих элементом это модель вычисления языка, на котором всё это будет реализовано. Дизайны решений для реализации на хаскеле и на C# не будет иметь между собой ничего общего. При этом будут содержать кучу мусора, которая к задаче не относится.

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

T>Я же доступно объяснил — ВПФ это очень сложная задача. Из того, что ООП это просто, никак не следует, что и ВПФ станет проще. Дизайн в люьбой парадигме на порядок сложнее самой парадигмы, с этим ничего не поделаешь.
О чем я тебе и толкую.
Круть ДСЛ в том, что когда мы его создаем, у нас нет навязанной языком реализации парадигмы.
Парадигма того языка в который происходит переписывание ни на что не влияет. Ваще. Совсем.
Нам просто не нужно думать о том, как мы будет поддерживать генерируемый код.
Поэтому мы можем генерировать любой говнокод с нарушением всех правил хорошего тона результирующего языка, за нарушение которых при ручной работе нужно отрывать руки.

Здравствуйте, Tanker, Вы писали:
CAB>>>>Разве само МП не является "моделью вычислений"(с которой надо будет бороться)?
WH>>>Нет.
CAB>>Почему?
T>Метапрограммирование использует ту модель, которую ты используешь для собтсвенно решения задачи.
Сначала давай определимся что же такое метапрограммирование? В моём понимании это процесс собственно создания метасредств, например макросов, DSL'ей и других программ создающих программы. А так как метасредства не являются voodoo, нужна некоторая вычислительная модель(модель вычислений), чтобы заставить это всё работать. Например в препроцессоре С этой моделью есть банальная подстановка текста.
Программирование с использованием метасредств(т.е. кода уже используется только модель задачи), ИМХО, называть МП не корректно, т.к. в это случае совершенно не обязательно знать о том как работает МП, и даже о том что оно существует.
T>Генеришь скажем код в ООП стиле — будет модель ООП. Генеришь код в функциональном стиле — будет модель функциональная. И тд.
Это ведь уже не программирование, это кодогенерация.
T>А вот так, что бы писать код и не использовать никакой вычислительной модели, такого не бывает, все базовые композиции — структурная, объектная, функциональная и тд нужно знать на зубок задолго до того, как берешься за метапрограммирование.
Зачем все? Думаю достаточно МП + то во что оно будет разворачиваться.
T>Причина этого явления в том, что конкретный вычислитель использует вполне конкретную вычислительную модель.
Не уловил связи между "конкретный вычислитель" и "все базовые композиции — структурная, объектная, функциональная и тд нужно знать на зубок"

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

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

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


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

M>Ага-ага. Потом такой вот гений уволится, а нагенерированый его поделкой говнокод будет вылезать боком в самых неожиданных местах, ага.

Далеко кстати ходить не надо. Никаких DSL тоже не надо.
Вот МС решили сделать генерацию кода из XSD: xsd.exe.
Тот же вопрос , кто это будет поддерживать если разработчик уволиться или как изменить нагенерированный код ?

За неимением ответа на вопрос, создали отдельный проект: Xsd2Code с открытым кодом, чтобы можно было корректировать генерацию.

P.S.
Конечно есть какой-то средний уровень разработчиков, однако, это не означает, что нужно писать ручной код для новичков.

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

T>>Я же доступно объяснил — ВПФ это очень сложная задача. Из того, что ООП это просто, никак не следует, что и ВПФ станет проще. Дизайн в люьбой парадигме на порядок сложнее самой парадигмы, с этим ничего не поделаешь.
WH>О чем я тебе и толкую.
WH>Круть ДСЛ в том, что когда мы его создаем, у нас нет навязанной языком реализации парадигмы.

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

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

Это заблуждение. Максимум продуктивности только на одном единственном языке, ну может двух. Отсюда следует, что тебе надо или N-тривиальных дсл, что практически ЯОН, или один-два-три на весь домен. Построй на досуге тот самй ДСЛ для инвентаризации, ну или для складского учета, или страхования и тебе все станет ясно.

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

Типичный проект любой из контор-гигантов представляет собой чудовище из самых разных кусков писаных в разные времена неизвестно кем, меняются команды, руководители, технологии, а код остаётся. И вдруг случается чудо — требования изменились, кому то надо разобраться в твоем ДСЛ что бы заимпрувить его. В большом проекте я буквально не знаю, какая часть что и как делает, то есть вообще. И дело не в количестве кода,а в количестве требований, которые надо усвоить что бы более-менее адекватно представлять происходящее. Соответсвенно если ктото до меня использовал дсл или просто другой язык, эту часть приходится при необходимости подымать с большим трудом, потому что во первых, никого нет из тех кто начинал, во вторых, требования изменились слишком сильно(иначе вопрос бы не стоял) и варианты такие — прикруть сбоку мульку, разобраться с ДСЛ и расширить его, или вообще переписать все.
Как ты понимаешь, выбирается тот вариант, который заапрувит бизнес. Мулька сбоку как правило оказывается проще, чем хотя бы разобраться в ДСЛ. Потому до того, как ДСЛ полностью выдохнется, он обрастет вагоном хаков, костылей и подпорок к этим костылям.

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

T>>Модель вычислений навязывает не ООП, а задача со своими требованиями и ограничениями. Сложность с дизайном в том, что это проектирование взаимодействия, а следовательно очень много элементов, которые влияют на конечное решение. Новичку просто невозможно взять в мозг все элементы.
WH>Один из этих элементом это модель вычисления языка, на котором всё это будет реализовано. Дизайны решений для реализации на хаскеле и на C# не будет иметь между собой ничего общего. При этом будут содержать кучу мусора, которая к задаче не относится.

Это смотря какие требования. Как только доходит дело до взаимодействия, как во всех функциональных языках появляется эмуляция ООП. Если тебе придет в голову написать на хаскеле хотя бы полноценный richedit, сразу станет ясно, что к чему.

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

WH>Тот код, который получается в результате переписывания, вообще никого не волнует.

Он что, сам пишется и сам выполняется и сам же отлаживается ?

WH>И для того чтобы переписать код написанный на ДСЛ в C# тебе не нужно уметь делать ОО дизайн. О дизайне результата вообще думать не надо.

ДСЛ и есть дизайн. Эта задача на порядок сложнее чем та о которой ты говоришь.

WH>Ибо ты можешь генерировать любой говнокод.
WH>Лишь бы работал.
WH>А всё по тому, что генерируемый код не требует поддержки.

Это слишком сильное утверждение.

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

WH>Ага, конечно.
WH>Почитай флеймы на тему что от чего ножно наследовать.
WH>Квадрат от прямоугольника или наоборот.

Реши ту же самую задачу в терминах хоть ФЯ, хоть макров, хоть мега-дсл и перед тобой встанут те же самые проблемы.

T>>потому что проектирование взаимодействия само по себе крайне сложный процесс, непредсказуемый и нелинейный, и какой то вычислительной моделью можно спокойно пренебречь.
WH> Нельзя. Ибо ты не можешь написать на языке то, что не ложится в его вычислительную модель.
WH>И когда ты пишешь на C#, ты работаешь с его вычислительной моделью и не можешь сделать ничего другого.

При этом задача проектирования взаимодействия на порядок сложнее.

WH> Вот только в результате этого шажка появляется куча не относящегося к делу кода.

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

T>>А что с чем сравнивать ? Вот если представить твой пример в виде ДСЛ, то получится например так, минимальный набор
WH>Отставить изобретать другие языки.

А можно я буду лучше знать, о чем же я говорил ?

WH>Покажи мне инверсию управления в приведенном коде.

Инверсия предполагает два варианта, один до, другой — после. Я показал тебе второй вариант, как сделать инверсию управления с помощью дсл и это именно то о чем я говорил изначально.

T>>Я знаю точно, что именно им мешает. В обычном программировании они видят код и этот код яляется собственно решением задачи.
WH>А еще они видят кучу лапши из классов, паттернов накрученных над классами и прочего бреда.
WH>Вот это всё очень сильно мешает.

Не фатально. Когда они не видят код решения основной задачи, они вообще ничего не могут сделать. А это уже фатально.

T>>В метапрограммировании код уже не является решением задачи, он является решением задачи по генерации кода решения основной задачи.
WH>Это как это не является?

Очень просто. Это для тебя какой то код является решением. А для разработчика это просто незнакомый текст.

WH>Вот это что такое?
WH>https://github.com/rampelstinskin/ParserGenerator/blob/master/N2/N2.Grammar/GrammarParser2.n2
WH>Это код решающий задачу разбора данного языка.

Это общий случай МП, я так понимаю ? Ну и предполагается, что студент, который пишет на С#, внезапно каким то чудом поймет такие вещи ?

T>>Даже с шаблонами, квазицитированием не все гладко — вместо того, что бы "посмотреть" нужно дополнять код из некоторого контекста. Соотственно продуктивность с МП у студентов много хуже чем без МП.
WH>Проверял?

А как же.

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

T>>Девелоперы не пишут на ИЛ, этот язык для прикладных и даже для фремворковых девелоперов чужой. Им нужно переводить все это в свой основной язык и поэтму все что я сказал про SRE абсолютно справедливо — результат ты или не увидишь вообще, или увидишь после н-приёмчиков.
WH>Те вся проблема в том, что ИЛ слишком низкого уровня?

Не важно, выше или ниже. Главное что он отличается от того уровня уверенности, на котором работает разработчик. Этот уровень определяется степерью прокачки понятий. То есть, у разработчика в голове строго определенный набор абстракций, которые соответствуют его опыту, других просто нет и скопировать просто невозможно. ДСЛ ничего не изменит у разраба в голове. Вот когда понятия будут прокачаны максимально глубоко, вот тогда от ДСЛ будет польза.
Knowledge transfer не компенсирует отставание, а опыт набирается только проверкой руками.
В большинсве бизнес-приложений такой момент никогда не наступает, вот в чем проблема, бизнес зачастую сам не дает до конца формализовать задачу, никто не будет ждать пока ты формализуешь и родишь ДСЛ под такую область как инвентаризация.
Кроме того, переключаться между языками дело очень затратное, а продуктивность на основном языке на порядки! выше чем на остальных.

T> В большинсве бизнес-приложений такой момент никогда не наступает, вот в чем проблема, бизнес зачастую сам не дает до конца формализовать задачу, никто не будет ждать пока ты формализуешь и родишь ДСЛ под такую область как инвентаризация.

Хохо-хо. Инвентаризация — это слишком просто. Можно попытаться описать такую область, как выдача микрокредитов (риски + оплата нам от магазинов + оплата нам от клиентов + оплата от нас магазинам + оплата от нас клиентам + dunning + debt collection, и все это замешано на рассрочках, кампаниях, прямых и отложенных оплатах, разных условиях для разных стран, валют и магазинов, и все еще сливается в бухгалтерию, как нашу, так и магазинов).

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

M>Ага-ага. Потом такой вот гений уволится, а нагенерированый его поделкой говнокод будет вылезать боком в самых неожиданных местах, ага.

А действительно будешь править нагенерированный говнокод, а не код на ДСЛ и кодогенератор? Тогда конечно вылезет боком. Но это как раз об этом в той пословице говорилось — "Заставь дурака богу молиться он лоб расшибет.".

В твоем мышлении есть одна ошибка. Ты почему-то не верно оцениваешь сложность поддержки рукописного кода. Если решения задачи можно сгенерировать по существенно более простой/короткой/ясной модели, то сравнимое по характеристикам рукописаное решение будет несоизмеримо сложно. И поддерживать его будет сложно просто из-за огромного объема кода и неизбежных для такого объема ошибок в проектировании и реализации.

Чем более концептуальная ошибка/изменение, тем сложнее ее устранить/сделать в рукописном коде. В решение же на базе ДСЛ и кодогенерации это не критично, так как изменив код генератора можно устранить ошибку без полного переписывания кода.

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

WH>Главное в ДСЛ это вычислительная модель самого ДСЛ.
WH>Всё остальное мелочи, не заслуживающие внимания.

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

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

VD>Если решения задачи можно сгенерировать по существенно более простой/короткой/ясной модели, то сравнимое по характеристикам рукописаное решение будет несоизмеримо сложно. И поддерживать его будет сложно просто из-за огромного объема кода и неизбежных для такого объема ошибок в проектировании и реализации.

+ при рукописном решении намного больше соблазн пофиксить подпоркой "вот тута, где оно глючит", а не разбираться в глубинных причинах, зачастую в кривости архитектуры, симптом которой проявился в ошибке

а вот в ДСЛ выбора нету — нужно переосмыслить и фиксить на корню

Ну и меньше кода — всегда лучше.
имхо