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

S> Угу смотрю я на запросы по 10 страниц никакой простоты и наглядности.
Напиши это с использованием прямого обращения к физической структуре БД. И запросы раздуются раз в 100.

S>Через навигационные методы было бы проще и нагляднее
Ну-ну.

S>или Linq.
Так я уже говорил, что линк это более правильный SQL.
Кстати проблемы SQL вызваны в немалой степени тем, что его пытались заточить под кухарок. Не вышло. И нормальным программистам проблем добавили.

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

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

S>> Угу смотрю я на запросы по 10 страниц никакой простоты и наглядности.
WH>Напиши это с использованием прямого обращения к физической структуре БД. И запросы раздуются раз в 100.
Ну писал огромное количество в свое время. Знаю о чем говорю. При том, что на любой структуре можно построить класс.
S>>Через навигационные методы было бы проще и нагляднее
WH>Ну-ну.
Есть куча мест где они и намного наглядне. Приходится писать кучу вложенных запросов просто для ипользовании вычисленных значений, что бы не было повторений и городить еще более сложный код для понимания, или разбивать текст на несколько строк, а потом их сшивать для получения результирующего запроса итд. И это еще в 1С где есть более менее нормальный конструктор "объектных" запросов.
S>>или Linq.
WH>Так я уже говорил, что линк это более правильный SQL.
WH>Кстати проблемы SQL вызваны в немалой степени тем, что его пытались заточить под кухарок. Не вышло. И нормальным программистам проблем добавили.
Ну так сколько времени то прошло. И Linq to EF нужно развивать. Кстати Linq пока хорош совместно с ObjectQuery. Так как у Linq есть ограничения в том числе и массовых изменений данных (Merge булки итд). И хотелось бы полностью избавиться от SQL.

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

G>>>Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL.
O>> Это не так.

G>Покажи на примере чтоли?

Давайте задачу — покажу, как хреноватый кодер (я, то есть), не приходя в сознание под эту задачу dsl делает.

O>> PHP. Серьезно.
G>PHP — язык общего назначения.

А мы теперь только не-Тьюринг-полные языки будем за dsl считать? Я так не играю.

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


b-3>А вы о чём? Я вообще первый раз слышу, чтоб семантику (не грамматику, а именно семантику) сводили к "правилам переписывания".

Вы бы полистали хотя бы один учебник по денотационным семантикам, что ли.

b-3>Можно где-нибудь пример таких "правил переписывания" увидеть?

Да то же хваленое лямбда-исчисление — не более чем TRS. Погуглите о term rewriting, много интересного узнаете. И еще советую посмотреть на язык Mathematica, он весь на переписывании построен, из его дизайна можно много полезных трюков наворовать.

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

WH>Да правда что ли? SQL сплошной матан. YACC, ANTLR и тп тоже один сплошной матан.

Все не так плохо. Для того, чтобы пользоваться sql, реляционную алгебру знать не обязательно. Можно описывать грамматики на yacc, antlr или даже Boost::Spirit и не понимать ничего про используемые алгоритмы парсинга. Эти DSL скрывают сложность, и именно по этой причине они популярны.

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

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

WH>Честно говоря, современные наработки весьма кривы. Но я работаю над выпрямлением.
WH>https://github.com/rampelstinskin/ParserGenerator

Кстати, почему не packrat? Он туп как пробка, и тем прекрасен?

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

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

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

WH>> YACC, ANTLR и тп тоже один сплошной матан.

N>Адаптаторы и power users не пишут на Yacc.

Однако power users обожают регвыры, куда как более матанистые.

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

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

Именно. Чем длиннее цепочка переписываний, чем меньше разницы между промежуточными языками в этой цепочке, тем все проще и надажнее.

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

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

WH>>Да правда что ли? SQL сплошной матан. YACC, ANTLR и тп тоже один сплошной матан.
O> Все не так плохо. Для того, чтобы пользоваться sql, реляционную алгебру знать не обязательно. Можно описывать грамматики на yacc, antlr или даже Boost::Spirit и не понимать ничего про используемые алгоритмы парсинга. Эти DSL скрывают сложность, и именно по этой причине они популярны.
Я с этим не спорю.
Но прочитай, что он сказал.

G>И это закономерно, что базовая семантика этих языков тупа до безобразия. Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.

