Здравствуйте, gandjustas, Вы писали:
G>Возьми пару известных систем и покажи где там eSQL
1C 8 подойдет?
G>Покажи некривой. Только реальный, не академический.
Ну вот Парус 10 такой Реальный, не академический.
AVK>>И что? DSL как правило менее мощный, нежели сравнительно универсальный язык, каковым является SQL. G>Именно, а в чем профит?
Как обычно. В том что при решении определенного класса задач DSL значительно лучше универсального языка.
G> Если менее мощный, то надо или больше писать для достижения того же результата
Попробуй доказать.
... << RSDN@Home 1.2.0 alpha 5 rev. 27 on Windows 7 6.1.7601.65536>>
Здравствуйте, Gaperton, Вы писали:
G>>>Воспоминания, очевидно, ложные. По всем понятиям он никак не общего назначения. WH>>Ну, тогда тебе не составит труда сказать, что же там такого предметно ориентированного. G>Конечно не составит. Система типов.
Какая такая система типов? Ты о чем?
WH>>Все что я о нем помню это обыкновенный динамически типизированный, императивный язык. G>Ты о скриптовой части, которая дает ему вычислительную полноту? Да какая разница, какая она? G>Впрочем, 1С-сники специально сделали ее настолько простой, что на ней может писать бухгалтер.
Это ты про какую версию? Даже в 6-й не всякий бух мог что-то слабать. А в 7-й было что-то a-la VB6 плюс набор библиотечных OLE-объектов. Или у нас VB6 перехал в категорию DSL-ей?
WH>>Причем они умудрились сделать его медленным даже по сравнению с другими динамически типизированными языками. G>Да, это вызывает большие проблемы у уникумов, умудряющихся решать на нем диффуры. G>А у нормальных пацанов приложения все равно на 90% времени затыкаются в базу, что видно в профайлере. Несмотря на эпическую тормознутость языка.
Не знаю как сейчас, но в начале века (когда была 7.5 и 7.7, вроде как) тормоза были в разных местах. Там был тормознутый транслятор, тормоза из-за навигационного доступа к данным, тормоза из-за пессимистических блокировок для достижения "сериализуемого" уровня изоляции и убирания дедлоков. Тормоза транслятора это явная бочина их программистов, а навигационный доступ и изоляция это из-за их целевой аудитории (т.е. техническими средствами не лечится).
WH>Остается выяснить в каком месте этот язык ДСЛ? WH>Я его очень давно не видел, но по воспоминаниям это язык общего назначения.
vba — язык общего назначения? если нет, тогда 1С тоже нет. язык 1С замкнут на самой платформе, на которой решается определенный круг проблем. Все. Без дополнительных приблуд (типа подключение внешних библиотек) на нем больше ничего сделать нельзя. WH>Причем очень плохо сделанный.
Не с чем сравнивать. Я не знаю аналогов 1С. Современные версии (8.2), те что я видел, вполне годные для своих задач. Но наверняка можно сделать лучше.
Здравствуйте, WolfHound, Вы писали:
WH>По сравнению с MVVM это все очень неудобно. WH>Все эти ковыряния в ДСМ просто жуть с ружжом.
Нууу я бы так не сказал. HTML в качестве инструмента оформления вполне эффективен, т.к для того и создавался. А код на javascript с учётом современных библиотечек превращается в набор конструкций вида:
$('#element_id').click(function(){
//реакция на нажатие
});
Т.е. такой вот функциональный асинхронный стиль. Не идеал естественно, но вполне можно пользоваться...
WH>Ты зря отмахнулся от тех ссылок, что я тебе дал.
Я понял идею. Но думаю что в реализации только для web'a это не особо нужно. Вот если бы была библиотека на такой идеи для нативных контролов или что-то подобное...
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Здравствуйте, alex_public, Вы писали:
_>>Tcl как-то не очень похож на DSL. Это скорее полноценный язык. _>>Ну и результат с Тк мягко говоря сомнительный...
ANS>Почему?
Tk слабая на мой вкус. ))) А Tcl слабый по сравнению с нормальными языками и при этом всё же сильнее чем надo для GUI DSL, т.к. это полноценный скриптовой язык. В общем всё не как надо. )))
Ну и еще вдогонку, выскажу свое, возможно, бестолковое мнение по теме. Считаю нужно не просто развивать идею построения dsl языков, ведь по сути это та же идея, что и просто построение языков, просто уровень абстракции меняется от задачи к задаче. Нужно продумать некую систему взаимодействия всего этого зоопарка. Здесь же — кодогенерация, трансформация, что угодно и как угодно это можно назвать, лишь бы работало. В вебе это особенно явственно чувствуется, — никто не хочет писать по двадцать раз код на js, потом опять же эту же логику повторять на серверной стороне php/java или что там. Вот придумывают свои приблуды(gwt) и даже языки. Т.е. нужно качественно повысить продуктивность разработчика именно продуманной системой, а не просто языком, пускай это будет даже и dsl .
Здравствуйте, WolfHound, Вы писали:
WH>Смех на палочке. WH>Напиши этот код руками:
Вот смотрю я на этот пример и думаю... А означает ли факт кодогенерации обязательное наличие DSL? Например, я уже писал тут, что мы используем для создания GUI визуальный редактор, который генерирует весь код создания интерфейса неспредственно на системном языке. Т.е. кодогенерация больших объёмов у нас тут есть, а никаких DSL вроде как и не видно.
И вообще вопрос в продолжение этой мысли... Может во многих случаях как раз такое и нужно? Т.е. именно генерация кода, а не dsl?
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, Vain, Вы писали:
V>>Это не ответ, это попытка уйти от реальности. WH>Те ты тоже считаешь, что возможность написать в несколько десятков раз меньше кода и как следствие в несколько десятков раз удешевить разработку и поддержку, а так же в несколько десятков раз сократить количество ошибок это мелочи? WH>Я тебя правильно понял? WH>И что касается ухода от реальности, этим занимаешься ты. WH>Ибо у меня на руках куча фактов. WH>Которые ты пытаешься игнорировать.
А какие факты? Факты про то что многие языки общего назначения являются промышленным стандартом? Факты про то что ни один старап не будет рисковать своим проектом и как следствие кошельком чтобы проверять выстрелит ли дсл? Факты про то что существует куча уже написанного и, главное, отлаженного временем кода который никто не захочет менять на написание какого-то там дсл? Факты про то что программистов с языком общего назначения на порядок больше чем дсл писателей, что сказывается на их цене? Эти факты как раз все против дсл.
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
_>$('#element_id').click(function(){
_> //реакция на нажатие
_>});
_>
_>Т.е. такой вот функциональный асинхронный стиль. Не идеал естественно, но вполне можно пользоваться...
Проблема выделена.
Вот там и начинается жуть с ружжом.
Хотя нет. Проблемы уже начинаются вот тут $('#element_id').
Ибо идут запросы к DOM который, по сути, должен быть чистым View. Но на него оказывается, завязана логика. Это явный косяк.
Идеология MVVM состоит в том, что мы полностью отвязываем логику от представления.
ViewModel о View ничего не знает.
_>Я понял идею. Но думаю что в реализации только для web'a это не особо нужно. Вот если бы была библиотека на такой идеи для нативных контролов или что-то подобное...
Это возможно.
Но чтобы сделать действительно хороший продукт нужно много работы.
Я могу спроектировать ДСЛи. Но один не напишу. Слишком много писать. А у меня и других дел хватает.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, alex_public, Вы писали:
_>Вот смотрю я на этот пример и думаю... А означает ли факт кодогенерации обязательное наличие DSL? Например, я уже писал тут, что мы используем для создания GUI визуальный редактор, который генерирует весь код создания интерфейса неспредственно на системном языке. Т.е. кодогенерация больших объёмов у нас тут есть, а никаких DSL вроде как и не видно.
Внутри редактора живет иерархия контролов.
Это и есть ДСЛ, по которому генерируется код.
_>И вообще вопрос в продолжение этой мысли... Может во многих случаях как раз такое и нужно? Т.е. именно генерация кода, а не dsl?
Код всегда генерируется по некой модели.
Так что если есть кодогенериция то есть и язык. Не обязательно в текстовом виде.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Vain, Вы писали:
V>А какие факты?
Многократное снижение издержек вот какие.
V>Факты про то что многие языки общего назначения являются промышленным стандартом?
Миллион мух не может ошибаться.
V>Факты про то что ни один старап не будет рисковать своим проектом и как следствие кошельком чтобы проверять выстрелит ли дсл? Это вообще бред сивой кобылы.
Многие стартапы как раз и поднялись на ДСЛях.
V>Факты про то что существует куча уже написанного и, главное, отлаженного временем кода который никто не захочет менять на написание какого-то там дсл?
А то, что код рано или поздно устаревает и его, в конце концов, приходится переписывать ты конечно забыл.
V>Факты про то что программистов с языком общего назначения на порядок больше чем дсл писателей, что сказывается на их цене?
Смешной ты человек.
Вот ты на SQL пишешь?
А это ДСЛ.
ДСЛ вообще изучить очень просто.
Обычно намного проще чем библиотеку которой его пытаются заменить.
V>Эти факты как раз все против дсл.
Это не факты. Это мифы.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, BrainSlug, Вы писали:
BS>vba — язык общего назначения? если нет, тогда 1С тоже нет. язык 1С замкнут на самой платформе, на которой решается определенный круг проблем. Все. Без дополнительных приблуд (типа подключение внешних библиотек) на нем больше ничего сделать нельзя.
Если к С не подключить внешние библиотеки для работы с сервисами ОС ты на нем тоже ничего не напишешь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, BrainSlug, Вы писали:
BS>Ну и еще вдогонку, выскажу свое, возможно, бестолковое мнение по теме. Считаю нужно не просто развивать идею построения dsl языков, ведь по сути это та же идея, что и просто построение языков, просто уровень абстракции меняется от задачи к задаче. Нужно продумать некую систему взаимодействия всего этого зоопарка.
Этим и занимаюсь.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, gandjustas, Вы писали:
G>>Возьми пару известных систем и покажи где там eSQL AVK>1C 8 подойдет?
Ага, там совершенно тупая трансляция в SQL.
G>>Покажи некривой. Только реальный, не академический. AVK>Ну вот Парус 10 такой Реальный, не академический.
Ну пример приведи, я не пользуюсь парусом.
AVK>>>И что? DSL как правило менее мощный, нежели сравнительно универсальный язык, каковым является SQL. G>>Именно, а в чем профит? AVK>Как обычно. В том что при решении определенного класса задач DSL значительно лучше универсального языка.
В чем лучше? Вот на примере SQL мы видим что dsl_и над ним не лучше.
G>> Если менее мощный, то надо или больше писать для достижения того же результата AVK>Попробуй доказать.
Так ты сам сказал что
DSL как правило менее мощный, нежели сравнительно универсальный язык
Здравствуйте, WolfHound, Вы писали:
WH>Если к С не подключить внешние библиотеки для работы с сервисами ОС ты на нем тоже ничего не напишешь.
да, но можно если захотеть самим написать такие либы. или заказать у кого-то, а 1С — вещь в себе. если бы разработчики не дали возможности подключать либы (и то, там есть свои правила и ограничения как это делать, есть также возможность подключать com сервера. в винде естессно), ничего бы не вышло. Не знаю 1С для меня как-то не тянет на язык общего назначения.
Здравствуйте, WolfHound, Вы писали:
WH>Проблема выделена. WH>Вот там и начинается жуть с ружжом. WH>Хотя нет. Проблемы уже начинаются вот тут $('#element_id'). WH>Ибо идут запросы к DOM который, по сути, должен быть чистым View. Но на него оказывается, завязана логика. Это явный косяк. WH>Идеология MVVM состоит в том, что мы полностью отвязываем логику от представления. WH>ViewModel о View ничего не знает.
Я и говорю что не идеал. Но пользоваться уже вполне можно, в отличие от того, что было лет 10 назад. Функциональность браузеров тогда не сильно отличалась от современной, а вот всяческих удобных фреймворков не было, так что все писали разную жуть, кто как может. А вот последние годы, с разрабокой множества инструментов ситуация изменилась — теперь уже вполне можно можно строить приличные web-интерфейсы без особой жути внутри.
Здравствуйте, gandjustas, Вы писали:
G>>> Если менее мощный, то надо или больше писать для достижения того же результата AVK>>Попробуй доказать. G>Так ты сам сказал что G>
G>DSL как правило менее мощный, нежели сравнительно универсальный язык
Конечно он менее мощный. Они, как правило, даже не полны по Тьрингу.
Но то, что на ПОЯ (при решении задачи для который создан ПОЯ) кода будет меньше чем на ЯОН это к гадалке не ходи.
Здравствуйте, WolfHound, Вы писали:
WH>Внутри редактора живет иерархия контролов. WH>Это и есть ДСЛ, по которому генерируется код.
Более того, у него даже есть свой отдельный формат для хранения "нарисованного" gui. Я в него как-то заглянул ради интереса — там некий дичайший xml. Так что формально можно даже текстовый dsl найти тут. Но речь то не об этом... Речь о том, что если поменять этот формат на любой другой (бинарный например), то абсолютно ничего в процессе разработки не изменится — люди никогда не видят его. Так можем ли мы называть это DSL, если люди с этим не работают никогда и от его реализации не зависит вообще ничего?
WH>Код всегда генерируется по некой модели. WH>Так что если есть кодогенериция то есть и язык. Не обязательно в текстовом виде.
Ну в данном случае, в смысле логики, модель задаётся иерархией классов фреймворка. Элементы которой мы двигаем мышкой в редакторе.
Здравствуйте, Буравчик, Вы писали:
Б>Одна из них — взаимодействие между языками. Как передавать данные из одного языка в другой? Взять ту же связку "язык общего назначения (ЯОН) — SQL". Сколько напридумывали вариантов передачи данных из ЯОН в SQL — и в компилятор встраивали, и формировали текст SQL в программе и передача параметров в хранимые процедуры. Аналогично и с превращением данных из SQL в данные ЯОН — всякие ридеры, датасеты и т.п. В итоге удобным вариантом оказался что-то типа LINQ, т.е. с одной стороны DSL, а работа все в том же ЯОН. Т.е. по сути получилась та же библиотека.
Взаимодействие между языками, унаследованным кодом и сторонними библиотеками — это те камни, на которых споткнулся Model Driven Development в целом и DSL-и в частности. Решать их лучше не созданием каких-то формальных стандартов обмена информации между языками а прагматичным подходом: к примеру, создание C API для DSL-я.
Помимо этого, есть еще такая вещь как дебаг кода. К DSL неплохо было бы прикладывать и DSL-specific debugger. Но это приводит к своим специфичным проблемам.
Реальный, не академический.
