Здравствуйте, oldjackal, Вы писали:
O>Здравствуйте, gandjustas, Вы писали:
G>>В бизнесе чуть ли не все задачи типовые, но вот dsl для них не придумали. G>>Когда будут?
O>1С и тому подобные.
1С по сути тоже ЯОН. Только в замкнутой экосистеме.
Решает задачи не только учета, а потенциально любые.
G>>DSL еще написать надо, это сложно. O> Намного проще, чем хорошую библиотеку с удобным API.
Покажи на примере. Рад буду такое использовать.
Здравствуйте, alex_public, Вы писали:
PSV>>Он используется в моей личной практике, но всё "программирование" происходит на бумаге с карандашом — язык очень простой, основная фишка: направленный граф без пересекающихся линий — это реально намного лучше того, что рисовалось до него не пойми как для своих всяких схем. Люди въезжают быстро, даже те, кто далёк от программирования и всяких блок-схем, быстро можно начать обсуждать предметную область на одном языке.
_>Используется где-то помимо его основного назначения? Интересно.
PSV>>Рекомендую.
_>Хы, ну только для самообразования. Не вижу где его особо можно применить на практике. В смысле у нас, а не вообще в мире. )))
Нет, ты не понял. Мы у себя ДРАКОН используем не для программирования, в классическом понимании. Там, где его изобрели, была реальная в нём потребность и используется он там по своему естественному назначению. В их звездолётах специфичное оборудование, управляется своеобразными командами по мудрённым принципам, на ассебмлер не похоже. Инженеры понимают внутреннее устройство и логику работы железа, но не могут программировать, а программистам эта прикладная сфера даётся крайне тяжело. Решили, пусть инженеры сами лепят себе привычные им чертежи, т.е. эти ДРАКОН-схемы, где всё на прямую расписывается алгоритм в рамках конкретных машинных команд. Дальше схемы куда-то транслируется и т.д.
Вокруг ДРАКОНа понапридумывали всяких трансляторов из схем в языки С, Pascal и т.д. Имхо, это только для учебных и образовательных процессов.
Мы же используем схемы для проектирования, набросков для алгоритмов, задач и т.д., когда нужно в чём-то разобраться, уяснить, обсудить с кем-то. Т.е. вместо традиционных программистких блок-схем, которые рисовались раньше кто как хотел: всякие прямоугольники со стрелками туда-сюда, в которых можешь сам потом хрен разобраться. В ДРАКОНе простой и удобный принцип: граф с направлением по линиям, которые не должны пересекаться. Всё, от ДРАКОНа больше ничего не нужно (нам, во всяком случае). Соединяешь прямоугольники (плюс что-то другое) со своим смыслом (в том числе, и как переходы к другим схемам — декомпозиция) линиями по правилам ДРАКОНа — получи реально простую и понятную всем схему. Можно с людьми, из прикладной области, говорить об одном и том же, все друг друга понимают без лишних слов.
В этом вся сила и гениальность, такое в жизни встречается редко. Это что-то вроде "графического лиспа".
Здравствуйте, VladD2, Вы писали:
G>>Ты о скриптовой части, которая дает ему вычислительную полноту? Да какая разница, какая она?
VD>Разница в том, что язык имеющий вычислительную полноту по тьюрингу и позволяющий писать код не через зад (как, например, SQL с рекурсивными расширениями) и является языком общего назначения.
Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.
Еще один пример из обыденной практики — использование LUA для написания скриптов AI в играх. Их пишут не программисты. Это для них в игровую платформу внедряют LUA. Цель — исключить необходимость затратного общения между гейм-аналитиками и программистами при реализации AI, пусть аналитики справляются сами.
Поэтому, все действительно практически успешные DSL на текущий момент имеют в качестве базы простейшие языки, с семантикой не сложнее раннего бейсика. 1С только один из немногих примеров.
Еще примеры? Системы компьютерной алгебры. Maltab. Maple. Автокад, который перешел с автолиспа на VBA. Язык TradingStation для описания торговых роботов.
И это закономерно, что базовая семантика этих языков тупа до безобразия. Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.
Влад, ты в каком-то своем странном мире живешь, реально.
VD>1Эс — это ЯОН + среда ориентированная на бизнес-задачи. Того же самого можно было бы добиться создав библиотеки и внешние утилиты для явы или дотнета.
Не думал, что когда-либо это скажу. Но. "Сперва добейся" (с)
Здравствуйте, Sinclair, Вы писали:
WH>>>Ну, давай изучи АПИ для прямых обращений к физической структуре БД. V>>А в чём проблема? MFC, ADO, DAO? S>Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД".
А вы объясните зачем?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, oldjackal, Вы писали:
O>Вы очень неудачно пример выбрали. В любой CAS эта задача решается именно через правила переписывания, причем крайне простые: факторизация выражения ( раскрытие скобок) и подстановка коэффициентов в готовую формулу. O>Не понял, вы вообще о чем?
А вы о чём? Я вообще первый раз слышу, чтоб семантику (не грамматику, а именно семантику) сводили к "правилам переписывания".
Можно где-нибудь пример таких "правил переписывания" увидеть?
Здравствуйте, Vain, Вы писали:
S>>Боюсь, ни один из них тебе не даст возможности напрямую читать/писать странички БД и расставлять локи разных уровней. А именно это и есть прямое обращение "к физической структуре БД". V>А вы объясните зачем?
Как зачем? Чтобы выполнять задачи управления данными в БД. Перечисленные вами аббревиатуры — это не замена SQL, а всего лишь библиотеки для использования того же самого SQL.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Ну так я про то и говорю, что кругом просто "размётка". И в этом случае я невижу никакого смысла для отдельного языка под это — проще сразу генерировать в редакторе готовый код на системном языке.
Странно. Вот вы не видите смысла, тем не менее даже ваша система использует этот отдельный язык. Как так?
_>А вот если бы у нас в gui dsl можно было бы задавать хотя бы минимальные действия... Весь значительная часть обработчиков замкнута самая же на себя. Т.е. зачем обращаться в мощный основной язык ради того что бы в обработчики команды меню вызвать команду "показать диалог такой-то". И таких вызовов очень много! Значительная часть обработчиков состоит из вызова одной строки — вызова функции другого gui контрола. Это всё можно было замкнуть внутри себя, сделав вызовы наружу (в системный язык) только уже для реальной функциональности. Вот на такой dsl я бы точно перешёл. Но таких gui фреймворков я не знаю вообще.
Это интересная идея. У меня есть некоторые подозрения о причинах отсутствия таких DSL, но я в них совершенно не уверен.
Если хотите, можем пообсуждать возможности и трудности, связанные с созданием такого DSL.
_>А с текущей ситуацией "просто размётки с указанием имён обработчиков" и при наличие визуального редактора у меня на такие dsl действует только бритва Оккама.
Это не бритва Оккама — это шоры. Т.е. языки есть, вы ими пользуетесь, но отказываетесь их видеть.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, alex_public, Вы писали:
_>Как раз в данном случае проблем быть не должно — автоконвертер справится легко. Это же именно язык для программы, а не для человека, поэтому там никакого произвола.
Это отличительная черта всех DSL, спроектированных для машинного чтения/записи. Интересно рассматривать языки двойного назначения, которые облегчают roundtrip между правкой "в визуальном редакторе" и "в текстовом режиме".
S>>То, что он у вас внутри какой-то некрасивый, как раз неважно. Важно, что он есть. Вы можете приделать к нему произвольное представление. Визуальное у вас уже есть. Можете приделать текстовое, и получите много замечательных бенефитов.
_>Оно кстати и есть текстовое сейчас. Только не реальное для редактированием человеком. Ну т.е. в теории конечно возможно, но на практике бред. )))
Никакого бреда. Представьте себе, что у вас два девелопера чинят два бага. Один увеличивает ширину кнопки submit, потому что в мадагаскарской локализации не влезла надпись, а другой меняет порядок табов на экране.
Теперь у них конфликт обновлений, и нужно выполнить слияние изменений. Если формат текстовый, но содержит произвольно изменяемые фрагменты типа автогенерённых идентификаторов объектов (см. например файлы Rational Rose), или вообще не дай байт бинарный, то это слияние будет делать крайне неудобно. (Ну, разве что вы разработаете свой специальный инструмент для этого, типа как в Microsoft Word). А если ваш язык проектировался как человекочитаемый, то с большой вероятностью существующие инструменты прекрасно подойдут. Разработчику будет совершенно очевидна суть сделанных изменений.
Не нужно думать, что эта задача требует каких-то сверхъестественных усилий. Посмотрите на то, как выглядят DFM-файлы в текстовом режиме. А ведь они пригодны для описания более-менее произвольной разметки контролов, в том числе и расширяемой.
_>Тут основной поинт был не в том что мышкой. А в том что мы по сути пользуемся DSL но при этом никто не продумывал для него синтаксис и т.п. не самые тривиальные детали.
Ну как это не продумывал? Конечно же продумывали. Вот этот ваш "визуальный синтаксис" — он же существует! Как-то показаны взаимоотношения контролов — иерархия, сцеплённость, размеры, и другие характерные вещи, которые вы редактируете. То, что вы не выделяли отельную фазу "разработка синтаксиса языка", ничего не значит. По факту он есть, пусть и в виде результата множества мелких решений.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, Gaperton, Вы писали:
G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.
[...]
G>Поэтому, все действительно практически успешные DSL на текущий момент имеют в качестве базы простейшие языки, с семантикой не сложнее раннего бейсика.
Вот тут — +100 под всем написанным.
Добавлю только, что само понятие "языка" с чёткими требованиями к синтаксису может быть чрезмерным для тех, кто пишет на DSL. Поэтому вопроса развиваются графические представления — для тех случаев, где они достаточны, и в них соблюдение синтаксических норм достигается само собой.
Здравствуйте, Wolverrum, Вы писали:
W>То-то же N так и не разродился промышленным компилятором...
Так это по тому, что при его реализации не использованы ДСЛ.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Gaperton, Вы писали:
G>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак.
Феерическая глупость.
Если программист не дурак, то это совершенно не означает что он должен писать в 10-100 раз больше кода, чем нужно для решения задачи.
G>И это закономерно, что базовая семантика этих языков тупа до безобразия. Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.
Да правда что ли? SQL сплошной матан. YACC, ANTLR и тп тоже один сплошной матан.
G>Не думал, что когда-либо это скажу. Но. "Сперва добейся" (с)
А что тут думать то?
Технических аргументов у тебя нет.
Одна демагогия.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, oldjackal, Вы писали:
O>Писать компиляторы и интерпретаторы намного проще чем принято думать. Это же тупая, формализованная и давно решенная задача. Мозгов не требует.
Честно говоря, современные наработки весьма кривы. Но я работаю над выпрямлением. https://github.com/rampelstinskin/ParserGenerator
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
G>>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак. WH>Феерическая глупость. WH>Если программист не дурак, то это совершенно не означает что он должен писать в 10-100 раз больше кода, чем нужно для решения задачи.
Ты случайно или намеренно не заметил, что речь идёт о DSL не для профессионального программиста, а для обычного пользователя с зачатками способностей к автоматизации?
G>>И это закономерно, что базовая семантика этих языков тупа до безобразия. Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны. WH>Да правда что ли? SQL сплошной матан.
Формулировку "выбрать среди всех записей те, у которых тип Z" способен освоить много кто, но опять-таки речь не о тех языках.
WH> YACC, ANTLR и тп тоже один сплошной матан.
Адаптаторы и power users не пишут на Yacc.
G>>Не думал, что когда-либо это скажу. Но. "Сперва добейся" (с) WH>А что тут думать то? WH>Технических аргументов у тебя нет. WH>Одна демагогия.
Нет, это ты не умеешь читать и пропускаешь ключевые слова.
Если бы ты умел читать, ты бы начал возражать на совсем другие места из того сообщения.
Здравствуйте, netch80, Вы писали:
G>>>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак. N>Ты случайно или намеренно не заметил, что речь идёт о DSL не для профессионального программиста, а для обычного пользователя с зачатками способностей к автоматизации?
Ты прочитай, что Gaperton написал.
Он прямым текстом заявляет, что программистам ДСЛ не нужны. Они типа и так умные.
N>Формулировку "выбрать среди всех записей те, у которых тип Z" способен освоить много кто, но опять-таки речь не о тех языках.
О тех самых. Опять же читай то, что пишет Gaperton внимательно.
А пишет он бред.
Про DSL, в основе которых матан, мы просто не знаем, по вполне понятной причине — они нехрен никому не нужны.
В основе SQL матан. Реляционная алгебра называется.
А то, что матан вдруг оказался простым в использовании это не удивительно.
Его для того и придумывают. Чтобы сложные вещи можно было записывать относительно простым способом.
WH>> YACC, ANTLR и тп тоже один сплошной матан. N>Адаптаторы и power users не пишут на Yacc.
Чего?
N>Если бы ты умел читать, ты бы начал возражать на совсем другие места из того сообщения.
Да правда что ли?
На что тут можно возразить?
Все что можно сделать, это указать на бред.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Это интересная идея. У меня есть некоторые подозрения о причинах отсутствия таких DSL, но я в них совершенно не уверен. S>Если хотите, можем пообсуждать возможности и трудности, связанные с созданием такого DSL.
Хотим.
Мой вариант такого ДСЛ основан на MVVM.
Model это произвольный код, не имеющий к ГУИ отношения.
ViewModel основана на реактивном программировании. Те если внутри ViewModel что-то изменилось, то все что на основе этого было вычислено также автоматические пересчитывается.
View это маппинг ViewModel на контролы. Благодаря реактивности при любом изменении ViewModel View автоматически пересчитывается. Также View может менять ViewModel при помощи биндинга свойств контролов на свойства ViewModel.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
G>>>>Сама цель создания DSL подразумевает, что для решения задач через него должна требоваться квалификация, на порядок меньшая, чем обычного программиста. Ибо программист справится и с обычным языком общего назначения. Ибо не дурак. N>>Ты случайно или намеренно не заметил, что речь идёт о DSL не для профессионального программиста, а для обычного пользователя с зачатками способностей к автоматизации? WH>Ты прочитай, что Gaperton написал. WH>Он прямым текстом заявляет, что программистам ДСЛ не нужны. Они типа и так умные.
Вот с этим и надо было спорить, а не с последствиями для очевидно другого предназначения — DSL для пользователей.
WH>А пишет он бред.
Нет, это ты не можешь отличить разговор в разных контекстах. Вообще напоминаешь героя одной истории:
Разговариваю с приятелем, который занимается каратэ. Он рассказывает о разных течениях и подвидах каратэ, показывает движения, в конце гордо заявляет:
— Так что эта классика — полное г#$но!
Из-за соседнего гаража выходит, покачиваясь, работяга с мутным взглядом, смотрит на нас и заявляет:
— Что ты сказал??? Да пошёл ты на#$% со своим передним приводом!
N>>Если бы ты умел читать, ты бы начал возражать на совсем другие места из того сообщения. WH>Да правда что ли? WH>На что тут можно возразить? WH>Все что можно сделать, это указать на бред.
Вот и критикуй по сути — о пользе DSL для программистов, как совсем другого явления, чем DSL для пользователей.
Я поставил ему плюс именно за грамотные и интересные комментарии о DSL для пользователей — я раньше как-то не задумывался о том, почему большинство успешных из них так похоже на Basic.
То, что он начинает с категорического ограничения своего контекста и в принципе игнорирует мир DSL для программистов, разумеется, некорректно, но это специфика его манеры и как бы уже привычно.
А вот тема DSL для программистов — больше твоя тема. И если бы ты не пытался сразу одним словом определить весь мир (причём в 90% случаев это слово "бред"), тебя можно было бы читать с пользой.
А пока что с этим явные проблемы.
Здравствуйте, WolfHound, Вы писали:
WH>В основе SQL матан. Реляционная алгебра называется. WH>А то, что матан вдруг оказался простым в использовании это не удивительно. WH>Его для того и придумывают. Чтобы сложные вещи можно было записывать относительно простым способом.
Угу смотрю я на запросы по 10 страниц никакой простоты и наглядности. Через навигационные методы было бы проще и нагляднее или Linq.
Но есть простые задачи где SQL рулит. Нужно и то и другое. Нужны и DSL в составе ЯОН.
и солнце б утром не вставало, когда бы не было меня
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, oldjackal, Вы писали:
O>>Писать компиляторы и интерпретаторы намного проще чем принято думать. Это же тупая, формализованная и давно решенная задача. Мозгов не требует. WH>Честно говоря, современные наработки весьма кривы. Но я работаю над выпрямлением. WH>https://github.com/rampelstinskin/ParserGenerator
Ты почти в каждый постинг суёшь эту ссылку.
Я охотно верю, что ты гордишься этим результатом. Но я точно так же уверен, что 99% читателей открывают, находят кучу странных зюк на неизвестном языке и закрывают.
Вместо этой ссылки следовало бы нарисовать статью в стиле хабра, с такими же подробными разжёвываниями начиная с азов и красочным рассказом о преимуществах.
Если ты хочешь, чтобы к тебе потянулись люди — а судя по заспамлению этой ссылкой, ты таки этого хочешь — то будь проще и понятнее.
Да какая разница, какая она?