Он явно гонит. Что я и продемонстрировал.

O>Я согласен с вашим оппонентом, что dsl должны быть тупыми. Вся сложность должна прятаться в их реализации. И есть множество способов сокращения даже этой сложности — если использовать dsl для реализации dsl, и если использовать более простые или более общие dsl в качестве целевого языка при компиляции новых dsl. Такаямногоуровневая структура позволяет избавляться от сложности на всех этапах.
Подписываюсь под каждым словом.
И я тебе больше скажу: Именно разработкой такой системы я и занимаюсь.

Вот только он не это сказал.
Он сказал, что ДСЛ нужны только не программистам и в основе полезных ДСЛ нет матана.
Читай то, что написано, а не то, что ты хочешь прочитать.
И имей в виду гапертон талантливый болтун, который имеет убеждать других в том, что он что-то знает. Но это не так. Ибо он слил в 100% технических споров.

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

O>Кстати, почему не packrat? Он туп как пробка, и тем прекрасен?
1)Не смотря на линейность, он жуткий тормоз.
2)Задолбаешься задавать приоритеты операторам. А ассоциативность ПЕГ вообще не может.
3)У ПЕГ есть проблема с приоритетным выбором. Его очень сложно использовать.
4)ПЕГ в чистом виде не поддерживает изменение грамматики во время разбора.
5)У ПЕГ низкая декларативность. Фактически приходится описывать алгоритм разбора.
...
Мне просто лень перечислять весь список.

Поэтому был разработан новый алгоритм. За основу были взяты PEG и Pratt parser.

O>Но вообще, когда говорят о компиляторах, парсингу уделяют незаслуженно много внимания. И это одна из причин, почему все так боятся даже думать о том, чтобы написать компилятор.
Ну да. Парсер должен описываться очень просто.
Но современные инструменты не адекватны.
На том же ПЕГ это сделать очень не просто. Особенно если у тебя есть несколько операторов с разными приоритетами и ассоциативностью.

O>Сейчас даже на голом шарпе без сторонних библиотек dslы делать легко и приятно. Да что там, я их когда-то и на Фортране писал не включая мозга.
Какие ДСЛи?

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

S>>>Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД".
V>>А вы объясните зачем?
S>Как зачем? Чтобы выполнять задачи управления данными в БД.
Я непонимаю. Есть проблемы поважнее баз данных, которым совершенно не нужны такие раздутые "прямые обращения", а нужно просто хранение массивов данных в иерархии и быстрый доступ к ним. В 99% это будет возможно и достаточно без прямый обращений "к физической структуре БД".

S>Перечисленные вами аббревиатуры — это не замена SQL, а всего лишь библиотеки для использования того же самого SQL.
Это не факт. Под объектами может скрываться вообще любая база, даже та которая не имеет своего dsl.

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

WH>>> YACC, ANTLR и тп тоже один сплошной матан.
N>>Адаптаторы и power users не пишут на Yacc.
O>Однако power users обожают регвыры,

Слово-то какое.

O> куда как более матанистые.

Они менее матанистые, в тех пределах, в которых их обожают. Потому что описать как "любая хрень от 5 до 12 цифр, за которой до трёх букв" проще, чем грамматику. 90% из них скончается в моральном плане на первом же shift/reduce конфликте, не поняв, как эту грамматику правильно вывернуть.
Чтобы перейти на уровень, где грамматика проще регулярных выражений, надо выучить нехилый пласт теории.

BTW, типичное регулярное выражение это даже не grep/posix-style. Это BASIC-style (это там, где '#' значит цифру, а '%' любую строку).

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

ANS>>Наличие среди всего прочего "довольно интересного язык запросов" (читай "абсолютно идиотского") не делает весь язык "DSL".
S> Да нет в 8 ке это уже максимально приближенный к "нормальному языку" язык запросов.

Так Гапертон распинается за 7.x. Там система с запросами (не API для навигационного доступа, а именно запросы) была реально странная. Хотя, afair, работала нормально — если в запросе возвращаемый тип у поля был мономорфный (т.е. поле имело тип конкретного документа или справочника), то запрос генерился по одной таблице.

