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

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

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

На DSL тут не императивщину писать надо, а связывать элементы управления и команды. Но вроде в дизайнере это и так несложно делается визуально.

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

VD> Таким образом, несмотря на его ориентированность на предметную область, я бы не назвал его предметно-ориентированным языком.

5 баллов. "Несмотря на то, что эта ткань белого цвета, я бы не назвал её белой". Это везде так у Фаулера?

VD>Другими словами — поддерживает мою точку зрения .

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

А если более конструктивно, вы оба впали в проблему недостатка терминов, но почему-то отказываетесь признать это явно. Хороший учёный тут хотя бы пронумеровал варианты, если недостаточно данных или фантазии для собственных названий. Например, белый-1 — это тот белый, который ты признаёшь белым, а белый-2 — тот, что не признаёшь. Далее попытался бы сформулировать критерии различия, пусть даже кривые и нечёткие. Проблема уже поставлена, а дальше можно надеяться, что кто-то ещё сможет сформулировать различие.

Мне кажется, что тут таки надо различать предметную *ориентированность*, *специализированность*, *специфичность* и *ограниченность*. То, что Фаулер пытался сказать, должно быть скорее сказано так: "R обладает предметной *ориентированностью* на задачи статистики, и частично *специализирован* на неё, но не *специфичен* и не *ограничен*".

Прикидка определения каждого из этих понятий:
* ориентированность — имеет специализированные средства для названной цели, но не общую адаптацию
* специализированность — адаптирован в целом (в общих принципах) под названную цель
* специфичность — реализация запросов за пределами названной цели заметно усложнена
* ограниченность — не имеет средств, выходящих за пределы, нужны для реализации названной цели

они представляют собой последовательное усиление в сторону DSL, в том же порядке.

VD>Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.

См. выше — должен быть не один критерий, а четыре.

VD>Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:

VD>В этом определении есть четыре ключевых элемента.
VD>* Язык программирования...
VD>* Природа языка...
VD>* Ограниченные выразительные возможности...
VD>* Ориентированность на предметную область...
VD>Обратите внимание на то, что ориентированность на предметную область оказалась последней в списке и является лишь следствием ограниченных выразительных возможностей. Многие используют буквальное определение DSL как язык для конкретной предметной области.

Во-во. Проблему он почувствовал, но выразить не супел.

VD>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем. А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.

Так крайние случаи очевидны, если бы всё состояло из них, и дискуссии не было бы.

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

G>>Впрочем, 1С-сники специально сделали ее настолько простой, что на ней может писать бухгалтер.

VD>Это полнейший гон. Ни одни бухгалтер (если он по совместительству не программист) не сможет написать на 1Эс нихрена.

"Это полнейший гон" — надо понимать заголовок твоего последующего суждения?

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

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

V>За свой небольшой опыт работы 1Сником — 1 год всего-лишь, я лично работал с тремя клиентами, которые сами писали себе код — с двумя бухгалтерами и одним мелким предпринимателем.
V>Да это был не ахти какой сложный код, они не автоматизировали полный цикл производства или что-то в этом духе, но делали себе отчеты, добавляли субконто к проводкам и тому подобные мелочи.
V>Программирование не настолько сложная штука, чтобы ей могли заниматься только программисты с профильным образованием.

Не надо откровенно врать. То что кто-то там в визуальном редактре сделал себе отчет (скорее всего под присмотром программиста) еще не значит, что этот человек может писать на языке встроенном в 1Эс. А именно он здесь обсуждается.

Я знаю много околокомпьютерных людей близких к программированию, но не программистов и не раз видел как они пытались влезть в программирование Ворда, Ёкселя или Эксеса. Их хватало на примитивные правки сгенерированного кода. Попытка выразить логику на (вроде бы языке для не проффесионалов) неизменно выливалась в то, что они звали меня или еще кого-то.

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

Идея "заставить писать код экспертов предметной области" поднималась уже не раз. Всякий раз они проваливалась. Хрестоматийный пример — SQL.

