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

PSV>А вот пример на Хаскель-коде, как непосредственного предка этого LINQ:

Хаскель, конечно, повлиял на LINQ сильно, но называть его непосредственным предком — явый перебор.

PSV>А вот пример генератора SQL на Кложуре:

Ну и? Ты сказать то чего хотел?

PSV>И таких DSL куча для разных языков. Вот только такой LINQ в SQL не впихнёшь.

При чем тут куча языков, если речь о LINQ? И зачем его впихивать?
На LINQ твой запрос будет выглядеть так:

var q = (from e in employees
        group e by e.dept into g
        let sum = g.Sum()
        order by sum descending
        select new {g.Key.dept, sum})
        .Take(5);

Единственная проблема, которую я здесь вижу — синтаксис query comprehension не поддерживает take/skip. Но с теоретической точки зрения это не интересно, потому что проблема исключительно в том, что недореализовали и ни в чем больше.

PSV> Но речь идёт абсолютно не об этом, не о каких-то конкретных SQL-серверах.

А LINQ это и не конкретные sql сервера, это именно DSL для работы с реляционными и иерархическим и моделями. Именно то, что ты хочешь обсудить.

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

AVK>Хаскель, конечно, повлиял на LINQ сильно, но называть его непосредственным предком — явый перебор.

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

PSV>>А вот пример генератора SQL на Кложуре:
AVK>Ну и? Ты сказать то чего хотел?

То, что кроме LINQ есть множество аналогичных DSL, для разных языков, и не только для генерации SQL (манипулирование данными внутри приложения, в коллекциях, например).

PSV>> Но речь идёт абсолютно не об этом, не о каких-то конкретных SQL-серверах.
AVK>А LINQ это и не конкретные sql сервера, это именно DSL для работы с реляционными и иерархическим и моделями. Именно то, что ты хочешь обсудить.

Я, собственно, ничего обсуждать не хочу. И в моём первом сообщении речь была совсем не о DSL в рамках клиентского приложения для работы с SQL. Я предложил Владу, как автору этой темы, и другим представителям лагеря Немерле сделать небольшой и простой учебный материал, в рамках форума, где бы на небольшой условной псевдо-задаче раскрыть свои теоретические взгляды по поводу DSL-строения, включая и определения ряда терминов, подкрепленными наглядными примерами, и заодно всем показать потенциал N2 для реализации DSL. В качестве постановочной задачи я предложил взять условную упрощённую реализацию SQL-сервера реляционной СУБД, т.к. эта сфера знакома всем. Ещё раз подчеркну, ни о каком DSL в рамках клиентского кода внутри своего приложения речи не было. А на примере этого кода:

PSV>

PSV>define MyWhere as AnyCol > 1000 and SomeCol is not null;

PSV>-- или с параметрами:

PSV>define Where2(AnyCol, Val1, Val2) as AnyCol between Val1 and Val2;

PSV>define MySelect (AnyTable) as
PSV>  select Col1, Col2, ... from AnyTable a
PSV>  where a.ID > 1000 and MyWhere and Where2(a.DateOper, '10.01.2012', '24.08.2012')
  
PSV>-- и использовать как-то так:

PSV>select * from MySelect(OperTable)  
PSV>

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

— что не всегда в DSL реализуется язык так, как хотелось бы программистам, т.к. через DSL часто решаются многие вопросы, технические и политические, не только прихоти профи-программистов. Т.е. именно такой SQL внутри сервера СУБД может, теоретически, не удовлетворять условиям поставленной задачи;

— что такой SQL является весьма спорным в рамках термина DSL: является ли такой вариант языка DSL-лем или это уже какой-то универсальный, хоть и ограниченный, язык, который уже сам позволяет создавать DSL? (Я бы сам хотел узнать, что об этом думают те, кто раскрывает тему DSL-строения)

Ни о LINQ и его аналогах, ни о конкретном SQL-сервере, включая и MSSQL, речи нет.

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

AVK>>Хаскель, конечно, повлиял на LINQ сильно, но называть его непосредственным предком — явый перебор.

PSV>Майкрософт прикармливает исследования в Хаскеле

О да, это все меняет

PSV>, в частности технология LINQ была обкатана в экспериментальном расширении этого языка

Для того Хаскель и придумали. Но обкатывали не на нем, а на C omega.

PSV>То, что кроме LINQ есть множество аналогичных DSL

И?

AVK>>А LINQ это и не конкретные sql сервера, это именно DSL для работы с реляционными и иерархическим и моделями. Именно то, что ты хочешь обсудить.

PSV>Я, собственно, ничего обсуждать не хочу.



PSV> И в моём первом сообщении речь была совсем не о DSL в рамках клиентского приложения для работы с SQL.

А LINQ никак не обязывает использовать SQL. Даже в самом фреймворке есть провайдеры для IEnumerable, XML, DataSet.

PSV>и заодно всем показать потенциал N2 для реализации DSL.

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