И вообще, чего все так к языку в 1С прицепились. С языками были и другие системы, а популярная — одна. Имхо основная причина популярности — доступная и вменяемая репортная часть. У бухов мало делать запросы, результат еще нужно распечатать.

Здравствуйте, Andrei N.Sobchuck, Вы писали:

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

ANS>>>Наличие среди всего прочего "довольно интересного язык запросов" (читай "абсолютно идиотского") не делает весь язык "DSL".
S>> Да нет в 8 ке это уже максимально приближенный к "нормальному языку" язык запросов.

ANS>Так Гапертон распинается за 7.x. Там система с запросами (не API для навигационного доступа, а именно запросы) была реально странная. Хотя, afair, работала нормально — если в запросе возвращаемый тип у поля был мономорфный (т.е. поле имело тип конкретного документа или справочника), то запрос генерился по одной таблице.

ANS>И вообще, чего все так к языку в 1С прицепились. С языками были и другие системы, а популярная — одна. Имхо основная причина популярности — доступная и вменяемая репортная часть. У бухов мало делать запросы, результат еще нужно распечатать.
Я в свое время выбрал в далеком 1996 1С тогда 7.0 из-за
1. Реализации в текущей конфигурации основных задач учета
2. Простая модификация данных и использования "объектов" конфигурации
3. Удобство формирования, вывода отчетов и обработка дейтвий пользователя с этим отчетом (вызов других отчетов по расшифровке в ячейке)
Наверное 2,3 пункт можно сравнивать с ДСЛ
Как таковой их язык запросов использовал не часто. Больше для меня подходил навигационный доступ через объекты.
На SQL там симбиоз и 1С запросов и 1С++. Самое основное это использование "объектных" запросов и использование полей с множественным типом.

По сути сейчас это аналог Linq to EF в ObjectQuery. Но когда появился ObjectQuery и 1С.
Вообще мне как 1С нику и просто работающему в 1С нужен только 1 ДСЛ это более продвинутый LINQ2SQL. А использовать его все равно придется в ЯОН. Если его так просто сделать, что же нет явных подвижек?

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

ANS>>Наличие среди всего прочего "довольно интересного язык запросов" (читай "абсолютно идиотского") не делает весь язык "DSL".

VE>А что делает язык DSL?

Нет формального критерия. Точнее чуть чуть есть (но нет). Различаю два вида DSL — внешний (external) и встроенный(embedded)(он же внутренний(internal)). Внешний реализован с помощью языка отличного от хост-языка (a-la Linq). А внутренний реализован на самом языке хостсистемы. Понятно, что есть языки на которых это получается красивее (Lisp, Ruby, ST), а есть на которых получается хуже. Понятно, что формализации в какой момент это еще API, а в какой это уже DSL тоже особо нету. "Assert" в jUnit это еще API или уже DSL? А х.з. А вот mockito уже больше похоже на внутренний DSL. Есть мнение, что любая большая система обрастая API обрастает и DSL-ями. Но имхо это бессмысленое утверждение (ввиду нефальсифицируемости).

При этом в основной массе, когда описывают что такое внутренний DSL, отдельно отмечают, что Word+VB это не DSL для обрабтки документов, а скриптовый язык. Какие критерии — я не знаю, но с тем, что Word+VB это не DSL для текстов я согласен. Если это всё переложить на 1С v7x, то получится, что движок+язык 1С это не DSL. Но внутренним DSL можно (если очень хочется) считать API для работы с проводками. Явным внешним DSL будет язык запросов в 1Cv7x. Та ж фигня с браузерами. Я ни разу не слышал, чтобы JS считали DSL для работы с DOM. Но, например, jquery можно считать internal DSL.

И еще пять копеек о том, что DSL всегда полезны. Вот в lisp есть loop. Персонально мне не кажется, что это такое большое достижение перед обычными циклами. А вот в том, что это переусложнение я уверен.

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

S> Я в свое время выбрал в далеком 1996 1С тогда 7.0 из-за
S>1. Реализации в текущей конфигурации основных задач учета
S>2. Простая модификация данных и использования "объектов" конфигурации
S>3. Удобство формирования, вывода отчетов и обработка дейтвий пользователя с этим отчетом (вызов других отчетов по расшифровке в ячейке)

Думаю для многих эти три пункта были критерием. И, думаю, п.1 это следствие п.2, п.3.

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

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

