Луп отвечает за страницу

Ну есть локальный сторейдж, да

Сценариев, когда надо внезапно что-то прокинуть на другую страницу, нет

удивительно)

Да норм же, eDSL - это не всегда прям другой синтаксис

dsl как средство решения прикладной задачи - еще ни разу не было хорошим решением, будь он встраиваемый или внешний. пользователи в гробу видели программирование, потому что для этого наняли программистов. а программисты в гробу видели dsl, потому что они владеют полным языком с куда большей гибкостью. dsl-и имели свои пять секунд славы как и экспертные системы, логическое программирование, case-системы и прочие экспонаты музея "Курьезы кибернетики"

eDSL - это embedded DSL, да?

dsl как средство решения прикладной задачи - еще ни разу не было хорошим решением, будь он встраиваемый или внешний. пользователи в гробу видели программирование, потому что для этого наняли программистов. а программисты в гробу видели dsl, потому что они владеют полным языком с куда большей гибкостью. dsl-и имели свои пять секунд славы как и экспертные системы, логическое программирование, case-системы и прочие экспонаты музея "Курьезы кибернетики"

пожалуй не соглашусь

Сценариев, когда надо внезапно что-то прокинуть на другую страницу, нет

библиотека не меняет синтаксис моего языка

eDSL тоже не обязан

библиотека не меняет синтаксис моего языка

а почему он тогда dsL?

Ну не знаю, я маленький DSL на строках тут запилил на работе. Удобно описывать типовой сценарий вместо 100500 строк кода.

Cначало строки, потом s-epxression, и не заметишь как сделаешь очередной lisp

а почему он тогда dsL?

какой нибудь ZIO заставляет тебя писать for { }

Ваще, SQL тоже DSL. ;P

Любое использование LINQ в шарпе и CE в F# - это использование eDSL

об этом и речь, просто запутались в терминологии. не путайте квантор существования с квантором всеобщности: любой eDSL - это библиотека (чаще всего), но не любая библиотека - это dsl.

это крайне специфические dsl

Так tagless final или фри монады - это один из возможных инструментов для написания eDSL

это да, но я говорю о том, что идея решать прикладную задачу (перекладывания жсонов) написанием edsl - так себе идея

потому что в 99% случаев спецификаций нет, требования растут по мере роста проекта, через полгода разработки 80% усилий - это попытки чинить dsl, придуманный без понимания домена вообще

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

можно. но почему-то с mtl\tf хрень получается чаще. точнее, в подавляющем большинстве случаев получается хрень

Ну я бы не сказал. MTL в хаскеле норм работает, если не нужно городить свои трансформеры. Коты в скале - тоже. Т.е. на котах в прод писал, в tf стиле, каких-то особых проблем с деливером value не заметил.

Я как-то пару лет наблюдал за командой в загончике напротив. Парни излучали энтузиазм, писали на дотнете на самых продвинутых технологиях, но за полтора года ни одного релиза

Я как-то пару лет наблюдал за командой в загончике напротив. Парни излучали энтузиазм, писали на дотнете на самых продвинутых технологиях, но за полтора года ни одного релиза

Как и везде, свои подводные камни есть, но и свои плюсы тоже.

завидовал небось

завидовал небось

20$ говорят, что твой код будет переписан приблизительно через месяц после твоего ухода из компании

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

Я писал дофига на том же стандартном энтерпрайзном шарпе и каких-то катастрофичных проблем в работе с эффектами в mtl стиле я так и не увидел. Вполне рабочий подход (с некоторыми но - если речь про скалу, но обходимыми). А про final tagless - я как-то котлинистам на нём eDSL помог проектировать, все остались предельно довольны результатом. Надо всё же разделять final tagless как подход к проектированию eDSL и mtl - как eDSL над эффектами.

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

Нет, eDSL - там, где они позволяют что-то выиграть.

для того, чтобы вообще можно было иметь dsl - хост язык должен иметь возможности для этого, что-то побольше, чем do или for {}.

То есть взять для контроля эффектов eDSL - это нормальный вариант, если хочется контроля эффектов.

eDSL можно делать и без смены синтаксиса языка

тогда это не dsl, не так ли? тогда это просто хостовый язык

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