Но SQL хотя бы ДСЛ. А 1Эс-ный язык — это полноценный императивный язык. Для его освоения надо стать программистом.

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

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

O> А, ну да, оба из 70х. В любом случае, парсеры это далеко не главное. Драконовщина нанесла непоправимый вред в первую очередь как раз зацикленностью на парсерах.

На самом деле там парсерам посвящено не более 20% места.

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

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

WH>>Она не вся гнилая. Есть там и полезные темы. Просто нужно перекопать кучу навоза, чтобы найти что-то полезное.

O> Естественно, term rewriting, семантики и тому подобное это в целом полезно.

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

O>Хоть и тут без ненужного переусложнения не обошлись.

+1

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

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

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

N>Хорошо, я теперь буду знать, что "я бы не назвал белое белым" является адекватным выражением твоей точки зрения. Учтём это в спорах об уездном городе языке N и других горячих темах

Ты занимаешься демагогией. Он же привел отличный пример. Монеты ни разу не компакт-диски, не смотря на то, что они несомненно компактные, и несомненно диски.

Точно так же одно то, что язык используется для решения узкого круга задач, еще недостаточно для того чтобы называть его ДСЛ-ем. Он так же должен обладать ограниченными выразительными возможностями. Языки обладающие неограниченными выразительными возможностями не могут называться ДСЛ-ями. По сему 1Эс и ВБА не ДСЛ-и.

Серджинио тут где-то привел определение подходящее для 1Эс-ного язяка. Что-то типа предметно-ориентированный язык высокого уровня. Что можно перевести на детерминированный язык как заточенный под предмет ЯОН.

N>А если более конструктивно, вы оба впали в проблему недостатка терминов, но почему-то отказываетесь признать это явно.

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

Причем дело доходит до обсурда.

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

Другой называет ДСЛ-ем наличие модели в приложении.

Третий видит ДСЛ в любом АПИ.

Короче полнейшая каша. С такой терминологической какофонией применять этот термин нельзя в принципе. Иначе любой разговор превратится в полную бессмыслицу.

N> Хороший учёный тут хотя бы пронумеровал варианты, если недостаточно данных или фантазии для собственных названий. Например, белый-1 — это тот белый, который ты признаёшь белым, а белый-2 — тот, что не признаёшь. Далее попытался бы сформулировать критерии различия, пусть даже кривые и нечёткие. Проблема уже поставлена, а дальше можно надеяться, что кто-то ещё сможет сформулировать различие.

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

N>Мне кажется, что тут таки надо различать предметную *ориентированность*, *специализированность*, *специфичность* и *ограниченность*. То, что Фаулер пытался сказать, должно быть скорее сказано так: "R обладает предметной *ориентированностью* на задачи статистики, и частично *специализирован* на неё, но не *специфичен* и не *ограничен*".

Фаулер не рассматривает отвлеченных тем. Он рассматривает то, что он сам считает (и называет) ДСЛ-ями.
По сему он привел ряд критериев которые позволяют назвать язык ДСЛ-ем (по его мнению). Я сними согласен.
Но к сожалению, они неформальны. Вот они:

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

В этом определении есть четыре ключевых элемента.
• Язык программирования. DSL используется людьми для постановки задачи компьютеру. Как и структура любого современного языка программирования, его структура призвана облегчить понимание языка человеком, но при этом он должен вы полняться компьютером.
• Природа языка. DSL является языком программирования и как таковой должен давать ощущение свободы выразительных возможностей, проистекающее не только из отдельных выражений, но и из способа их соединения.
• Ограниченные выразительные возможности. Язык программирования общего назначения предоставляет множество возможностей: поддержку разнообразных данных, управления и абстрактных структур. Все это полезно, но делает язык сложным в освоении и использовании. DSL поддерживает минимум возможностей, необходимых для поддержки своей предметной области. Вы не можете построить всю программную систему с помощью DSL; вместо этого DSL используется для
одного конкретного аспекта этой системы.
• Ориентированность на предметную область. Ограниченный язык полезен только в том случае, если имеет четкую направленность на небольшую предметную область. Ориентированность на предметную область  вот что придает ценность такому языку.

