Кто-то юзал уже в продакшене?

hVostt,

кто-нить вообще юзал?

скрипты на C#-е, без оверхеда в тексте динамически компилируемого кода (классика C# REPL)

ась?

Cat2hVosttскрипты на C#
Это PowerShell

ещё раз повторяю: скрипты на C#

никакого PowerShell, такие скрипты нужны для того, чтобы часть товой расчётной логики вынести на уровень данных. конечно, можно было бы примонстрячить, например, какой-нибудь Lua.NET или что-то такое, но надо исключить из уравнения «учить ещё один язык» (даже самый пипец какой сверх-наипростейший в этой вселенной -- наплевать!), и включить в уравнение «возможности C# LINQ».

т.е. никакого PowerShell или <мой-любимый-скриптовый-язык>.

поэтому и спрашиваю, кто-нить щупал Roslyn? (уже включённый в состав фреймворка, но до сих пор отсутствующий в полной мере в нугетах). использовал в продакшене? вопрос концептуальный.

ViPRos,

т.е. это пока на уровне задумки?

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

ViPRos,

твои задачи несколько отличаются от моих :)
у тебя же кодогенерация и анализ кода, которую можно уже юзать. это не скриптинг.

моя задача — это написание алгоритмов и сохранение их в данных. алгоритмы это чистокровное мясо, т.е. никаких тебе «особенностей реализации», пишешь тупо в лоб — ни валидации, ни отлов исключений, ни журналирование — ничего этого ты не делаешь, да и вообще знать про это не знаешь, пишешь себе алгоритм. при чём даже не весь алгоритм, а разбиваешь на куски, которые можно тут же протестировать, и всё это через пользовательский интерфейс, без всяких студий. на брифингах выяснилось, что нет ни одной дельной причины приделывать сюда какой-то скриптовый язык, алгоритмы 100% императивные, так что функциональщина сразу топает лесом в огород. алгоритмы будут писать специально обученные люди, и разговаривать вся команда должна на одном языке, вавилонские башни пусть другие строят :)

ViPRoshVostt,

а как же контекст для этих алгоритмов?
откуда берется?
какая область знаний?

контекст предоставляется «сверху», в контексте вся модель данных и туда же алгоритмы пишут результат.
откуда берётся, не имеет значения. может быть из базы данных. а может ещё откуда-то, для алгоритмов это без разницы, они делают своё чёрное дело.
область знаний — расчёты. грубо говоря, у определённых людей есть методички с формулами, наборы регламентов, приказов и прочего барахла, на основе чего они пишут эти алгоритмы. для написания этих алгоритмов надо знать базовый синтаксис C# и базовые принципы LINQ, этого достаточно. осилит даже обезьяна. ну и программисты на подхвате — подскажут. программисты же заняты самим инструментом в ПО, которое будет делать всю чёрную работу — валидация, журналирование, визуализация, отлов ошибок, проверки, подсказки, подготовка контекста и прочее.

ViPRosприведи пример

ну вот кусок алгоритма:




грубо говоря, это какой-нибудь узел алгоритма.

ViPRoshVostt,

а контекст откуда берется?
М?

Ну М, например. Контекст передаётся каждому узлу, это инстанс класса. Разумеется, контекст отслеживает изменения своих данных, ну и заведомо не содержит некорректных данных (null вместо коллекций, например).

ViPRoshVostt,

то что передается ясно :)
а при Написании алгоритма уже есть доступ к М (ну к метаописанию М)?
если есть то зачем тебе скриптинг?
если М дайнамик конкретно нетовский, то опять ж
скриптинг - когда М еще нет, а есть просто протокольный (ну бумажный) интерфейс М

доступ к мета есть при написании. живой М передаётся при исполнении, конечно же.

скриптинг нужен, потому что алгоритмы хранятся как данные, редактируются пользователями (специально обученными), имеют свойства данных — могут создаваться через пользовательский интерфейс, редактироваться/изменяться, копироваться, архивироваться, связываться с расчётами и прочее. этим алгоритмам не место в коде приложения, им также не место в СУБД (там вообще не место никакой даже самой мало-мальской логике!).

ViPRosдык они обычный код, только внешний для приложения

нет, не обычный. это текст, хранимый как данный. текст, который исполняется как код. это -- текст.

ViPRosВИПРОС просто их загружает и выполняет по команде пользователя - а что они делают ей пофиг

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

ViPRosа сами методы в каких то ДЛЛках или в хранимках или просто СКЛ запрос

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

ViPRosбрать с длл такойто неймспейс такойто класс такой то метод такой то или схема и хранимка или запрос прямо в описании метода

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


ViPRosвсе эти методы уанвей - т.е. они просто возвращают норм ли выполнились или нет (вот этого я хочу с помощью рослин исправить)

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

ViPRosи дял этого никакого скриптинга не надо

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