S>>Тысячи их.
_>И везде одна и та же ерунда. )

S>>Чуть менее, чем во всех GUI-фреймворках привязка обработчиков выполнена внутри "языка размётки". Сами обработчики традиционно отдаются в General-Purpose-язык, но это исключительно оттого, что не хочется делать "ещё один" turing-complete язык внутри разметочного.

_>Ну так я про то и говорю, что кругом просто "размётка". И в этом случае я невижу никакого смысла для отдельного языка под это — проще сразу генерировать в редакторе готовый код на системном языке.

_>А вот если бы у нас в gui dsl можно было бы задавать хотя бы минимальные действия... Весь значительная часть обработчиков замкнута самая же на себя. Т.е. зачем обращаться в мощный основной язык ради того что бы в обработчики команды меню вызвать команду "показать диалог такой-то". И таких вызовов очень много! Значительная часть обработчиков состоит из вызова одной строки — вызова функции другого gui контрола. Это всё можно было замкнуть внутри себя, сделав вызовы наружу (в системный язык) только уже для реальной функциональности. Вот на такой dsl я бы точно перешёл. Но таких gui фреймворков я не знаю вообще.

_>А с текущей ситуацией "просто размётки с указанием имён обработчиков" и при наличие визуального редактора у меня на такие dsl действует только бритва Оккама.

Ты вроде раньше говорил, что разработка у тебя под виндой и используется (или теперь уже использовалась) студия. Гуй, я так понимаю, какой-то свой, но по идеологии что-то напоминает MFC. Я уже смутно помню, какое там было взаимоотношение дизайнеров с их местными картами сообщений, но такие мотивы песен вроде тебя не устраивают. Среди промышленных систем Delphi умеет делать то, что ты хочешь, со времён царя гороха. Там кроме визуальных контролов/виджетов есть и невизуальные компоненты, которыми тоже можно манипулировать в дизайнере. В нашем случае это так называемые там Action-ы: програмляются типовые объекты, которые реализуют нужные универсальные действия, затем эти action-ы в дизайнере привязал к нужным кнопкам и меню и т.д. Из коробки есть много чего типового, фактически, для учебного примера можно только в дизайнере наваять полноценный редактор по типу блокнота, не написав ни строчки кода (хотя, скорее всего, я несколько преувеличиваю, но не много). А если к такой системе прикрутить тот ДРАКОН, о котором мы недавно говорили — получи полноценную, и реально мощную, графическую систему программирования.

А вообще-то, я тебе как-то говорил про нашу DSL-систему. У нас там есть фактически встроенная мини-дельфи. Но со временем у нас развился альтернативный скриптовый язык (кроме встроенного Паскаля), и для наших (!) многих задач мы убедились, что эффективнее всё-таки вручную програмлять интерфейс, особенно, если язык, простой и эффективный, позволяет несложно это делать. Как-то это гибче, мощнее, особенно когда нужно реализовать сотни типовых форм. Но и GUI-дизайнер тоже для ряда случаев удобная вещь.

Здесь рядом в своём сообщении WolfHound говорит о реактивном программировании на основе model-view. Вполне здравая идея, проверенная у нас. Удобно, когда подправил скрипт и сразу видишь результат неотходя от кассы, часто не нужны отладчики или debug-сообщения.