Здравствуйте, VladD2, Вы писали:
VD>Что-то вроде.
Теперь понял.
ИМХО, проблемой будет "скрутить" в одно приложение код, нагенерированный каждым из DSL(или даже точнее, сделать так чтобы все DSL корректно собрались в одно приложение и не конфликтовали друг с другом), это будет основным источником "жуков". Особенно если предполагается доверить разработку новых языков пользователям и кросплатформеность. А увеличение уровней на которых будет происходить такая "скрутка", умножит эти проблемы на число уровней(маленькая ошибка на верхних уровнях, приводит большим проблемам на нижних).
Но с другой стороны, если "фронтэнд"(то с чем работает пользователь) каждого из DSL будет хорошо спроектирован, то есть не будет давать пользователю делать того чего нельзя, а "бэкэнд"(генерируемый код) будет хорошо протестирован на совместимость с другими DSL, это будет работать.

VD>>>...модель приложения.
AC>>Под моделью я подразумеваю "модель среды"(не IDE)
VD>Приложение он ведь решает некоторую проблему пользователя...
Вы ведь пилите ЯП(инструмент для создания приложений), а не приложение.
VD>Вот тут уже не совсем так. На самом деле мы используем ЯОН и ДСЛ-и для описания и работы с моделями предметной области. Мы моделируем эту область разными способами. ДСЛ-и это возможность работать с этими моделями в терминах этой предметной области. Только и всего. Если не применять ДСЛ-и то мы будем вынуждены возиться с классами и процедурами которые в свою очередь реализуют модель.
VD>Тут можно провести следующую аналогию. Представь себе, что ты пишешь простую программу которая читаешь данные из файла, производит не сложные их изменения и записывает их в другой файл. Не сложная задача, правда?
Я изложу подробней как я это понимаю, поправь если я где не прав.
Мы можем написать программу, решающую конкретную проблему в конкретной предметной области, в лоб. Просто взять и написать, на каком нибудь ЯОН. Но если таких программ предполагается много, то прежде стоит подготовить инструмент, который облегчит написание программ для этой конкретной предметной области.
Например нам нужен инструмент для написания программ работающих с текст файлами, конкретно и их заглавиями. Это может быть и библиотека функций или макросов, класс etc. но в данном случае мы выберем предметный язык. У этого инструмента есть собственная модель*, являющаяся "отражением" предметной области.
Наш язык для работы с файлами можно представить так:

В зелёном прямоугольнике форматы языковых конструкций, в коричневом связанные с ними элементы модели языка(отражения элементов предметной области). Реализовано это может быть разными способами, например если бы мы выбрали библиотеку функций то в зелёном были бы форматы их вызовов, а в коричневом собственно библиотека с функциями и структурами. Если DSL реализован при помощи макросов, то в коричневом они. Если для DSL используется транслятор, то до трансляции элементы в коричневом треугольнике будет существовать только в документации к DSL(или в голове его разработчика), однако транслятор будет "знать" как построить каждый из них.
Когда инструмент готов, можно приступать к написанию собственно программы. Для чего мы складываем элементы модели(посредством ЯП), предоставляемые инструментом, таким образом чтобы конструкция из них решала конкретную проблему(как ты не знаю, я делаю именно так). Эта конструкция и будет моделью приложения(отражением конкретной проблемы,(!)а не всей предметной области).
Например у нас есть конкретная проблема, нужно взять заглавие одного текст файла изменить его и сохранить в отдельный файл, для чего мы пишем приложение:

Модель этого приложения можно представить так:

"В компьютере" оно конечно не будет иметь точно такой вид, но структурой будет похоже.
Т.е. "модель приложения" есть набор связанных между собой элементов модели ЯП, использованного для его написания, построенный по исходному тексту этого приложения.
*"модель" — следует понимать в зависимости от контекста как "программная модель реального объекта"(существует в компьютере) или как "мысленная модель реального объекта"(в воображении).

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

PSV>>и заодно всем показать потенциал N2 для реализации DSL.

AVK>В Н просто LINQ реализован. Так что выглядеть это будет бессмысленным извращением.

Я Немерле не использую и, фактически, его не знаю, да и не знаток я и платформы Net, но очень рад, что в Немерле, как я понимаю, появилась прозрачная поддержка LINQ, как в С#, вместо макросов linq <# ... #>, которые были в N1. И очень жаль, что теперь наличие LINQ делает процесс создания DSL в Немерле бессмысленным извращением, даже если (возможно) речь идёт об учебном примере создания псевдо-сервера СУБД.

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

— наличие LINQ в языке избавляет от всех потребностей в любом другом DSL для любой задачи. Поэтому создание своего DSL на Немерле теперь является бессмысленным извращением. Нет никаких потребностей в другом языке, кроме LINQ, включая и сервер СУБД.
Как-то всё это противоречит тому, о чём здесь говорят Влад и Вольфхаунд, как минимум. Странно, пока лучше опустить этот момент, я не специалист по Немерле, сам хочу увидеть какую-то конкретику.

— В современном сервере СУБД не должно быть неудобного и ограниченного языка SQL: там однозначно должен быть язык для запросов похожий на LINQ.
В жизни ещё не доводилось разрабатывать сервера СУБД, вполне возможно, что так будет лучше, хоть и не стандартно, я не спец.