Обратите внимание на то, что ориентированность на предметную область оказалась последней в списке и является лишь следствием ограниченных выразительных возможностей. Многие используют буквальное определение DSL как язык для конкретной предметной области. Но буквальные определения часто неправильны: мы не называем монеты компактдисками, хотя это типичные диски, которые, конечно, более компактны, чем те, к которым мы применяем данный термин.

Его мысль в том, что наличие одного из условий еще не делает язык ДСЛ-ем. Нужно сочетание факторов.
И я с этим категорически согласен.

N>Прикидка определения каждого из этих понятий:
N>* ориентированность — имеет специализированные средства для названной цели, но не общую адаптацию
N>* специализированность — адаптирован в целом (в общих принципах) под названную цель
N>* специфичность — реализация запросов за пределами названной цели заметно усложнена
N>* ограниченность — не имеет средств, выходящих за пределы, нужны для реализации названной цели

Опять какая-то каша. Ориентированность, специализированность и специфичность — это все из одной оперы.

VD>>Взаимоисключаемы ДСЛ-и и ЯОН-ы. Понятно, что полнота по тьюрингу не четкий критерий, но наличие процедур, циклов, условных операторов и прочего барахла, как бы говорит нам, что это 100% ЯОН. И не фига тут философствовать.

N>См. выше — должен быть не один критерий, а четыре.

Твои критерии вообще никуда не годятся. Критерии фаулера — годятся.

Язык с неограниченной выразительностью ДСЛ-ем быть не может, согласно этим критериям.

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

Зато язык не полный по тьюрингу и ориентированный на конкретную задачу — это уже точно ДСЛ.

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

N>Во-во. Проблему он почувствовал, но выразить не супел.

Он то сумел. Просто кто-то кобенится и не хочет понять сказанного.

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

VD>>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем. А вот реальные ЯОН вроде ВБА и 1Эс вы, почему-то, определяете как ДСЛ. Хот, казалось бы, взгляни на них и все поймешь.

N>Так крайние случаи очевидны, если бы всё состояло из них, и дискуссии не было бы.

В том то и дело, что у нас дисскурссия возникает даже по крайним случаям. Есть не мало упертых товарищей которые называют ДСЛ-ями ВБА. А кое-то (весьма не глупый) вообще дофилософствовался до того, что подменил понятие "уровень языка" понятием "ДСЛ", а ДСЛ в его словах это любой язык относительно языка более низкого уровня.

Такие "знания" и такая терминология не дает возможность продуктивно обсуждать данную область.

Так что нужно сделать одно из двух:
1. Ограничить определение термина ДСЛ выделив независимые понятия в отдельные понятия и дав им названия (введя термины).
2. Придумать новые термины для подтипов ДСЛ-ей, если уж не удается прийти к консенсусу в п.1.

Вот регекспы и ВБА по-твоему ДСЛ-и?

Если, да, то нужно придумать новые термины для различения этих подвидов ДСЛ-ей.

Если нет, то для ВБА нужно придумать отдельный термин, а ДСЛ-ем называть только регекспы.

Для ВБА термин есть — скриповый язык встроенный в хост-приложение. А как нажвать класс ДСЛ-ей в который входят регексы, SQL и т.п.?

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

S>И ты в поддержку этой точки зрения цитируешь Фаулера, для которого XSTL одновременно является и GPPL и DSL — в зависимости от задачи.

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

Фаулер тоже философствует. Критерии действительно не четки. И XSTL — это забавный пример. В принципе XSTL отлично подходит под определение ДСЛ-я, но в погоне за гибкостью в XSTL были включены фичи которые позволяют использовать (и довольно эффективно) его не по назначению. Если XSTL начинает использоваться не для преобразования текста — это он сразу же превращается в ЯОН. Главное здесь, то что использование XSTL для рассчетов — это внеполовое извращение.

С другой стороны язык 1Эс по своему дизайну позволяет писать код вне предметной области на которую он рассчитан. При этом никаких извращений предпринимать не нужно, так как 1Эс — это полноценный процедурный язык. В нем есть универсальные штатные средства — циклы, процедуры, операторы условного преехода.

