Здравствуйте, alex_public, Вы писали:
_>Более того, у него даже есть свой отдельный формат для хранения "нарисованного" gui. Я в него как-то заглянул ради интереса — там некий дичайший xml. Так что формально можно даже текстовый dsl найти тут. Но речь то не об этом... Речь о том, что если поменять этот формат на любой другой (бинарный например), то абсолютно ничего в процессе разработки не изменится — люди никогда не видят его. Так можем ли мы называть это DSL, если люди с этим не работают никогда и от его реализации не зависит вообще ничего?
Они работают с его графическим представлением.
Графические ДСЛ с моей точки зрения очень сомнительны. Но их сомнительность не отменяет того что они ДСЛ.
Лично я считаю, что текстовый ДСЛ с превьюшкой обновляющейся в реальном времени был бы лучше.
Вот смотри:
Если сделать 3 окошка.
В одном ViewModel синхронизируемая в обе стороны с превьюшкой.
В другом превьюшка в которой можно нажимать кнопки и редактировать текст. И в это время будет меняться состояние ViewModel в соседнем окне.
В третьем маппинг ViewModel на контролы. Меняя который превьюшка автоматически перестраивается. При этом все данные остаются в ViewModel.
Плюс возможность сохранить несколько состояний ViewModel. Для того чтобы можно было быстро переключаться между ними и смотреть как ведет себя ГУИ.
Думаю это было бы весьма круто.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали:
_>Вот смотрю я на этот пример и думаю... А означает ли факт кодогенерации обязательное наличие DSL? Например, я уже писал тут, что мы используем для создания GUI визуальный редактор, который генерирует весь код создания интерфейса
DSL бывают и графическими.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
Здравствуйте, BrainSlug, Вы писали:
BS>Ну и еще вдогонку, выскажу свое, возможно, бестолковое мнение по теме. Считаю нужно не просто развивать идею построения dsl языков, ведь по сути это та же идея, что и просто построение языков, просто уровень абстракции меняется от задачи к задаче. Нужно продумать некую систему взаимодействия всего этого зоопарка. Здесь же — кодогенерация, трансформация, что угодно и как угодно это можно назвать, лишь бы работало. В вебе это особенно явственно чувствуется, — никто не хочет писать по двадцать раз код на js, потом опять же эту же логику повторять на серверной стороне php/java или что там. Вот придумывают свои приблуды(gwt) и даже языки. Т.е. нужно качественно повысить продуктивность разработчика именно продуманной системой, а не просто языком, пускай это будет даже и dsl .
Когда разрабатывался Smalltalk, то до St-80 были и St-72 и St-74 и St-76 и St-78. Особенностью ранних систем St было, окромя ассинхронности, еще и то, что грамматику протокола задавал сам объект-получатель. На практике, получалась каша и всё свелось к унифицированной грамматике в St-80. При этом, проблема была не в примитивном способе разбора потока сообщений, а именно в разных грамматиках в одной программе, в сложности прочтения получившейся программы.
Это не отменяет пользы DSL, но и мульёнами в одной системе они вряд-ли будут появляться.
Здравствуйте, alex_public, Вы писали:
_>>>Tcl как-то не очень похож на DSL. Это скорее полноценный язык. _>>>Ну и результат с Тк мягко говоря сомнительный...
ANS>>Почему?
_>Tk слабая на мой вкус. ))) А Tcl слабый по сравнению с нормальными языками и при этом всё же сильнее чем надo для GUI DSL, т.к. это полноценный скриптовой язык. В общем всё не как надо. )))
Здравствуйте, Andrei N.Sobchuck, Вы писали:
G>>>>Воспоминания, очевидно, ложные. По всем понятиям он никак не общего назначения. WH>>>Ну, тогда тебе не составит труда сказать, что же там такого предметно ориентированного. G>>Конечно не составит. Система типов.
ANS>Какая такая система типов? Ты о чем?
Это я о регистрах, справочниках, документах, планах счетов... Это типы данных, со сложным поведением и сильной заточкой на предметную область.
WH>>>Все что я о нем помню это обыкновенный динамически типизированный, императивный язык. G>>Ты о скриптовой части, которая дает ему вычислительную полноту? Да какая разница, какая она? G>>Впрочем, 1С-сники специально сделали ее настолько простой, что на ней может писать бухгалтер.
ANS>Это ты про какую версию? Даже в 6-й не всякий бух мог что-то слабать. А в 7-й было что-то a-la VB6 плюс набор библиотечных OLE-объектов. Или у нас VB6 перехал в категорию DSL-ей?
Это я про design goals языка 7-рки, со слов Сергея Нуралиева. Любого "буха", который обучался в университете основам программирования, можно обучить написать разнесение проводок, или вносить туда простые правки.
Разумеется, "бух" не станет от этого уберпрофессионалом, способным написать на 1С все возможное и невозможное. И что? Тебе очень сильно придраться хочется, но не знаешь к чему?
WH>>>Причем они умудрились сделать его медленным даже по сравнению с другими динамически типизированными языками. G>>Да, это вызывает большие проблемы у уникумов, умудряющихся решать на нем диффуры. G>>А у нормальных пацанов приложения все равно на 90% времени затыкаются в базу, что видно в профайлере. Несмотря на эпическую тормознутость языка.
ANS>Не знаю как сейчас, но в начале века (когда была 7.5 и 7.7, вроде как) тормоза были в разных местах.
Давай, рассказывай мне. Я на 7.5 и 7.7 "в конце века" сделал несколько десятков проектов. Некоторые из них были на пике возможностей платформы по тогдашним временам (к примеру, мы первыми сделали полноценное управление производством). И вот ни разу почему-то не утыкался в тормоза интерпретатора. Все время в базу.
И я скажу по поводу 1С так. При правильном применении она приводит к экономии затрат на разработку, в сравнении с языками общего назначения, от 2-х до 10 раз. И это многократно проверенный факт — трудно не заметить, что ты систематически выигрываешь у самоделкиных тендера, и быстрее нарезаешь бабки. Что, со временем, и привело к почти абсолютному доминированию 1С для малых-средних предприятий сейчас.
Когда оно по практике так — можно урассуждаться о том, насколько это плохой DSL. Плохому танцору всегда яйца мешают — он сильных сторон технологий видеть просто не умеет, и потому полагается на слабые. И тут у него и начинается "в разных местах".
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS> А в 7-й было что-то a-la VB6 плюс набор библиотечных OLE-объектов. Или у нас VB6 перехал в категорию DSL-ей?
И чтобы внести ясность. А то ты как я вижу не в курсе.
В 7-ке никогда не было "библиотечных OLE-шных объектов". Единственный COM интерфейс, который она выставляла — это кривое подобие IDispatch, предназначенное для внешних приложений.
Ее язык никогда не был похож на VB6. Если искать, на что он больше похож — это подмножество JS c опаскаленым синтаксисом, переведенный на русский язык. Нет, это совсем не то же самое, что VB6.
А "в категории DSL" у нас находится не VB6, а Visual Basic for Applications, который туда не "переехал", а изначально использовался в качестве основы DSL в майкрософтских офисных продуктах.
Здравствуйте, Vain, Вы писали:
V>Здравствуйте, WolfHound, Вы писали:
WH>>Здравствуйте, Vain, Вы писали:
V>А какие факты? Факты про то что многие языки общего назначения являются промышленным стандартом? Факты про то что ни один старап не будет рисковать своим проектом и как следствие кошельком чтобы проверять выстрелит ли дсл?
И как тут не вспомнить "Beating the Averages" Грэма.
The average big company grows at about ten percent a year. So if you're running a big company and you do everything the way the average big company does it, you can expect to do as well as the average big company-- that is, to grow about ten percent a year.
The same thing will happen if you're running a startup, of course. If you do everything the way the average startup does it, you should expect average performance. The problem here is, average performance means that you'll go out of business. The survival rate for startups is way less than fifty percent. So if you're running a startup, you had better be doing something odd. If not, you're in trouble.
G>И чтобы внести ясность. А то ты как я вижу не в курсе. G>В 7-ке никогда не было "библиотечных OLE-шных объектов". Единственный COM интерфейс, который она выставляла — это кривое подобие IDispatch, предназначенное для внешних приложений.
Это не важно. Ты б еще придрался к тому, что, в отличии от VB, в 1C ключевые слова — русские.
G>Ее язык никогда не был похож на VB6. Если искать, на что он больше похож — это подмножество JS c опаскаленым синтаксисом, переведенный на русский язык. Нет, это совсем не то же самое, что VB6. G>А "в категории DSL" у нас находится не VB6, а Visual Basic for Applications, который туда не "переехал", а изначально использовался в качестве основы DSL в майкрософтских офисных продуктах.
Языки для скриптования прикручиваются ко многим системам. Но, по какой-то загадочной причине, они всегда называются скриптовыми языками, а не DSL.
Здравствуйте, Gaperton, Вы писали:
G>>>>>Воспоминания, очевидно, ложные. По всем понятиям он никак не общего назначения. WH>>>>Ну, тогда тебе не составит труда сказать, что же там такого предметно ориентированного. G>>>Конечно не составит. Система типов. ANS>>Какая такая система типов? Ты о чем? G>Это я о регистрах, справочниках, документах, планах счетов... Это типы данных, со сложным поведением и сильной заточкой на предметную область.
О. Если каждую объектную систему называть DSL, то получится, что каждая программа на ООП языке состоит из множества DSL. Но нормальные люди называют это классами и пакетами.
G>>>Впрочем, 1С-сники специально сделали ее настолько простой, что на ней может писать бухгалтер. ANS>>Это ты про какую версию? Даже в 6-й не всякий бух мог что-то слабать. А в 7-й было что-то a-la VB6 плюс набор библиотечных OLE-объектов. Или у нас VB6 перехал в категорию DSL-ей? G>Это я про design goals языка 7-рки, со слов Сергея Нуралиева. Любого "буха", который обучался в университете основам программирования, можно обучить написать разнесение проводок, или вносить туда простые правки.
"Сделали" и "design goals" это разные вещи. И, замечу, design goal этот не достигнут. Ибо редкий бух освоит язык общего назначения.
G>Давай, рассказывай мне. Я на 7.5 и 7.7 "в конце века" сделал несколько десятков проектов. Некоторые из них были на пике возможностей платформы по тогдашним временам (к примеру, мы первыми сделали полноценное управление производством). И вот ни разу почему-то не утыкался в тормоза интерпретатора. Все время в базу.
Контеншен на глобальном локе это не "тормоза базы".
G>Когда оно по практике так — можно урассуждаться о том, насколько это плохой DSL. Плохому танцору всегда яйца мешают — он сильных сторон технологий видеть просто не умеет, и потому полагается на слабые. И тут у него и начинается "в разных местах".
О, коммерческий успех стал выступать мерилом степени DSL-ности. Ты не перерабатывай так много.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>Какая такая система типов? Ты о чем? G>>Это я о регистрах, справочниках, документах, планах счетов... Это типы данных, со сложным поведением и сильной заточкой на предметную область.
ANS>О. Если каждую объектную систему называть DSL, то получится, что каждая программа на ООП языке состоит из множества DSL. Но нормальные люди называют это классами и пакетами.
А. Но только в языке 1С нет ни "классов", ни "пакетов". И ничего похожего на эти вещи. Зато там есть, например, довольно интересный язык запросов по бизнес-объектам, лежащим в базе, которые кажутся тебе классами и пакетами.
В связи с этим, я плохо понимаю, с чего это ты записал себя в "нормальные люди". Нормальные люди называют вещи своими именами, а не чем попало. И нормальные люди не спорят на темы, в которых ничерта не разбираются.
Здравствуйте, Gaperton, Вы писали:
G>Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>>>>Какая такая система типов? Ты о чем? G>>>Это я о регистрах, справочниках, документах, планах счетов... Это типы данных, со сложным поведением и сильной заточкой на предметную область. ANS>>О. Если каждую объектную систему называть DSL, то получится, что каждая программа на ООП языке состоит из множества DSL. Но нормальные люди называют это классами и пакетами. G>А. Но только в языке 1С нет ни "классов", ни "пакетов". И ничего похожего на эти вещи. Зато там есть, например, довольно интересный язык запросов по бизнес-объектам, лежащим в базе, которые кажутся тебе классами и пакетами.
Наличие среди всего прочего "довольно интересного язык запросов" (читай "абсолютно идиотского") не делает весь язык "DSL".
G>В связи с этим, я плохо понимаю, с чего это ты записал себя в "нормальные люди". Нормальные люди называют вещи своими именами, а не чем попало. И нормальные люди не спорят на темы, в которых ничерта не разбираются.
Т.е. ты уже осознал, что ошибся записав язык 1С в DSL, и решил просто повилять хвостиком неся чушь?
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Наличие среди всего прочего "довольно интересного язык запросов" (читай "абсолютно идиотского") не делает весь язык "DSL".
Здравствуйте, gandjustas, Вы писали:
AVK>>1C 8 подойдет? G>Ага, там совершенно тупая трансляция в SQL.
Ну да, обозвал тупым и все понятно. Запрос там строится в терминах одноэсных документов, проводок и т.п. И результат тоже возвращается ввиде объектов 1С.
AVK>>Ну вот Парус 10 такой Реальный, не академический. G>Ну пример приведи, я не пользуюсь парусом.
Ну вот что в тестах, к примеру, валяется:
Запрос:
USING Mock;
SELECT
bc2.BoolAttr AS ba,
bc2.BizClass1Link.IntAttr AS ia,
sq.Identity.BoolAttr,
jbc2l.BizClass1Link.IntAttr AS lia,
jbc2r.BizClass1Link.IntAttr AS ria,
sq.Identity.BizClass1Link.IntAttr AS tjia
FROM
BizClass2 bc2,
(SELECT Identity FROM BizClass2) AS sq,
BizClass2 AS jbc2l JOIN BizClass2 AS jbc2r ON jbc2l.BizClass1Link = jbc2r.BizClass1Link;
В сиквел в итоге отдаеться такое:
SELECT
[bc2].BoolAttr AS ba,
[__join_0].IntAttr AS ia,
[__join_1].BoolAttr AS BoolAttr,
[__join_2].IntAttr AS lia,
[__join_3].IntAttr AS ria,
[__join_4].IntAttr AS tjia
FROM
[MockSchema].[Tbl-Mock.BizClass2] AS [bc2]
/*implicit*/LEFT OUTER JOIN [MockSchema].[Tbl-Mock.BizClass1] AS [__join_0] ON (([__join_0].id = [bc2].LinkTo_BizClass1Link_id) AND ([__join_0].tid = [bc2].LinkTo_BizClass1Link_tid)),
(
SELECT
[MockSchema].[Tbl-Mock.BizClass2].id AS Identity,
[MockSchema].[Tbl-Mock.BizClass2].tid AS Identity_Type
FROM
[MockSchema].[Tbl-Mock.BizClass2]
) AS [sq]
/*implicit*/LEFT OUTER JOIN [MockSchema].[Tbl-Mock.BizClass2] AS [__join_1] ON (([__join_1].id = [sq].Identity) AND ([__join_1].tid = [sq].Identity_Type))
/*implicit*/LEFT OUTER JOIN [MockSchema].[Tbl-Mock.BizClass1] AS [__join_4] ON (([__join_4].id = [__join_1].LinkTo_BizClass1Link_id) AND ([__join_4].tid = [__join_1].LinkTo_BizClass1Link_tid)),
[MockSchema].[Tbl-Mock.BizClass2] AS [jbc2l]
/*implicit*/LEFT OUTER JOIN [MockSchema].[Tbl-Mock.BizClass1] AS [__join_2] ON (([__join_2].id = [jbc2l].LinkTo_BizClass1Link_id) AND ([__join_2].tid = [jbc2l].LinkTo_BizClass1Link_tid))
INNER JOIN [MockSchema].[Tbl-Mock.BizClass2] AS [jbc2r]
/*implicit*/LEFT OUTER JOIN [MockSchema].[Tbl-Mock.BizClass1] AS [__join_3] ON (([__join_3].id = [jbc2r].LinkTo_BizClass1Link_id) AND ([__join_3].tid = [jbc2r].LinkTo_BizClass1Link_tid)) ON (([jbc2l].LinkTo_BizClass1Link_id = [jbc2r].LinkTo_BizClass1Link_id) AND ([jbc2l].LinkTo_BizClass1Link_tid = [jbc2r].LinkTo_BizClass1Link_tid))
AVK>>Как обычно. В том что при решении определенного класса задач DSL значительно лучше универсального языка. G>В чем лучше?
Во всем.
G> Вот на примере SQL мы видим что dsl_и над ним не лучше.
Это где ты такое увидел?
G>>> Если менее мощный, то надо или больше писать для достижения того же результата AVK>>Попробуй доказать. G>Так ты сам сказал что
G>
G>DSL как правило менее мощный, нежели сравнительно универсальный язык
Доказать, что менее мощный язык означает, что для достижения того же результата надо больше писать.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
Здравствуйте, Gaperton, Вы писали:
G>И я скажу по поводу 1С так. При правильном применении она приводит к экономии затрат на разработку, в сравнении с языками общего назначения, от 2-х до 10 раз. И это многократно проверенный факт — трудно не заметить, что ты систематически выигрываешь у самоделкиных тендера, и быстрее нарезаешь бабки.
Осталось только выяснить: благодаря чему это происходит. Благодаря DSL, или благодаря тому, что в случае с 1C 80% необходимого функционала уже реализовано "из коробки"?
Здравствуйте, WolfHound, Вы писали:
WH>56 страниц сильно оптимизированного кода на жабе (год разработки) против 17 строк на ДСЛ (год разработки компилятора).
Хреновый как-ой то DSL. Можно было бы сделать DSL в 17 раз круче, который будет решать задачу в одну строчку. Пример того, как надо делать нормальные DSL можно посмотреть тут
Здравствуйте, mrTwister, Вы писали:
G>>И я скажу по поводу 1С так. При правильном применении она приводит к экономии затрат на разработку, в сравнении с языками общего назначения, от 2-х до 10 раз. И это многократно проверенный факт — трудно не заметить, что ты систематически выигрываешь у самоделкиных тендера, и быстрее нарезаешь бабки.
T>Осталось только выяснить: благодаря чему это происходит. Благодаря DSL, или благодаря тому, что в случае с 1C 80% необходимого функционала уже реализовано "из коробки"?
Благодаря DSL, а говоря конкретно — лежащей в его основе модели справочник-документ-отчет. Случаи внедрения готовых конфигураций я вообще не считаю.
Кстати, о типовых конфах, в которых у нас "80% необходимого функционала" (для отраслевых решений это не так, и их часто пишут с нуля, но неважно). Рассмотрим подробнее, это показательно.
Объем "глобального модуля" 1С Оперативный учет 7.5 составлял порядка 4000 (четырех тысяч) строк кода.
А объем "глобального модуля" 1С Бухгалтерии 7.5 составлял порядка 2000 (двух тысяч) строк кода.
Отношение бизнес-логики к прочему коду в системах на 1С очень высоко, примерно 9 к 1. Выигрышь образуется за счет того, что ты проектируешь сразу в терминах справочник-документ-отчет (это сильно отличается от ООП и баз данных, за этим стоит определенная методология), и, по сути, не пишешь ничего кроме бизнес-логики. То есть, не делаешь лишней работы.
Многие сервисы тебе вообще даются почти бесплатно. Например, синхронизация баз в распределенных офисах еще в семерке делались легким мановением руки и компонентой за 500 баксов.
За это ты, естественно, расплачиваешься очень много чем, например, сильными ограничениями по организации GUI твоего приложения (он жестко привязан к тому, что можно с некоторой натяжкой назвать "схемой БД"). Часто результат того стоит. А бывает, что нет.
Здравствуйте, gandjustas, Вы писали:
WH>>Когда этим кто-нибудь займется. Твой КО. G>Так почему до сих пор не занялись? Бинес-задачи меняются мало, а кроме SQL пока ниче не придумано. G>В чем проблема?
Почему не придумали? Придумали и массу. Проблема только в том, что:
* Для большинства задач написание DSL, с использованием "лопаты", не закончится к сроку завершения проекта.
* Для большинства задач требуется в разы меньшая квалификация, тем для разработки DSL, с использованием "лопаты".
WH>>Просто его плохо спроектировали. G>Почему?
Потому что проектировали не под конкретную задачу, а на все случаи жизни.
WH>>Но ответь на вопрос: Променяешь его на прямые запросы по физической структуре БД? G>Это технически невозможно, сервер на другом компе стоит, порты закрыты.
Что-то ты гонишь. Вы СУБД не используете? Или SQL не применяете?
Он тебя спрашивает — станешь ли ты лезть в БД вручную (использовать ISAM), при наличии скуля?
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, Gaperton, Вы писали:
G>В 7-ке никогда не было "библиотечных OLE-шных объектов". Единственный COM интерфейс, который она выставляла — это кривое подобие IDispatch, предназначенное для внешних приложений.
Внутри там тоже IDispatch, хоть и вычурный. Только вот это совершенно пофигу, это детали реализации.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
Да какая разница, какая она?