— Использование LINQ в Немерле (возможно, и во всём Net) теперь является обязательным явлением, и даже страшно предположить, теперь является чуть ли не единственным способом для манипулирования данными, не исключаю, что многие методы/алгоритмы, например, в тех же коллекциях, объявлены как "deprecated". Поэтому LINQ это единственный очевидный способ реализации обработки данных в рамках сервера СУБД.
Здесь я тоже не спец по платформе Net.

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

— В Немерле жёстко принято все операции с данными делать через LINQ: писать запросы внутри программы, компилировать/собирать сборку/проект и запускать на выполнение. Это делает инструмент Heмерле бессмысленным извращением для создания сервера СУБД.
В этом логика есть.

Одним словом, не понимаю, в чём заключается всемогущая обязательность LINQ и каким образом он делает процесс создания DSL бессмысленным извращением, даже в рамках учебного материала для псевдо-задачи по созданию условного сервера СУБД. По мне, так наоборот, раз уж эта технология LINQ такая прекрасная для всех случаев, то этот LINQ как раз может упростить создание учебного примера. Можно задать простое условие: нужно реализовать приложение, которое будет слушать сеть или по простому читать из консоли/файла строку с текстовым запросом, процесс как-то переварит этот запрос и обработает данные в ОЗУ (пусть вся информация будет только в коллекциях), и программа выдаст нужный ответ наружу. Фактически, достаточно только показать:

— пусть этот LINQ будет как язык запросов внутри этого LINQ-сервера (вместо SQL-сервера). Мы прочитали текстовую строку с запросом, какими-то уже имеющимися средствами скомпилировали этот запрос как исходник Немерле, как-то динамически загрузили новый байт-код и его успешно запустили для выполнения (при этом новый код чудесным образом через LINQ как-то добрался до данных в памяти основного процесса, в его коллекциях). Всё это хотелось бы увидеть, как оно примерно выглядит. Можно также показать схематично, очень кратко, как осуществлена поддержка этого DSL, т.е. LINQ (не думаю, что там настолько всё криво, что выглядит как бессмысленное извращение).

— или пусть мы всё-таки делаем SQL-сервер. Тогда запрос будет в виде SQL. Нужно как-то его через универсальный парсер в Немерле трансформировать в вид LINQ и дальше как выше по тексту. Здесь можно кратко показать как задаются правила разбора, как используется парсер, как генерируется текстовый код LINQ. Может здесь есть возможность схематично показать как реализуются бэкенды для Немерле, через которые можно текст SQL сразу перегнать в байт-код Net-а, где будет использован LINQ.


Такой реальный пример будет всем полезный, чем ругня в многотысячных топиках форума. В нём же и в двух словах не мешало бы раскрыть и все нужные термины по поводу DSL. Более того, нужен пример для тех, у кого платформа Net не является целевой. Я, например, как некий потенциальный разработчик сервера СУБД, должен буду задуматься над тем, что если я возьму Немерле, как замечательный инструмент для работы с DSL, с какими проблемами я столкнусь, чтобы создать объектные файлы, которые я смогу скомпоновать с остальным кодом проекта на С++ (без никакой зависимости от Net, особенно при использовании чудесного LINQ). Мне реально нужно понять, из-за чего профессионалы, работающие для таких проектов как gcc, LLVM с Сlang и пр., переключатся на создание бэкендов для Немерле, или по каким соображениям корпорации смогут их нагнуть для этого, или какие будут мотивы у интузиастов-профессионалов для адаптации Немерле под JVM, и т.д. Не хотелось бы всегда заниматься своей низкоуровневой генерацией кода на С++, Java, Erlang и т.п.


P.S. Вести неконструктивные споры не вижу никакого смысла, здесь уже более чем достаточно темы форума по поводу ненужности многих языков.

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

T>>>А вот такой вопрос: не мог бы ты предложить хороший вариант DSL'я для работы с файлами?

VD>>Это слишком расплывчатая формулировка. С файлами можно по разному работать. Скажем SQL — это тоже, в какой-то мере, язык по работе с файлами .

T>Я имею ввиду DSL для замены файлового менеджера: скопировать, удалить, переместить и пр.

Дык в ОС (Windows/Linux/etc) есть такой DSL .

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

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

T>>>>А вот такой вопрос: не мог бы ты предложить хороший вариант DSL'я для работы с файлами?

VD>>>Это слишком расплывчатая формулировка. С файлами можно по разному работать. Скажем SQL — это тоже, в какой-то мере, язык по работе с файлами .

T>>Я имею ввиду DSL для замены файлового менеджера: скопировать, удалить, переместить и пр.

GIV>Дык в ОС (Windows/Linux/etc) есть такой DSL .

По поводу Windows (cmd) соглашусь, а по поводу PowerShell, bash и пр., нет, это полноценные языки общего назначения (особенно PowerShell). Но назвать cmd хорошим DSL-ем значит сделать антирекламу всей идеи.

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

Z>Всем дотнетчикам приходится работать с "кривым API от Майкрософта", с этим ничего не поделать (остальным с "кривым API от SomeCompany"). Яж тебе предлагал показать что-то получше.

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