VD>>И все это потому, что ДСЛ — это не о том, что язык для чего-то заточен, а о том, что язык предназначен только для чего-то.
S>Ок, так тоже можно. Но даже если мы будем судить о DSL-ности по тому, чего именно нельзя на этом языке, всё равно у нас будет континуум таких языков.

Нам нужно четко разделить ВБА, 1 Эс, SQL и регексы. SQL и регексы — это четкие представители того что я (и, как оказалось, Фаулер) называю ДСЛ-ем. ВБА — для меня вообще скрипт не имеющий к ДСЛ-ю никакого отношения. 1Эс — спорный вопрос, но я бы отнес его к специализированным ЯОН или даже к ЯОН с со встроенными ДСЛ-ями (хотя основную мощь в 1Эс определяет среда и встроенная модель).

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

На мой взгляд ДСЛ должен обладать одной моделью. Если язык штатно позволяет манипулировать несколькими моделями, то это уже ЯОН (или очень кривой ДСЛ).

Скажем моделью SQL является запрос к СУБД, ХСЛТ описывает модель трансформации ХМЛ, а моделью регексов — паттерн поиска подстроки в тексте. SQL, ХСЛТ и регексы всего лишь удобный синтаксис по заполнению соответствющих моделей. 1Эс же — это универсальный язык который позволяет в том числе манипулировать рядом моделей которые предоставляет среда 1Эс.

И это огромное различие. Под истенные ДСЛ можно подвести четкую иделогию:
1. Проектируем модель описывающую решаемую задачу.
2. Проектируем язык позволяющий максимально декларативно и понятно заполнить модель.
3. Делам компилятор или интерпретатор модели.

Все! Мы получили способ решения сложных проблем в любой области.

Для создания жерешений вроде 1Эс данная иделогия не применима, так как в 1Эс много моделей и связующего их кода. 1Эс можно представить как ряд ДСЛ-ей, часть из которых визуальные (формоклепство и описание отчетов).

VD>>Еще одним показателем ЯОН-а является то можно ли на нем (без использования других языков) написать целую систему.
S>Я уже в этой ветке писал, что это — не критерий. На языке C без использования других языков ничего полезного не напишешь, тупо потому, что в него кроме управляющих конструкций ничего не встроено. А библиотеки для него, обеспечивающие ему возможности для написания систем, написаны, очевидно, с использованием других языков.

Ты опять извращаешь реальность. Библиотеки ни разу не отдельная сущность для ЯОН. У любого языка можно отнять библиотеки и он станет ограниченным в возможностях. Но это ни разу не меняет реальность.

Это ты выдумал сам, что ЯОН без библиотек чудесным образом превращается в ДСЛ. Но это не так! ЯОН позволяет описать модели прямо внутри себя и решить любые задачи без использования библиотек. Библиотеки только позволяют общаться с внешним миром.


VD>>Это не имеет отношение к делу. Ты как и многие не верно (прямолинейно) толкуешь термин ДСЛ. Кстати, у Фаулера об этом хорошо сказано:
S>Прости, но Фаулер для меня не авторитет. Для тебя, кстати, тоже — см. противоречие выше.

У меня вообще нет авторитетов. Но мужик провел реальную работу по классификации я согласен с его выводами. Ну, и сам факт, что мое мнение не уникально уже косвенно подтверждает его правоту.

VD>>Меня не интересует этот вопрос. Да и реально толстого мы все определим без проблем.
S>Практика показывает, что толстость человека напрямую зависит от его окружения. В компании дистрофиков типа меня или Мерля любой покажется толстоватым.

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

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

F>Я помню в школе у нас учительница преподавала химию и было все просто и понятно. Потом она переехала, вместо нее пришел новы преподавать, и сразу резко стало сложно и непонятно. Хотя сложность предмета при этом явно не изменилась.

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

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

V>А я не про DSL, а про то, что при наличии такой возможности многие DSL вполне могут служить языками общего назначения. Даже случайно.
Вы так говорите, как будто это плохо.

