Из десятка проектов на дотнете, я видел только один активно использующий XML как DSL - там вьюшки собирались в страницы из компонент. Ну и WPF еще бывает, да, но я не трогал.
Короче половина проекта на XML - это вроде больше про яву.
И лиспы как DSL для дотнета - в топку. Они не типизированы, и это в реалиях энтерпрайза - жопа. Такая же точно как XML - только букв меньше, код загадочнее, и поддержки IDE нет. В дотнете есть средства делать eDSL и метапрограммировать не убирая типизацию - вот ими и надо пользоваться.
>В дотнете есть средства делать eDSL и метапрограммировать не убирая типизацию - вот ими и надо пользоваться.
Какие это такие "типизированные" мегасредства для eDSL и метапрограммировать есть в дотнете, и почему я, разработчик с минимум 7-летним опытом в дотнете, чуть ли не наизусть знающий мельчайшие его детали с версии 2, о них не знаю?
Objects/array literals, fluent interfaces, LINQ, expression trees, аттрибуты, рефлекшн, генерация MSIL налету, интроспекция и изменение сборок через post sharp и т.п., и т.д. А еще Roslyn выходит, и есть F# давно, так что вообще грех жаловаться.
Parser<string> identifier =
from leading in Parse.WhiteSpace.Many()
from first in Parse.Letter.Once()
from rest in Parse.LetterOrDigit.Many()
from trailing in Parse.WhiteSpace.Many()
select new string(first.Concat(rest).ToArray());
Супротив аналогичной XML-ки или лиспа - оно тайпчекается и держит рефакторинг.
Я бы не сказал что у какого-нибудь хаскеля инструментов для того же самого сильно больше. Лаконичнее и прямее - это да, но качественно там примерно тоже самое.
>Objects/array literals Средство метапрограммирование? Шта?
>fluent interfaces Туда же
>LINQ LINQ, и его Expression trees - крайне ограниченная вещь. Это API работы с коллекциями и реляционными запросами. Максимум что из нее можно было выжать это Rx. Но сам по себе LINQ и его реализации это не метапрограммирование вообще никаких боком, это обычное функцональное API. Монада, если угодно.
>Expression trees, Expression trees - самое интересное и хоть сколько-то относящееся к метапрограммированию из перечисленного. Фактически это урезанное AST C#. Типизация тут вообще никоим боком, на самом деле, потому что самая важная и крутая фича этого API это динамическая генерация и обработка кода на C#. Но по сравнению с возможностями современных реализаций лиспа, Expression Trees это просто детский сад. А еще - ты ими в продакшне пользовался хоть раз то? Я вот регулярно. И могу сказать - по сравнению с лиспами - они сложны и использовании, ограничены, и намноого менее юзабельны, чем встроенные инструменты самого простейшего даже лиспа, типа емаксового.
Далее >аттрибуты, рефлекшн, генерация MSIL налету, интроспекция Это все как раз мной в том числе активно используется(чем кстати интроспекция от рефлекшн отличается ггг?), но по сравнению с инструментами лиспа того же, это все крайне убого, громоздко и отвратительно, это во-первых, а во-вторых, опять же - ни в коем случае не типизировано. Используя эти инструменты, программист на C# или любом другом языке .NET фактически переизобретает лисп-систему через жопу, а даже скорее не лисп-систему, а недо-питон какой-нибудь.
>и изменение сборок через post sharp PostSharp вот это уже ближе, но это настолько через жопу достигается(и кстати платно), что Типизированным Достоинством Дотнета я бы это не назвал даже в бреду.
>А еще Roslyn выходит Roslyn еще не вышел, но мне тоже интересно, что еще MS утащит из лиспа в очередной раз.
>и есть F# давно F# к метапрограммирования никоим боком.
Максимально декларативно описывать модель данных, генерировать ее из этого описания, вдобавок к этому декларативно описывать модель джойнов данных, и метаданные свойств(полей классов), для гридов и вообще любых UI-контролов, и опять же, генерировать гриды и контролы из этого. Плюс к этому, декларативным и внятным DSL-ем описать модель воркфлоу бизнес-логики и разнообразные валидаторы и функции перехода состояний объектов и комбинаций состояний объектов.
Отчасти это у меня в текущем проекте делается. Естественно, через рефлекшн и подобное, с описаниями в XML. Но выглядит это, хм ... Ну хотя, намного лучше и(особенно) компактнее и яснее, чем тупым хардкодом на C#, с типизацией и прочим.
Все это делается без всяких XML, на голом C# - указанными выше средствами. "Тупой хардкод" - плохой аргумент за использование XML для этой цели. Я не вижу ни одного плюса у XML относительно C#.
Классы модели данных можно генерировать из одной сборки в другую. Я вот генерирую typescript, например. Но не вижу препятствий зафигачить eDSL-код для конфигурации модели данных в отдельной сборке, и генерить из этой сборки C# классы для всего остального.
Метаданные навешиваются аттрибутами и fluent-интерфейсами. В отличии от XML имеется возможность втыкать в метаданные логику, например .Condition(s => s == Sex.Male).
Стейт-машины, бизнес-процессы, валидация, и прочее - тоже вполне себе нормально делается.
Да, eDSL на C#, да и вообще любые eDSL проиграют по прямоте правильно сделанным DSL отдельным.
Но лисп - это тоже ведь нифига не правильно сделанный DSL. Это general-purpose-язык, со своим мешком проблем, который ты хочешь как-то хостить в дотнете, и на котором ты планируешь делать eDSL.
Если писать вообще всё на какой-нибудь там кложури - такое можно. Но нужно понимать что никакой серебрянной пули от этого не случится.
>В отличии от XML имеется возможность втыкать в метаданные логику, например .Condition(s => s == Sex.Male).
Ээээ. В XML ты вообще-то можешь втыкать вообще всё, что придумаешь. XML это просто язык разметки.
>Стейт-машины, бизнес-процессы, валидация, и прочее - тоже вполне себе нормально делается.
Нет. У нас была недоделанная стейт-машина на аттрибутах. Я выкинул, за 2 дня написал с XML. Аттрибуты остались для валидации переходов стейтов. Но это тоже надо выкинуть в XML, по идее. Потому что это банально меньше кода, потому что проще, потому что код яснее выглядит, итд. На C# DSL тупо не сделать нормально. XML позволяет хоть какое-то подобие.
>Но лисп - это тоже ведь нифига не правильно сделанный DSL. Это general-purpose-язык, со своим мешком проблем, который ты хочешь как-то хостить в дотнете, и на котором ты планируешь делать eDSL.
Как старый лиспер, авторитетно заявляю: Лисп это не то что не DSL, лисп это вообще не язык программирования. Это метаязыковая среда.
XML - нормальный язык разметки документов. При этом XML - плохой хост для eDSL. Он даже как формат сериализации плох.
Не надо стейт-машину делать на аттрибутах. Надо делать что-нибудь, например, такое:
Transition(
from: State.Draft,
to: State.Published,
verb: "Publish"
)
.Precondition((entity, context) => context.User.IsManager(), description: "You must be a manager to publish entities")
.Precondition((entity, context) => entity.IsValid(), description: "All fields should be specified correctly to publish entity")
.SideEffect(entity => new AddToNewsFeed(entity.ID);
.PostTransitionTask(entity => new SendPublishNotificationTask(entity.ID));
...
>XML - нормальный язык разметки документов. При этом XML - плохой хост для eDSL. Он даже как формат сериализации плох.
Ну какой есть. Привыкли. Хотя я бы все на S-выражениях делал.
> Transition( from: State.Draft, to: State.Published, verb: "Publish" ) .Precondition((entity, context) => context.User.IsManager(), description: "You must be a manager to publish entities") .Precondition((entity, context) => entity.IsValid(), description: "All fields should be specified correctly to publish entity") .SideEffect(entity => new AddToNewsFeed(entity.ID); .PostTransitionTask(entity => new SendPublishNotificationTask(entity.ID));
Кошмар. Вот у меня это описывается в 2 строки в XML абсолютно декларативно, без всякого там "entity, context => ..." и прочего, плюс 1 аттрибут в 15 символов считая квадратные скобки, плюс две стринги, локализируемые ресурсы.
Я не верю что тоже самое ты опишешь в две строчки. Именно с той же семантикой - с ограничением на переходы (кто имеет право, в каком состоянии должен быть объект), со всякими побочными эффектами и прочим.
Можешь хотя-бы показать как у тебя будет в XML-е выглядеть аналог (entity, context) => context.User.IsManager() ?
> высокоуровневый интерпретатор XML чтобы он нам генирировал наш XML из декларативного описания другим XML
XSLT же. Приловчившись, можно даже превращать один xslt-шаблон в другой при помощи третьего или самого себя. И только потом натравливать на xml )))
Но в целом, язык тут не важен. Конфигурирование всего - это ловушка. Один раз в неё попал, и всё, обратной дороги нет. Компиляция возможна только на лету. Отладка превращается в ад. Тестирование занимает гораздо больше времени. Сопровождение тоже. Ну и в дополнение обычно идет исключительно уродский UI. Короче, highway to hell. Уж сколько я таких наработок видел.
![[identity profile]](https://www.dreamwidth.org/img/silk/identity/openid.png){kind=small}
![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png)
timeasmymeasure
no subject
Date: 2014-11-12 08:52 am (UTC)Короче половина проекта на XML - это вроде больше про яву.
И лиспы как DSL для дотнета - в топку. Они не типизированы, и это в реалиях энтерпрайза - жопа. Такая же точно как XML - только букв меньше, код загадочнее, и поддержки IDE нет. В дотнете есть средства делать eDSL и метапрограммировать не убирая типизацию - вот ими и надо пользоваться.
no subject
Date: 2014-11-12 08:01 pm (UTC)Какие это такие "типизированные" мегасредства для eDSL и метапрограммировать есть в дотнете, и почему я, разработчик с минимум 7-летним опытом в дотнете, чуть ли не наизусть знающий мельчайшие его детали с версии 2, о них не знаю?
no subject
Date: 2014-11-12 08:14 pm (UTC)Типа вот из кода:
Entity<Program>() .PropagateChangesTo<EventInstance>( getId: (db, p) => db.EventInstances.Where(e => e.ProgramId == p.Id).Select(e => (int?)e.Id).FirstOrDefault(), condition: p => p.IsSingleEvent ) .HideField(p => p.IsSingleEvent) .HideField(p => p.Responsible) .Field(t => t.Comments, c => c.DoNotLogValues()) .AffectUnit(p => p.OrgUnitId, RelatedEntityRole.EventSupervisor) .AffectUser(p => p.Created.By, RelatedEntityRole.EventOrganizer) .AffectUser(p => p.ResponsibleId, RelatedEntityRole.EventOrganizer);Или вот Sprache:
Parser<string> identifier = from leading in Parse.WhiteSpace.Many() from first in Parse.Letter.Once() from rest in Parse.LetterOrDigit.Many() from trailing in Parse.WhiteSpace.Many() select new string(first.Concat(rest).ToArray());Супротив аналогичной XML-ки или лиспа - оно тайпчекается и держит рефакторинг.
Я бы не сказал что у какого-нибудь хаскеля инструментов для того же самого сильно больше. Лаконичнее и прямее - это да, но качественно там примерно тоже самое.
no subject
Date: 2014-11-12 08:40 pm (UTC)>Objects/array literals
Средство метапрограммирование? Шта?
>fluent interfaces
Туда же
>LINQ
LINQ, и его Expression trees - крайне ограниченная вещь. Это API работы с коллекциями и реляционными запросами. Максимум что из нее можно было выжать это Rx. Но сам по себе LINQ и его реализации это не метапрограммирование вообще никаких боком, это обычное функцональное API. Монада, если угодно.
>Expression trees,
Expression trees - самое интересное и хоть сколько-то относящееся к метапрограммированию из перечисленного. Фактически это урезанное AST C#. Типизация тут вообще никоим боком, на самом деле, потому что самая важная и крутая фича этого API это динамическая генерация и обработка кода на C#. Но по сравнению с возможностями современных реализаций лиспа, Expression Trees это просто детский сад. А еще - ты ими в продакшне пользовался хоть раз то? Я вот регулярно. И могу сказать - по сравнению с лиспами - они сложны и использовании, ограничены, и намноого менее юзабельны, чем встроенные инструменты самого простейшего даже лиспа, типа емаксового.
Далее
>аттрибуты, рефлекшн, генерация MSIL налету, интроспекция
Это все как раз мной в том числе активно используется(чем кстати интроспекция от рефлекшн отличается ггг?), но по сравнению с инструментами лиспа того же, это все крайне убого, громоздко и отвратительно, это во-первых, а во-вторых, опять же - ни в коем случае не типизировано. Используя эти инструменты, программист на C# или любом другом языке .NET фактически переизобретает лисп-систему через жопу, а даже скорее не лисп-систему, а недо-питон какой-нибудь.
>и изменение сборок через post sharp
PostSharp вот это уже ближе, но это настолько через жопу достигается(и кстати платно), что Типизированным Достоинством Дотнета я бы это не назвал даже в бреду.
>А еще Roslyn выходит
Roslyn еще не вышел, но мне тоже интересно, что еще MS утащит из лиспа в очередной раз.
>и есть F# давно
F# к метапрограммирования никоим боком.
no subject
Date: 2014-11-12 08:45 pm (UTC)no subject
Date: 2014-11-12 08:53 pm (UTC)Максимально декларативно описывать модель данных, генерировать ее из этого описания, вдобавок к этому декларативно описывать модель джойнов данных, и метаданные свойств(полей классов), для гридов и вообще любых UI-контролов, и опять же, генерировать гриды и контролы из этого. Плюс к этому, декларативным и внятным DSL-ем описать модель воркфлоу бизнес-логики и разнообразные валидаторы и функции перехода состояний объектов и комбинаций состояний объектов.
Отчасти это у меня в текущем проекте делается. Естественно, через рефлекшн и подобное, с описаниями в XML. Но выглядит это, хм ... Ну хотя, намного лучше и(особенно) компактнее и яснее, чем тупым хардкодом на C#, с типизацией и прочим.
no subject
Date: 2014-11-12 09:30 pm (UTC)Классы модели данных можно генерировать из одной сборки в другую. Я вот генерирую typescript, например. Но не вижу препятствий зафигачить eDSL-код для конфигурации модели данных в отдельной сборке, и генерить из этой сборки C# классы для всего остального.
Метаданные навешиваются аттрибутами и fluent-интерфейсами. В отличии от XML имеется возможность втыкать в метаданные логику, например .Condition(s => s == Sex.Male).
Стейт-машины, бизнес-процессы, валидация, и прочее - тоже вполне себе нормально делается.
Да, eDSL на C#, да и вообще любые eDSL проиграют по прямоте правильно сделанным DSL отдельным.
Но лисп - это тоже ведь нифига не правильно сделанный DSL. Это general-purpose-язык, со своим мешком проблем, который ты хочешь как-то хостить в дотнете, и на котором ты планируешь делать eDSL.
Если писать вообще всё на какой-нибудь там кложури - такое можно. Но нужно понимать что никакой серебрянной пули от этого не случится.
no subject
Date: 2014-11-12 09:44 pm (UTC)Ээээ. В XML ты вообще-то можешь втыкать вообще всё, что придумаешь. XML это просто язык разметки.
>Стейт-машины, бизнес-процессы, валидация, и прочее - тоже вполне себе нормально делается.
Нет. У нас была недоделанная стейт-машина на аттрибутах. Я выкинул, за 2 дня написал с XML.
Аттрибуты остались для валидации переходов стейтов. Но это тоже надо выкинуть в XML, по идее. Потому что это банально меньше кода, потому что проще, потому что код яснее выглядит, итд. На C# DSL тупо не сделать нормально. XML позволяет хоть какое-то подобие.
>Но лисп - это тоже ведь нифига не правильно сделанный DSL. Это general-purpose-язык, со своим мешком проблем, который ты хочешь как-то хостить в дотнете, и на котором ты планируешь делать eDSL.
Как старый лиспер, авторитетно заявляю: Лисп это не то что не DSL, лисп это вообще не язык программирования. Это метаязыковая среда.
Про другое потом отвечу, сейчас лень.
no subject
Date: 2014-11-12 10:03 pm (UTC)Не надо стейт-машину делать на аттрибутах. Надо делать что-нибудь, например, такое:
no subject
Date: 2014-11-12 10:13 pm (UTC)Ну какой есть. Привыкли. Хотя я бы все на S-выражениях делал.
>
Transition(
from: State.Draft,
to: State.Published,
verb: "Publish"
)
.Precondition((entity, context) => context.User.IsManager(), description: "You must be a manager to publish entities")
.Precondition((entity, context) => entity.IsValid(), description: "All fields should be specified correctly to publish entity")
.SideEffect(entity => new AddToNewsFeed(entity.ID);
.PostTransitionTask(entity => new SendPublishNotificationTask(entity.ID));
Кошмар. Вот у меня это описывается в 2 строки в XML абсолютно декларативно, без всякого там "entity, context => ..." и прочего, плюс 1 аттрибут в 15 символов считая квадратные скобки, плюс две стринги, локализируемые ресурсы.
no subject
Date: 2014-11-12 10:15 pm (UTC)Можешь хотя-бы показать как у тебя будет в XML-е выглядеть аналог (entity, context) => context.User.IsManager() ?
no subject
Date: 2014-11-12 10:34 pm (UTC)no subject
Date: 2014-11-12 10:35 pm (UTC)no subject
Date: 2014-11-12 09:26 am (UTC)XSLT же. Приловчившись, можно даже превращать один xslt-шаблон в другой при помощи третьего или самого себя. И только потом натравливать на xml )))
Но в целом, язык тут не важен. Конфигурирование всего - это ловушка. Один раз в неё попал, и всё, обратной дороги нет. Компиляция возможна только на лету. Отладка превращается в ад. Тестирование занимает гораздо больше времени. Сопровождение тоже. Ну и в дополнение обычно идет исключительно уродский UI. Короче, highway to hell. Уж сколько я таких наработок видел.
no subject
Date: 2014-11-12 08:21 pm (UTC)no subject
Date: 2014-11-21 10:24 am (UTC)Все что можно вынесено в XML. Сишный код по сути только двигло.