I>>Вот тебе задачка — твой ДСЛ очень классно работает, но вот засада, на одном из серверов в продакше отваливается и урлы не мапятся.
I>>Без ДСЛ нужно воспроизвести ситуацию и тупо продебажить. Что ты будешь делать с ДСЛ ?

Z>Воспроизведу ситуацию и продебажу

То есть вижла должна поддерживать все инструменты для ДСЛ, правильно ? Откуда это будет у кастомных ДСЛ ? Откуда прикладной программист будет знать, какие системные вызовы стоят за твоим дсл, если дсл будет возложен на архитектора ?
Если речь про макросы, стало быть прикладной должен будет понимать эти макры на уровне архитектора ?

I>>Я понимаю, у вас немерлистов хроническая болезнь — при объяснении спрыгивать на свои частные задачки, но это ваши проблемы.

Z>Я так понимаю у тебя, без перехода на личности, дискуссию вести не получается. Я пытаюсь показать, что есть задачи, где DSL удобнее библиотеки с API ...

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

Z>... А ты — что есть задачи, для которых польза DSL не так очевидна. Можешь не стараться, никто не ставит под сомнение этот тезис.

Wolfhound как раз и ставит под сомнение. Роутинг, пермишны — это капля в море. Время на это расходуется около нуля даже без ДСЛ. А вот бизнеслогика это совсем другой расклад и здесь как я понял, у вас ничего нет, а это 99% расходов на разработку. Вот эти затраты и нужно сокращать.

Z>Конкретно по задаче от AVK. Лично я бы не стал сразу придумывать какой-то очень хитрый язык.

Вот-вот. Его задача ничем не особенная, и он даже ответил на все вопросы, а ДСЛ пока никто не предложил.

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

Z>>Всем дотнетчикам приходится работать с "кривым API от Майкрософта", с этим ничего не поделать (остальным с "кривым API от SomeCompany"). Яж тебе предлагал показать что-то получше.

I>В таком случае ты просто предложил другую платформу — руби. Вот и все преимущество.

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

I>То есть вижла должна поддерживать все инструменты для ДСЛ, правильно ? Откуда это будет у кастомных ДСЛ ? Откуда прикладной программист будет знать, какие системные вызовы стоят за твоим дсл, если дсл будет возложен на архитектора ?

А какие системные вызовы стоят за File.Exists и нужна ли специальная поддержка студии для него? В принципе можно наколбасить макросами кода так, что отлаживать его ты задолбаешься, но это проблема применима ко всем технологиям программирования. Безудержное применение ООП или ФП не по месту тебе даст проблем не меньше. Попробуй подебажить linq запрос, например. Если вдруг он начал падать на продакшен сервере

I>Если речь про макросы, стало быть прикладной должен будет понимать эти макры на уровне архитектора ?

Прикладной понимает API на уровне архитектора? Та же ситуация и с макросами.

I>Не надо слов, покажи решение для общего случая, а не для частных. Тебя же никто не просит накидать парсер-компилер, а только показать сам язык.

Да не бывает частных решений для общего случая. Покажи чем там может помочь FP? Или это тоже негодная парадигма?

I>Wolfhound как раз и ставит под сомнение. Роутинг, пермишны — это капля в море. Время на это расходуется около нуля даже без ДСЛ. А вот бизнеслогика это совсем другой расклад и здесь как я понял, у вас ничего нет, а это 99% расходов на разработку. Вот эти затраты и нужно сокращать.

Ну так спорь с Wolfhound, я тут при чем? Впрочем, подозреваю, что ты пытаешься довести его точку зрения до абсурда и этим опровергнуть.

Z>>Конкретно по задаче от AVK. Лично я бы не стал сразу придумывать какой-то очень хитрый язык.

I>Вот-вот. Его задача ничем не особенная, и он даже ответил на все вопросы, а ДСЛ пока никто не предложил.

Несмотря на ответы, мне толком непонятно что там происходит. Имхо, это даже не логика, а кусок низкоуровневого API для использования в BL слое, одна мелкая операция. Иначе мне сложно представить как там выглядят бизнес-алгоритмы, их однозначно нельзя писать в таком стиле.

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

I>>В таком случае ты просто предложил другую платформу — руби. Вот и все преимущество.

Z>Я не понимаю, что ты хочешь этим сказать. Я показал, как нормально можно описать REST роутинг в приложении. Люди пытаются сделать что-то подобное с помощью fluent+expressions, но выходит все равно коряво. Без этого получаются ужаснейшие рукописные макароны.

Возьми трекер и отфильтруй тикеты на эту маршрутизацию. Сколько суммарно времени ? Сколько разработчиков на проекте, тестеров, ба и тд ? Сколько выходит в процентах, если поделить сумму времени по тикетам на сумму времене всех работников на проекте ?

Z>А какие системные вызовы стоят за File.Exists и нужна ли специальная поддержка студии для него? В принципе можно наколбасить макросами кода так, что отлаживать его ты задолбаешься, но это проблема применима ко всем технологиям программирования. Безудержное применение ООП или ФП не по месту тебе даст проблем не меньше. Попробуй подебажить linq запрос, например. Если вдруг он начал падать на продакшен сервере