V>С тобой не согласен синтаксис объявления функций без определения в С и ключевое слово extern для переменных.
И тем не менее, никакого способа сообщить в языке "мне нужна эта библиотека" нету. Всю нездоровую мощь программе даёт рантайм,

V>В общем, никогда в плюсах линкер не был отдельно, это часть языка. Хотя бы потому, что без знания ABI конкретного компилятора линковка невозможна.
Простите, это чушь. Линкер всего лишь разрешает символьные имена. Никакой информации об ABI в нём нету. Ну, то есть современные линкеры стали шибко умными и поддерживают LTCG, но языку C не нужна LTCG. Она не является частью спецификации. И линкер не является частью языка C.

V>Если в этих модулях будут ср-ва "общего назначения", типа ввода/вывода в файлы, сеть и т.д., то ес-но станет. Но, насколько я помню, в Лого таких ср-в быть не может, все его операторы — это оператор рекурсии и команд над черепашкой.
Вы правильно помните. Итак, стал ли Лого GPPL после добавления возможности импорта библиотек на том же Лого?

V>Тем, что в С можно подключать любые нейтивные библиотеки. Похоже, ты путаешь синтаксис языка и его полную спецификацию. Для того, о чем ты говоришь, есть скриптовые языки с практически полной иммитацией синтаксиса С за исключением вот этого extern и предварительного объявления ф-ий. Их как раз для своих DSL в "любимом синтаксисе" и разработали.
Я как раз ничего не путаю. В JS я тоже могу подключать любые "нейтивные" библиотеки. Если хост будет столь добр, что разрешит CreateObject(), то я могу делать всё, что угодно. В С роль хоста играет линкер.

V>А для какого-нить скриптового, со встроенным типом SomeType — вовсе не факт. Потому что помимо синтаксиса важна еще семантика происходящего. И эта семантика таки входит в спецификацию языка.

Ок, тогда давайте вернёмся к вопросу определений. Как мы убедились, возможность подключать библиотеки сама по себе никак не влияет на DSLность языка.

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


V>Ну, во-первых запрос мне кажется некорректным, т.к. не выведет менеджеров, у которых не было продаж вообще.
Это зависит от формулировки задачи. Предположим, что он корректен.

V>Во-вторых, есть минимум 2 популярных библиотечных подхода:
V>1. это непосредственная реализация некоей функциональности (например, это иерархия объектов и весь функционал контролов WPF).
V>2. "движок" поверх этой функциональности, который на входе берет некое декларативное описание и по нему комбинирует имеющийся фнкционал (это интерпретаторы XAML форм, стилей, шаблонов отображения, шаблонов данных и т.д.)

V>Прикладной вызов либы как-то так:
V>

V>struct OrderTotal { ManagerID managerId; double amount; }