И языки разметки, имхо, на помойку лучше не выбрасывать пока, их неплохо можно готовить несколько по другим рецептам. Вот представь, что ты делаешь ГУИ на основе какого-нибудь HTMLLayout. Здесь есть отличный шанс на разделение задач: HTML — это структура, основа, документа, CSS — оформление (возможен не один вариант). При этом, какие-то верстальщики формируют HTML, они для этого могут сами для себя воспользоваться ещё одним DSL, например, Haml, какие-то дизайнеры возятся с CSS, могут для себя использовать Sass — ещё один DSL. Внутри HTML можно указать ещё DSL — шаблон для формирования документа. Лично мне симпатичны шаблоны без встроенного кода, как CTemplate от Google, или по мотивам Mustache ( {{переменная}}, {{! комментарий }}, {{#секция}} — {{/секция}}).

А вообще-то, лично я с вебом слабо повязан, но я заметил хороший подход в некоторых фреймворках на Кложуре (возможно это сплошь и рядом, я не в курсе, но что-то сильно не заметно). Создаётся чистый HTML (пусть верстальщиком, дизайнером), без шаблонов, без CSS-элементов, без никакого кода, где есть некоторые правила, например, условные имена для div. Программист в коде читает этот файл, он трансформируется в структуры и пр. этого языка, дальше манипулируй с документом как хочешь в рамках программного кода. Также можно работать с CSS. Можно с нуля всё запрограмлять. Можно обработчики событий назначить, при этом можно код писать в самой Кложуре, вроде есть компиляция в JavaScript.
Таким образом, можно получить такое разделение: отдельно только разметка, отдельно только оформление, и отдельно программный код. При этом каждый может заниматься своим делом, удобным ему способом, и никто друг на друга не влияет (относительно, конечно). Может всем заниматься один человек, может всё запрограмлять на одном языке, без HTML и пр.
В этом конкретном случае ещё здорово помогает и сам язык и его платформа, для тех, конечно, кто с лиспом дружит.

Имхо, отличный подход, который можно взять на вооружение не только для веба.

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

S> Есть куча мест где они и намного наглядне. Приходится писать кучу вложенных запросов просто для ипользовании вычисленных значений, что бы не было повторений и городить еще более сложный код для понимания,
Ну, во-первых, вы правы. При разработке SQL вопросы повторного использования не рассматривались почти что никак. Поэтому в нём, в частности, нет функций высшего порядка. Да и вообще функций, аргументом которых являлось бы relation, нет.
Во-вторых, всё же всё не настолько плохо, как вы говорите. В новом SQL есть with как способ введения "табличной переменной".

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


S>>Как зачем? Чтобы выполнять задачи управления данными в БД.
V>Я непонимаю. Есть проблемы поважнее баз данных, которым совершенно не нужны такие раздутые "прямые обращения", а нужно просто хранение массивов данных в иерархии и быстрый доступ к ним.
Если вам нужно "просто хранение массивов данных в иерархии и быстрый доступ к ним", то вам не нужен ни SQL, ни заменяемая им равномощная библиотека.

Здравствуйте, WolfHound, Вы писали:
WH>Мой вариант такого ДСЛ основан на MVVM.
WH>Model это произвольный код, не имеющий к ГУИ отношения.
WH>ViewModel основана на реактивном программировании. Те если внутри ViewModel что-то изменилось, то все что на основе этого было вычислено также автоматические пересчитывается.
Надо понять, что такое "было вычислено", и что такое "автоматически пересчитывается".
WH>View это маппинг ViewModel на контролы. Благодаря реактивности при любом изменении ViewModel View автоматически пересчитывается. Также View может менять ViewModel при помощи биндинга свойств контролов на свойства ViewModel.
Давайте обсудим примеры каких-нибудь конкретных gui-сценариев, где "в классике" нам нужно писать обработчики событий, от которых хочется уйти.

1. Зависимые контролы. Типа выбор радиобаттона определяет видимость или разблокированность связанных с ним контролов. Очевидно, решается введением зависимых свойств. Типа, BillingAddressPanel.Enabled = !BillingIsTheSameAsShipping.Checked
2. Валидация данных, с отображением результата валидации. Вариантов оформления — бездна. Суть — более-менее одна: есть некая формула, которая связывает данные с результатом валидации, а результат валидации — с внешним видом контролов. Опять — таки зависимые свойства.
3. Нетривиальное поведение. Скажем, вводим URL — по окончанию ввода в фоне программа бежит по этой ссылке и отображает preview картинки или что там по этому URL нашлось (см.тж. facebook).
Тут нюанс в том, что надо вешаться не каждое изменение данных, а только на более-менее паузы.
В Delphi мы такие штуки делали путём добавления отдельного объекта-таймера и довольно муторной обработки событий OnChanged и OnTimer.
4. Аналогичная штука — анимации.
То есть для 3 и 4 просто зависимостей от мгновенных значений есть ещё необходимость всё-таки реагировать на события, или на их цепочки, определённым образом. Пока мне не очевидно, как это сделать хорошим способом. Не обязательно визуальным — важно обойтись без лишнего мусора, типа асинхронных таймеров и синхронных стейт-машин, описанных вручную.