Роутинг на иис не сводится к File.Exist. Я привел абсолютно реальный пример, если что.

I>>Если речь про макросы, стало быть прикладной должен будет понимать эти макры на уровне архитектора ?

Z>Прикладной понимает API на уровне архитектора? Та же ситуация и с макросами.

АПИ винды или ИИС — вполне возможно. Архитектор давно забыл что это такое.

Z>Да не бывает частных решений для общего случая. Покажи чем там может помочь FP? Или это тоже негодная парадигма?

Вот-вот.


I>>Вот-вот. Его задача ничем не особенная, и он даже ответил на все вопросы, а ДСЛ пока никто не предложил.

Z>Несмотря на ответы, мне толком непонятно что там происходит. Имхо, это даже не логика, а кусок низкоуровневого API для использования в BL слое, одна мелкая операция. Иначе мне сложно представить как там выглядят бизнес-алгоритмы, их однозначно нельзя писать в таком стиле.

Это типичная операция. Он даже указал откуда это все взялось.

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

T>>А вот такой вопрос: не мог бы ты предложить хороший вариант DSL'я для работы с файлами?
_O_>Любой shell на Linux/Unix — это DSL для работы с файлами, причем проверенный временем.

Осталось понять, почему при наличии хорошего и проверенного временем DSL при написании приложений всё ещё используются fopen/fstream/File/open/... ?

http://habrahabr.ru/post/143306/ интересная презентация. Т.е. сам предмет не новый, но я что-то не видел ещё подобную популяризацию, да ещё и на русском.

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

PSV>>А вот пример на Хаскель-коде, как непосредственного предка этого LINQ:

AVK>Хаскель, конечно, повлиял на LINQ сильно, но называть его непосредственным предком — явый перебор.

На Хаскеле был создан прототип (очень отдаленный) линка. Об этом Меер где-то вещал, если не ошибаюсь.

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

Z>Имхо, это даже не логика, а кусок низкоуровневого API для использования в BL слое

Нет, это как раз таки типичная бизнес-логика.

Z>Иначе мне сложно представить как там выглядят бизнес-алгоритмы, их однозначно нельзя писать в таком стиле.

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

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

Z>>Имхо, это даже не логика, а кусок низкоуровневого API для использования в BL слое

AVK>Нет, это как раз таки типичная бизнес-логика.

Отличное доказательство, что для этого требуется ДСЛ.

Z>>Иначе мне сложно представить как там выглядят бизнес-алгоритмы, их однозначно нельзя писать в таком стиле.

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

Так ты задачу то опиши. Тогда и покажем.

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

AVK>>Нет, это как раз таки типичная бизнес-логика.

VD>Отличное доказательство, что для этого требуется ДСЛ.

Ну так где пример такого DSL?

VD>Так ты задачу то опиши. Тогда и покажем.

Я правильно понимаю, что вы по прежнему предлагаете писать DSL под каждый конкретный продукт? Т.е. рассчет зарплаты — один DSL, кадровый учет — другой, бухгалтерия — третий?
Ну да ладно — вот тебе весьма тривиальная задачка — рассчет ЗП. Некоторые прям в экселе делают. Нагуглилось сходу — http://www.reghelp.ru/raschet_zarplat.shtml .
Достаточно подробно? Только учти — писать рассчет зарплаты много много раз не нужно, достаточно одного. Т.е. DSL, завязанный конкретно на этот самый рассчет — не нужен. Нужен DSL, позволяющий решать подобные задачи.

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

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

AVK>>>Нет, это как раз таки типичная бизнес-логика.

VD>>Отличное доказательство, что для этого требуется ДСЛ.

AVK>Ну так где пример такого DSL?

Где внятное описание задачи? Я как бы уже не один десяток ДСЛ-ей окучил. И авторитетно тебе заявляю, что создать ДСЛ по твоей лапше нельзя в принципе. Для ДСЛ-я вжно понимать, что за процесс мы описываем, а не видеть какие-то там действия не ясно с чем, да еще и в виде макаронного АПИ.

VD>>Так ты задачу то опиши. Тогда и покажем.

AVK>Я правильно понимаю, что вы по прежнему предлагаете писать DSL под каждый конкретный продукт?

Это зависит. Иногда даже для отдельной подзадачи. А иногда универсальное решение которое можно использовать во многих проектах. Если речь идет о расчете амортизации, то скорее всего ДСЛ будет под этот рассчет, но в рамках системы.

AVK>Т.е. рассчет зарплаты — один DSL, кадровый учет — другой, бухгалтерия — третий?

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

Помнишь, кстати, такой продукт — Турбо Бухгалтер? Не знаю как сейчас, но в 90-ых это был ДСЛ для маленьких бухгалтерий. Для расчета баланса или оборотки нужно было компиляцию запустить. Прямо как в Рубо Паскале. :)

Так вот мой отец на базе этого ДСЛ-я вел сразу 7 фирм зарабатывая тем самым не плохие деньги на то время.

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

AVK>Ну да ладно — вот тебе весьма тривиальная задачка — рассчет ЗП. Некоторые прям в экселе делают.