V>auto annual = select(from(orders), between(cdate("20100101", &Order::orderDate, cdate("20101231")))
V>auto byManager = group(annualOrders, groupBy(&Order::managerId));
V>auto orderTotals = transform(byManager, transformWrap<OrderTotal>((_1.managerId=_2.first, _1.amount=sum(_2.second, &Order::amount)) ));
V>

V>Дальше лень расписывать, пока было расписано подвыражение:
V>select ManagerID, sum(Orders.Amount) from Orders where Orders.OrderDate between '20100101' and '20101231' group by ManagerID;
Отлично. Пока что SQL рвёт библиотеку 1 к 3м по компактности и читаемости.
И это у вас ещё нет никаких попыток разрешить переписывания и оптимизации запроса внутри библиотеки — ваши предикаты это всего лишь функторы, а не Expression Trees.

V>Можно спросить, что ты хотел узнать?
Да я-то ничего нового не узнал. Я хотел вам показать разницу между DSL и библиотекой, нарисованной на GPPL. Надеюсь, показал.
V>На Клиппере пожестче было в свое время — никто не жаловался. И рвали по быстродействию любые базы, бо скомпилированный код многократно быстрее интерпретируемого работает.

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


V>>>Если же ты о перезаписи операций и прочей оптимизации — то это совсем отдельные операции, которые тоже, впрочем, достаточно формализованы.
S>>Хотелось бы, чтобы перезапись операций и прочая оптимизация были не хуже, чем в SQL.

V>Это нужен подход №2, когда выражение дается в виде декларации и доступно затем для аналитических вычислений. Тогда точно так же как показано выше в синтаксисе, но пусть select, from, transform и т.д. являюся не вызовами на обработку коллекций, а конструкторами узлов графа операций (аналог AST). Добавится лишь еще одна команда, нечто типа:
V>

V>auto resultingCollection = execute(result);
V>

Что-то меня гложут тяжкие сомнения про то, что это так легко сделать, как вы пишете. Скажем, Версанту потребовалось всё-таки приделать свой парсер C++, чтобы обойти ограничения языка. Для AST недостаточно скормить в between указатель на член класса — надо каким-то образом дать возможность среде определить, что это за член класса такой, и поднять всю нужную метадату.

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

T>Тут самое интересное начинается. Есть ДСЛ для организации всяких импортов ?
Мне неизвестны.

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

VD>Не надо откровенно врать. То что кто-то там в визуальном редактре сделал себе отчет (скорее всего под присмотром программиста) еще не значит, что этот человек может писать на языке встроенном в 1Эс. А именно он здесь обсуждается.
Вот и не ври. И желательно читать целиком написанное. Субконто к проводке ты не добавишь только визуальными средствами, да и предприниматель запрос к отчету писал руками, он просто не понял, как с помощью конструктора отчетов воплотить свою задумку. В последствии этот предприниматель мне пару звонил — спрашивал как обновить распределенную базу — значит что-то еще дописывал сам, без чьей-либо помощи.

VD>Я знаю много околокомпьютерных людей близких к программированию, но не программистов и не раз видел как они пытались влезть в программирование Ворда, Ёкселя или Эксеса. Их хватало на примитивные правки сгенерированного кода. Попытка выразить логику на (вроде бы языке для не проффесионалов) неизменно выливалась в то, что они звали меня или еще кого-то.
Почти согласен. Но лично знаю несколько человек, которые себе писали скриптовой код для бота одной онлайн игры, все они были не программистами. Про бухов я уже выше рассказал. Но таки да, 99% нифига не сделают.

VD>А так, даже не Эксесе любой продвинутый пользователь без проблем создаст отчет в визуальном редакторе, и даже сможет определить новые таблицы. Но как только дело дойдет до написания кода, то все побегут за программистом.

VD>Идея "заставить писать код экспертов предметной области" поднималась уже не раз. Всякий раз они проваливалась. Хрестоматийный пример — SQL.
И еще много раз провалится, в том числе и с DSLями.

VD>Но SQL хотя бы ДСЛ. А 1Эс-ный язык — это полноценный императивный язык. Для его освоения надо стать программистом.
Тут всплывает другой вопрос — что значит "стать программистом"?
Стать 1С программистом, при условии что раньше не программировал вообще, можно за пару месяцев, но чтобы писать вменяемый код, не просто рабочий — еще пару лет.
Я не готов спорить по поводу DSLности 1С, по нескольким причинам — я не знаю четкого и емкого определения DSL, а как показывает этот топик, оно необходимо, иначе спор похож на рассуждения дальтоников об оттенках красного, да и сам я 1с считаю императивным языком.

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

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

PD>Картинка размером от 3000*5000 до 5000*6000 пикселей, размер файла 15-30 Мб.
PD>Время на обработку — 200-300 мсек на современном процессоре. Не уложишься — считай, что задача не решена.

PD>Я ее писал на С. Наверное, неправильно делал. Расскажи, на чем надо было бы писать.
Думаю, надо писать на ассемблере. Потому как "модели" тут у предметной области нет никакой. Выполнять побайтное сравнение с константой — это ровно одна операция. Задача не в том, как эту операцию представить в более читаемом виде, а как поаккуратнее запихать данные в SSE.

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

AVK>Ну давай проведем эксперимент. Вот типовой серверный бизнес-код на универсальном языке — C#. Давай ты продемонстрируешь, как все будет круто на DSL?

Лично я — не могу показать.
1. Я не явлюясь специалистом в данной предметной области.
2.1. Я не являюсь специалистом в создании DSL.
2.2. У меня нет удобных средств написания DSL. Поэтому я с такой надеждой смотрю на N2, и желаю проекту успеха.
Пока что я пишу примерно такой же код.

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

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

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

V>Вот и не ври. И желательно читать целиком написанное. Субконто к проводке ты не добавишь только визуальными средствами, да и предприниматель запрос к отчету писал руками, он просто не понял, как с помощью конструктора отчетов воплотить свою задумку. В последствии этот предприниматель мне пару звонил — спрашивал как обновить распределенную базу — значит что-то еще дописывал сам, без чьей-либо помощи.

И какой объем кода написали твои не программисты?

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

Я освоил программирование сам по книжкам и самостоятельным попыткам написать что-то. Вот только в процессе этого я и стал программистом.

V>Почти согласен. Но лично знаю несколько человек, которые себе писали скриптовой код для бота одной онлайн игры, все они были не программистами. Про бухов я уже выше рассказал. Но таки да, 99% нифига не сделают.

Почти нет правил без исключений. Те единицы что могут освоить ЯП "рассчитанный на не программистов" просто имеют способности программистов или приобретают навыки программиста. Только и всего.

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

VD>>Идея "заставить писать код экспертов предметной области" поднималась уже не раз. Всякий раз они проваливалась. Хрестоматийный пример — SQL.
V>И еще много раз провалится, в том числе и с DSLями.

Вот именно!

VD>>Но SQL хотя бы ДСЛ. А 1Эс-ный язык — это полноценный императивный язык. Для его освоения надо стать программистом.
V>Тут всплывает другой вопрос — что значит "стать программистом"?

Научиться мыслить алгоритмически. Понять (осознать) логическое устройство компьютера. Что такое память. Как ее менять. Что такое команды компьютеру. Что такое поток управления и как с его помощью управлять командами и памятью. Короче освоение архитектуры Фон Неймана.

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

Да нельзя, нельзя! За пару месяцев можно освоить только технику. А стать программистом означает — уметь сформулировать алгоритм, уметь логически мыслить, уметь понять и устранить ошибку.

Просто есть люди с врожденными талантами и те кто имеет некоторую подготовку. Вот они и составляют этот 1% освоивших (и то кое как) программирование.

V>Я не готов спорить по поводу DSLности 1С, по нескольким причинам — я не знаю четкого и емкого определения DSL, а как показывает этот топик, оно необходимо, иначе спор похож на рассуждения дальтоников об оттенках красного, да и сам я 1с считаю императивным языком.

На самом деле твоя позиция практически идентична моей. Просто ты несколько иначе рассматриваешь факты. Ты считаешь, что одно исключение можно рассматривать как доказательство возможности. А я считаю, что это не возможность, а полное ее отсутствие. Ведь те кто говорят, что на языке Х может писать кто угодна не оговариваются о том, что этот кто угодно на самом деле не кто угодно, а всего лишь 1%, фактически, избранных.

VD>>Для того чтобы эксперт мог читать или даже править код — это код нужно выражать на крайне ограниченном, декларативно и простом ДСЛ-е. И то только отдельные эксперты смогут его понимать.
V>Существуют люди, которые пишут код и отлично разбираются в предметной области, но таких крайне мало и стоят они дорого.

Вот именно. Это потому, что человек фактически является и программистом, и еще кем-то. Т.е. совмещает два не простых знания.

Что касается терминов, то я как раз об это и говорю. Никакая терминология мешает не только популяризации ДСЛ-подхода, но и банальному рассуждению о нем.

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

V>Или взять популярный случай размерности величин. Не думаю, что для вменяемого программиста запись 42kg будет сильно отличаться от записи 42*unit.kg или unit.kg(42), тем более, что константы в коде встречаются относительно редко.

Дело не просто в записи. На DSL можно реализовать не только запись размерности величин, но и проверку на этапе компиляции, разрешена ли операция над этими величинами.

Поясню. Например, в обычном коде имеются две переменные типа double — масса и температура. Простой язык программирования никак не запретит допустим сложить две эти переменные: с точки зрения компилятор типы double можно складывать. Но с точки зрения физики массу и температуру складывать нет смысла: какая величина должна получиться?
Именно эту ситуацию способен разрулить DSL.

Конечно, нечто подобное можно реализовать в ООП: создать классы Масса и Температура, переопределить операции сложения для них. Но очевиден оверхед: для простых типов данных будет использоваться класс, что и быстродействие снизит, и память жрать будет. В случае обработки миллионов значений это критично.
А в DSL и масса и температура по-прежнему останутся после компиляции простым типом. Никакого оверхеда в рантайме!

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

T>А у меня было так — один и тот же преподаватель рассказывал про программирование и компиляторы и про ОС и много чего еще. Что странно, компиляторы в среднем давали худший выхлоп.

А у меня было так. Изучал тему самостоятельно. Сначала пытался делать это на основании курсов из институтов и приславутой книги дракона (ибо единственный брэнд). Результат был плачевным.

Потом начал изучать все на практике и читать малоизвестные научные работы. Результат в корне изменился.

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

V>>А это что?
V>>

V>> SQL является удобным и несложным средством описания сложных операций с данными.

V>>По вашему получается что с++ по сложности вообще для первоклашек, раз так.
S>Ваша ошибка — в попытке оценивать сложность в отрыве от задачи. Для описания операций с данными SQL значительно проще, чем любой GPPL, будь то си, паскаль, или жава.
S>И чем сложнее эти операции, тем сильнее рулит SQL.
Ну так в этом и дело, вы пытаетесь рассматривать только запросы в отрыве от всего остального куда входят сами базы данных, управление правами, пользователями, связи и отношения в таблицах, триггеры, процедуры и т.д. Сами запросы это вершина айсберга.

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

S>>И чем сложнее эти операции, тем сильнее рулит SQL.
V>Ну так в этом и дело, вы пытаетесь рассматривать только запросы в отрыве от всего остального куда входят сами базы данных, управление правами, пользователями, связи и отношения в таблицах, триггеры, процедуры и т.д. Сами запросы это вершина айсберга.
Нет. Запросы — это всё-таки ядро. Управление правами и пользователями — это администрирование серверов баз данных.
Но вы по-прежнему не понимаете одну главную вещь: скрипты SQL гораздо проще для управления БД, чем любые библиотеки на С++. Совершенно неважно то, что сами базы данных — это большая и сложная область. Мы сейчас не сравниваем объём предметных областей. Мы сравниваем удобство и простоту различных языков для работы в этих областях.

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

K>Лично я — не могу показать.

Воот.

K>1. Я не явлюясь специалистом в данной предметной области.
K>2.1. Я не являюсь специалистом в создании DSL.

А таких людей вообще — просто считанное количество. That's the problem.

K>2.2. У меня нет удобных средств написания DSL.

Причем тут средства? Я не прошу тебя написать парсер и анализатор DSL, я прошу показать, как DSL будет выглядеть.

K> Поэтому я с такой надеждой смотрю на N2, и желаю проекту успеха.

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

K>Пока что я пишу примерно такой же код.

Ну так покажи — какой код ты хотел бы писать.

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

Идея DSL это не отменяет.

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

Бизнесмен все равно не сможет сказать на языке DSL. Потому что DSL абсолютно формален, и именно формализация задачи составляет основную сложность общения с ним. DSL решает в другом месте проблему — перевод формальной спецификации в понятные компу инструкции. Бизнесмен там уже не участвует.

P.S. Пример я привел, чтобы продемонстрировать две важные вещи:
1) Для сочинения DSL требуется специфичная и очень высокая квалификация. Подчеркиваю, для сочинения, а не для реализации.
2) Современные ЯОН совсем не так уж и ужасны при умелом использовании.