А у меня для этого свой ДСЛ-чик на ХМЛ-е создан (он правда более универсальный, я им еще накладные и счета генерирую). Правда количество сотрудников у нас сам знаешь какое :). И сложность рассчета тоже. Но тем не менее я спокойно обхожусь без бухгалтера и делаю эту самую зарплату за 10 секунд. Подъезжай, как нить, покажу.

AVK>Нагуглилось сходу — http://www.reghelp.ru/raschet_zarplat.shtml .
AVK>Достаточно подробно? Только учти — писать рассчет зарплаты много много раз не нужно, достаточно одного.

Спасибо за разяснения, кэп! :))

AVK>Т.е. DSL, завязанный конкретно на этот самый рассчет — не нужен. Нужен DSL, позволяющий решать подобные задачи.

Ну, ты тут правильно заметил, что подобный ДСЛ чем-то на Ёксель должен быть похож. Он должен содержать рассчеты (они там взаимосвязанные) и указания откуда надо брать данные. Ну, а на выходе может быть, например, генерация файла экспорта 1Эс, который во многих банк-клиентах используется.

Я вот, у себя, данные прямо в ХМЛ храню (объемы нулевые — БД не нужна).

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

<?xml version="1.0" encoding="utf-8"?>
<Specification>
  <Template>
    <Path>ПлатежноеПоручениеДляБанкКлиентаСБ.txt</Path>
    <Info>
      <Copies>2</Copies>
    </Info>
  </Template>
  <Includes>
    <Include>Реквизиты-Название-фирмы-специально-удалено-в-файле-лежат-ее-реквизиты.xml</Include>
  </Includes>
  <Properties>
    <ЗаМесяц>$Месяц</ЗаМесяц>
    <День>27</День>
    <Месяц>02</Месяц>
    <Год>2012</Год>
    <ЗарплатаСПодоходным>ставка-зарплаты-так-же-скрыта</ЗарплатаСПодоходным>
    
    <Дата>$День.$Месяц.$Год</Дата>
    <ЛицевойСчет>40100770016</ЛицевойСчет>
    <ПодоходныйНалог>$(ЗарплатаСПодоходным * 13 / 100)</ПодоходныйНалог>
    <ЗарплатаНаРуки>$(ЗарплатаСПодоходным - ПодоходныйНалог)</ЗарплатаНаРуки>
    <Платеж>
      <Номер>$(НомерЭлемента())</Номер>
      <Статус>01</Статус>
      <Показатель>
        <Основания>ТП</Основания>
        <НалоговогоПериода>МС.$ЗаМесяц.$Год</НалоговогоПериода>
        <НомераДокумента>0</НомераДокумента>
        <ДатыДокумента>$Дата</ДатыДокумента>
        <Типа>НС</Типа>
      </Показатель>
      <СуммаПрописью>$(РублиПрописью(Платеж_Сумма)) 00 копеек</СуммаПрописью>
      <СуммаНДС>Без НДС</СуммаНДС>
      <СуммаБезКопеек>$Платеж_Сумма-00</СуммаБезКопеек>
      <Город>Москва</Город>
      <Очередность>3</Очередность>
      <ОКАТО>45280580000</ОКАТО>
    </Платеж>
   
  </Properties>
  <Items>
    <Платеж id="ПенсионныйСтраховой">
      <Сумма>$(ЗарплатаСПодоходным * 16 / 100)</Сумма>
      <Статус>01</Статус>
      <Имя>УФК по г. Москва (для ГУ - Отделения ПФР по г. Москве и Московской области)</Имя>
      <Основание>
        "Уплата ПФР - страховая часть пенсии." Рег. № 087-301-000107.        За $ЗаМесяц месяц $Год года.
      </Основание>
      <ИНН>7703363868</ИНН>
      <КПП>770301001</КПП>
      <РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
      <КорСчет></КорСчет>
      <ВБанке>Отделение 1 Московского ГТУ Банка России г.Москве 705</ВБанке>
      <БИК>044583001</БИК>

      <КБК>39210202010061000160</КБК>
      <Показатель>
        <Типа>ВЗ</Типа>
      </Показатель>
    </Платеж>

    <Платеж id="ПенсионныйНакопительная">
      <Сумма>$(ЗарплатаСПодоходным * 6 / 100)</Сумма>
      <Статус>01</Статус>
      <Имя>УФК по г. Москва (для ГУ - Отделения ПФР по г. Москве и Московской области)</Имя>
      <Основание>
        "Уплата ПФР - накопительная часть пенсии." Рег. № 087-301-000107.        За $ЗаМесяц месяц $Год года.
      </Основание>
      <ИНН>7703363868</ИНН>
      <КПП>770301001</КПП>
      <РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
      <КорСчет></КорСчет>
      <ВБанке>Отделение 1 Московского ГТУ Банка России г.Москве 705</ВБанке>
      <БИК>044583001</БИК>

      <КБК>39210202020061000160</КБК>
      <Показатель>
        <Типа>ВЗ</Типа>
      </Показатель>
    </Платеж>

    <Платеж id="ФФОМС">
      <Статус>01</Статус>
      <Сумма>$(ЗарплатаСПодоходным * 3.1 / 100)</Сумма>

      <Имя>УФК по г. Москва (для ГУ - Отделения ПФР по г. Москве и Московской области)</Имя>
      <Основание>Рег. в Управлеии ПФР № ГУ 6 087-301-000107. Рег. № в ФОМС 453160900411818. Страховые взносы ОМС, зачисляемые в бюджет ФФОМС.</Основание>
      <ИНН>7703363868</ИНН>
      <КПП>770301001</КПП>
      <РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
      <КорСчет></КорСчет>
      <ВБанке>Отделение 1 Московского ГТУ Банка России г.Москве 705</ВБанке>
      <БИК>044583001</БИК>

      <КБК>39210202101081011160</КБК>
      <Показатель>
        <Типа>ВЗ</Типа>
      </Показатель>
    </Платеж>
    
    <Платеж id="ПодоходныйНалог">
      <Статус>02</Статус>
      <Сумма>$ПодоходныйНалог</Сумма>
      <Основание>Подоходный налог с з/п.</Основание>

      <Имя>УФК по г. Москве (ИФНС России № 16 по СВАО г. Москве).
            Лицевой счет $ЛицевойСчет.</Имя>
      <ИНН>7716103458</ИНН>
      <КПП>771601001</КПП>
      <РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
      <КорСчет></КорСчет>
      <ВБанке>Отделение 1 Московского ГТУ Банка России г.Москве 705</ВБанке>
      <БИК>044583001</БИК>
      
      <КБК>18210102021011000110</КБК>
    </Платеж>

    <Платеж id="СтраховойТарифОтрасли">
      <Статус>08</Статус>
      <Тариф>0.2</Тариф>
      <Сумма>$(ЗарплатаСПодоходным * Платеж_Тариф / 100)</Сумма>
      <Основание>Уплата страхового тарифа 
              отрасли $Платеж_Тариф%. Рег. № 7729032413.</Основание>

      <Имя>Филиал №29 ГУ - МРО ФСС РФ</Имя>
      <ИНН>7710030933</ИНН>
      <КПП>770701001</КПП>
      <РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
      <КорСчет></КорСчет>
      <ВБанке>Отделение 1 Московского ГТУ Банка России в г.Москве</ВБанке>
      <БИК>044583001</БИК>

      <КБК>39310202050071000160</КБК>
    </Платеж>


    <Платеж id="ФСС">
      <Статус>08</Статус>
      <Тариф>2.9</Тариф>
      <Сумма>$(ЗарплатаСПодоходным * Платеж_Тариф / 100)</Сумма>
      <Основание>Уплата в ФСС по временной нетрудоспособности и в связи с 
                 материнством $Платеж_Тариф%. Рег. № 7729032413.</Основание>

      <Имя>УФК по г. Москва (Госудерственное учреждение - 
           Московское региональное отделение Фонда социального 
           страхования Российской Фередерации)</Имя>
      <ИНН>7710030933</ИНН>
      <КПП>770701001</КПП>
      <РассчетрыйСчет>40101810800000010041</РассчетрыйСчет>
      <КорСчет></КорСчет>
      <ВБанке>Отделение 1 Московского ГТУ Банка России в г.Москве</ВБанке>
      <БИК>044583001</БИК>

      <КБК>39310202090071000160</КБК>
      <Показатель>
        <Типа>ВЗ</Типа>
      </Показатель>
    </Платеж>

    <Платеж id="ПереводСуммыЗарплатыНаКредитку">
      <Сумма>$ЗарплатаНаРуки</Сумма>
      <Основание>л/с 40817.810.0.3809.4505543 RuR з/п Чистяков Владислав Юрьевич</Основание>
                     
      <Имя>Чистяков Владислав Юрьевич, Мещанское ОСБ № 7811/01444, г. Москва</Имя>
      <ИНН>772415355463</ИНН>
      <КПП>0</КПП>
      <РассчетрыйСчет>40817810038094505543</РассчетрыйСчет>
      <КорСчет>30101810400000000225</КорСчет>
      <ВБанке>Сбербанк России, ОАО. г. Москва</ВБанке>
      <БИК>044525225</БИК>

      <КБК></КБК>
      <Показатель>
        <Основания></Основания>
        <НалоговогоПериода></НалоговогоПериода>
        <НомераДокумента></НомераДокумента>
        <ДатыДокумента></ДатыДокумента>
        <Типа></Типа>
      </Показатель>
      <СуммаПрописью>$(РублиПрописью(Платеж_Сумма)) 00 копеек</СуммаПрописью>
      
      <Очередность>3</Очередность>
      <ОКАТО></ОКАТО>
      <Статус></Статус>
    </Платеж>
  </Items>
</Specification>

А вот файлик который используется для генерации платежек в формате 1Эс-ного экспорта:

СекцияДокумент=Платежное поручение
Номер=##Платеж_Номер##
Дата=##Дата##
Сумма=##Платеж_Сумма##
ПлательщикСчет=##Мы_РассчетрыйСчет##
ПлательщикИНН=##Мы_ИНН##
Плательщик1=##Мы_Имя##
ПлательщикБанк1=##Мы_НаименованиеБанка##
ПлательщикБИК=##Мы_БИК##
ПлательщикКорсчет=##Мы_КорСчет##
ПолучательСчет=##Платеж_РассчетрыйСчет##
ПолучательИНН=##Платеж_ИНН##
Получатель1=##Платеж_Имя##
ПолучательБанк1=##Платеж_ВБанке##
ПолучательБИК=##Платеж_БИК##
ПолучательКорсчет=##Платеж_КорСчет##
ВидПлатежа=01
Очередность=##Платеж_Очередность##
НазначениеПлатежа=##Платеж_Основание## ##Платеж_СуммаНДС##
СтатусСоставителя=##Платеж_Статус##
ПлательщикКПП=##Мы_КПП##
ПолучательКПП=##Платеж_КПП##
ПоказательКБК=##Платеж_КБК##
ОКАТО=##Платеж_ОКАТО##
ПоказательОснования=##Платеж_Показатель_Основания##
ПоказательПериода=##Платеж_Показатель_НалоговогоПериода##
ПоказательНомера=##Платеж_Показатель_НомераДокумента##
ПоказательДаты=##Платеж_Показатель_ДатыДокумента##
ПоказательТипа=##Платеж_Показатель_Типа##
КонецДокумента

Я даже GUI поленился приделать, так как три поля можно и руками заполнять. :shuffle:

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

T>По поводу Windows (cmd) соглашусь, а по поводу PowerShell, bash и пр., нет, это полноценные языки общего назначения (особенно PowerShell). Но назвать cmd хорошим DSL-ем значит сделать антирекламу всей идеи.

ДСЛ-ями скорее являются команды копирования, перемещения и удаления. Против robocopy.exe возражения есть? :))

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

VD>И авторитетно тебе заявляю, что создать ДСЛ по твоей лапше нельзя в принципе.

Больше вопросов не имею.

AVK>>Я правильно понимаю, что вы по прежнему предлагаете писать DSL под каждый конкретный продукт?

VD>Это зависит. Иногда даже для отдельной подзадачи.

Ясно. DSL с ровно одним использованием — это круто.

VD>Помнишь, кстати, такой продукт — Турбо Бухгалтер? Не знаю как сейчас, но в 90-ых это был ДСЛ для маленьких бухгалтерий.

Только DSL там был очень похож на то, что мы сейчас имеем в 1С.

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

Это просто настройка для уже написанного кода расчета зарплаты. Я же спрашивал про DSL для самого кода рассчета зарплаты.

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

AVK>>>Я правильно понимаю, что вы по прежнему предлагаете писать DSL под каждый конкретный продукт?
VD>>Это зависит. Иногда даже для отдельной подзадачи.

AVK>Ясно. DSL с ровно одним использованием — это круто.

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

VD>>Помнишь, кстати, такой продукт — Турбо Бухгалтер? Не знаю как сейчас, но в 90-ых это был ДСЛ для маленьких бухгалтерий.

AVK>Только DSL там был очень похож на то, что мы сейчас имеем в 1С.

Вообще ничего общего. Там ДСЛ имел вид списка проводок. Что-то типа:

#12.01.2012
12345 ID_однго_счета ID_другого_счета -- коментарий
некоторая-формула ID_другого_счета ID_другого_счета -- коментарий
...

Сам Турбо-Бухгалтер был эдаким компилятором который читал этот файл и генерировал по нему нужные документы. Еще были другие файлы с описание счетов и т.п.

Эдакая смесь базы данных в текстовом виде и простенького языка программирования позволяющего вычислять суммы проводок на основании имеющихся данных.

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

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

AVK>Это просто настройка для уже написанного кода расчета зарплаты. Я же спрашивал про DSL для самого кода рассчета зарплаты.

Ты ошибаешься. Расчет зарплаты прямо там приведен. Просто он очень простой.

Сам расчет зарплаты — это не более чем набор формул. Вводим исходные цифры (сумма зарплаты, в моем случае) и вычисляем какие налоги нужно заплатить.

Если бы стояла задачи рассчитывать сами начисления, то это тоже не было бы проблемой. Описать их в виде пропертей и использовать в рассчете.

То что я тебе показал — это нечто генератора отчетов по модели. Модель состоит из свойств (пропертей) и ряда "документов". Я с помощью этого дела генерирую накладные при выходе нового номера журнала. Опять же процедура полностью автоматизирована. Документами, при этом, являются список заказов (кто чего заказал и какая у них скидка), а результатом набор документов: счета, накладные, счета фактуры. Для некоторых журналов в итоге получается стопка в сотни страниц. При этом заводится всего несколько цифр. Печать идет через эксел. Он как шаблонизатор выступает. Открывается в текстовом виде (xml), трансформируется и выбрасывается на печать.

Заметь ДСЛ-ь этот не внутренний, а внешний. Используется он в трех разных видах задач и автоматизирует работу которая при ручном ее исполнении у меня занимала по пол дня (а то и весь день). Но главное — это то, что он резко сокращает объем ошибок и их исправление, в случае чего.