Здравствуйте, Tanker, Вы писали:
T>Ну тогда навскидку" T>Как быть с теми, чей домен не сильно определен ? T>Как быть с теми, которые плохо формализованы ? T>Как быть с теми которые затрагивают сразу несколько доменов ?
Элементарно — не мыслить вообще в таких категориях. Есть простой и естественный, очевидный подход — плясать от терминологии задачи. Термины и отношения между ними сами собой язык и сформируют. Никаких формализмов, абстракционизмов и модернизмов не надо.
T>Наиболее дешовое, которое подходит для текущего случая. Бюджеты вобщем не резиновые.
А проще и дешевле чем с DSL уже и некуда.
WH>>Скажи, зачем ты парсишь CSV?
T>Импортирую данные которые кастомеры по отрасли хранят в CSV.
Куда?
T>Я видел проекты где решения вроде string.split работали десятками лет. Для чего там полноценный парсер ?
А что такое "полноценный парсер"? Такой, который escape всякие поймет, да кавычки корректно прочитает? Ну так он действительно необходим, тупое решение будет работать до первого же не-тупого CSV от "кастомеров по отрасли" (уж не знаю, кто это такие, но звучит страшно).
T> Я вот не смог объяснить, потому там и по сей день string.split.
Достаточно показать валидный CSV который этот split сломает. Чего там объяснять-то?
T>Не совсем ясно, как быть с приложением, где встретится сразу пачка разных областей. Где набрать дсл на все случаи жизни ?
Те, кто не способен dsl написать, не справятся и с тупым решением задачи, требующей экспертизы в нескольких областях.
T>>>DSL, хочешь ты или нет, это очень сложная тема. WH>>Только для тех, кто ничего кроме книги дракона не видел.
T>А большинство про неё даже не знают.
У них огромное преимущество — они не испорчены и не напуганы.
Здравствуйте, Tanker, Вы писали:
WH>>Ибо все, что люди из него выносят это то, что компиляторы это что-то сложное. WH>>При этом реальных навыков создания компиляторов они не получают. По тому и говорю, что не учат.
T>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют.
Неверно. При паршивом преподавании любой материал сложным покажется. А в данном случае вообще нужный материал и не дают, а только грузят абсолютно несущественной ерундой, 100% из которой на практике не пригодится совершенно. То, что пригодится, как раз и не дают.
T>Я и не говорил про матан, но по моему компиляторы это всего лишь часть математики.
Так любую хоть немного формализуемую (пусть даже только в бредовых фантазиях формализуемую) отралсь можно обозвать "частью математики".
Здравствуйте, Tanker, Вы писали:
T>В кратце, люди создают инструментарий для себя T>1 орудийный == синтаксис T>2 понятийный == семантика
T>Людие которые в разумные сроки могут п.2 + п.1 настолько мало, что их можно пересчитать по пальцам.
Вот как раз это утверждение совершенно не соответствует действительности. Это может любой школьник. Не напрягаясь. Если вооружится правильным подходом и если не испортит себе мозги драконьими книгами и матаном.
ANS>Тот же Word+VB умеет работать с COM. Чем это отличается от С с библиотеками?
VB умеет импортировать ф-ии из DLL. Потому что он не скрипт, а полноценный язык программирования. Но VBScript не умеет. А с COM работает только через ф-ию CreateObject, которую ему предоставляет хост.
ANS>А то получается, что С без библиотек это DSL, а с — нет.
На С и на VB можно писать эти библиотеки. И подключать любые имеющиеся. Вот такое маленькое отличие. Хотя... никто не мешает хосту дать возможность подключать библиотеки. Я похожим образом поступал несколько раз во время хостинга JS для прикладных нужд.
Здравствуйте, Andrei N.Sobchuck, Вы писали:
ANS>Я к тому, что наличие "встроенного" класса "Документы" ничем таким не отличается от класса "Документы" в Java/C#, чтобы язык со встроенным классом стал DSL.
Он только синтаксисом не отличается. Но реально отличается всем. Возьми для сравнения скриптовый объект JS — они все одинаково устроены. А в 1C встроенные объекты имеют уникальное устройство каждый, но для тебя эта уникальность скрыта за однообразным синтаксисом. Разве не в этом задача DSL — скрывать подробности относительно реализации предметной области?
V>>Тебя синтаксис языка в заблуждение ввел, похоже. ANS>DSL нужен человеку -> вся суть DSL в синтаксисе (а если не вся, то 80% точно, т.е. таки вся).
Ну таки да. Разве что этот синтаксис у некоторых вызывает устойчивые ассоциации с ранее виденным.
Здравствуйте, Sinclair, Вы писали:
S>Но это как раз неинтересно. Интересно, когда вам нужно передать данные из одного контрола или формы в другой. Вот коллега Wolfhound предлагает делать это через биндинги и ViewModel, а от событий (как я понял) отказаться вовсе.
Совсем не получится.
Ибо есть кнопки по нажатию на которые обычно нужно что-то сделать.
Но в остальном вполне можно и без обработчиков жить.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, vdimas, Вы писали:
V>>>Отсебятина из-за непонимания. кол-во писанины зависит исключительно от соотношения встроенных в язык/библиотеки ср-в и потребностей в них для конкретной задачи. В DSL это соотношение гораздо лучше для конкретного класса задач. G>>Так это и есть та мощность языка, которую имеет смысл тут рассматривать.
V>Это выразительность.
Ок, напиши вместо мощности выразительность. Чтонить изменится? Мы тут не корректность терминов обсуждаем.
Здравствуйте, oldjackal, Вы писали:
O> Ну так я смогу определить такую функцию и в том же модуле ей воспользоваться? А смогу из макроса воспользоваться другими функциями из этого модуля?
Да. Да.
В том числе рекурсивно.
WH>>Именно. Причем типизация будет полностью декларативна. Я уже и матаном на эту тему обчитался. O> Вот этого я и боюсь. Может получиться неприемлемо сложно.
С этим я как раз борюсь.
Для этого матаном и обчитался.
Ибо хочу вместо того чтобы заставить человека писать вывод типов (это сложно шо писец) написать декларативный код проверки типов.
И по нему уже сгенерировать вывод типов.
Уверен использовать это будет очень просто.
O> Иногда типы могут зависеть от типизации вложенных макр, которых нет (и про которые мы ничего не знаем) до тех пор, пока AST не развернули. Когда я пытался прикрутить типизированную макросистему к ML я по этим граблям походил. В Nemerle система типов несколько более человечная, так что не берусь утверждать, что трудности непреодолимы.
В Н2 идеология другая.
А системы типов вообще нет. Ибо это не язык, а движок для создания языков.
Ибо, например мой генератор парсеров имеют свою систему типов не похожую на другие языки.
Основная идея состоит в том, что каждая конструкция имеет, не только правила разбора, но и правила типизации.
Таким образом, мы можем полностью типизировать программу до переписывания в язык более низкого уровня.
Скажем в режиме ИДЕ, переписывание производится, вообще не будет.
Ибо все ошибки компиляции и так будут известны.
Скажем для if будет что-то типа такого (очень предварительный вариант):
abstract rule Expr
{
Type : LangType;
}
rule IfExpr is Expr
syntax "if" "(" cond : Expr ")" expr1 : Expr "else" expr2 : Expr;
{
assert(cond.Type == #bool, "Condition type must be bool.");
assert(Type <= expr1.Type && Type <= expr2.Type, "Branch types must be convertible to same type.");
}
O> Обоснуете? Чем плоха возможность пользоваться определениями сразу, не отходя от кассы?
Я понимаю, о чем ты, но у меня просто принципиально иной подход к построению системы.
То, что ты хочешь, в нем просто не имеет смысла.
O> Ну, по этому вопросу лучше не дискутировать, у меня прямо противоположное мнение —
По которому из трех пунктов?
Тормозит, жрет память и главное ошибки не ловит.
O>я не хочу закрывать для себя возможности реализации вообще любой системы типов.
Вы можете выбрать любую систему типов, если она проверяется статически.
Динамически типизированный язык тоже можно будет сделать. Это путь я не смогу закрыть при всём желании. Просто я не вижу в них смысла.
O>Если же в языке уже есть строгая типизация, то она ограничивает возможные системы типов надстраиваемых над языком DSL.
Н2 не будет навязывать систему типов языку который на нем разрабатывается.
Это моя принципиальная позиция.
Это будет обеспечено тем, что иерархия языков будет весьма ветвистой и глубокой.
Те не будет какого-то одного языка, под который все обязаны подстроиться.
O> Пусть он другой, но если он ограничивает возможности реализации иерархических макросов, то он должен как минимум предоставлять что-то взамен. Что-то не менее ценное.
Я это понимаю. И изначально создаю систему с прицелом на иерархию языков.
Разница с макрами в том, что макры всё же завязаны на конкретный язык. И упираются в его ограничения.
У меня этого не будет.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, oldjackal, Вы писали:
O> Вам нравятся грамматики со сложными правилами приоритетов? А я вот такой код читать не могу совершенно, если там есть что-то сложнее школьной арифметики. И писать такой код не могу, я всегда скобочки расставляю явным образом. Не хочу и не могу помнить, больше у '%' приоритет чем у '+' или меньше.
Это дело вкуса.
Большинство людей это не напрягает.
WH>>У меня обе без мемоизации работают. Ключевые слова Pratt parser. WH>>У меня алгоритм основа на нем. O> Как-то информации по нему мало, кроме самой оригинальной статьи.
Есть такое. http://javascript.crockford.com/tdop/tdop.html
Бред про то, что оно заточено под динамически типизированные языки пропускай мимо ушей.
O> Совсем нет? Так не бывает. Но вы меня заинтересовали, попробую узнать про Pratt-а побольше. Есть какие-то ссылки по теме, которые гугл и википедия не дадут?
У меня нельзя делать непрямую левую рекурсию.
Те это правильно:
pow is expr = expr : 31 '^'s expr : 30;
Тк левая рекурсия идет в правило, которое расширяется.
Но на практике я даже представить не могу, кому может понадобиться непрямая левая рекурсия в данном алгоритме.
В оригинальном алгоритме такой проблемы нет, ибо там всего одно правило. Те непрямой левой рекурсии быть просто не может.
O> Естественно, воспользоваться я этим смогу только если алгоритм позволяет писать парсеры руками, на C или шарпе, без всяких генераторов.
С этим как раз все просто.
Пратт простой как пробка.
WH>>Да я не спорю. Но существующие языки тоже нужно разбирать. O> К задаче реализации DSL это особого отношения не имеет, к счастью.
Но у меня это требование есть.
Ибо одна из задачь парсить C# и Java.
Чтобы дать людям возможность взять готовый проект и начать добавлять туда макры.
WH>>Мне хватает скорости, чтобы все распарсить. O> Даже если там сто тысяч строк кода?
Nemerle.Peg пару метров в секунду на грамматике C# дает.
WH>>Я это понимаю. И собираюсь сделать язык описания ошибочных ситуаций. O> А это не ошибочная ситуация. Это предупреждение.
Тогда видимо я что-то не понял.
Я думал ты про восстановление после ошибок говоришь.
WH>>Это позволит очень просто задавать сообщения для подобных случаев. O> Очень интересно. Я пока что не представляю себе, как это можно сделать декларативно.
Пока в процессе. Так что конкретного ответа пока не дам.
O> Мне Packrat интересен как раз тем, что его можно и руками делать, без DSLей, без генераторов.
Так там как раз генератор.
O> Семантика то как раз прозрачна, поскольку не далеко ушла от привычной семантики низлежащего языка.
Вот ту не могу согласиться.
Ибо ДСЛ для того и создают чтобы уйти от семантики языка более низкого уровня.
... << RSDN@Home 1.2.0 alpha 4 rev. 1472>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Sinclair, Вы писали:
S>Здравствуйте, Vain, Вы писали: S>>>А если вам нужно посчитать какие-то агрегаты по результату join восьми таблиц, и при этом ещё иметь гарантии ACID, то вручную вы это делать замаетесь. V>>Ну что вы мне сказки рассказываете? Специалист по SQL это такой же специалист по C++ или java, а это самостоятельные языки. S>Я не понял вашу фразу.
Меня терзают смуутные сомнения (c)
Какую именно?
[In theory there is no difference between theory and practice. In
practice there is.]
[Даю очевидные ответы на риторические вопросы]
Здравствуйте, vdimas, Вы писали:
V>ИМХО, SELECT оператор SQL спроектирован превосходно, т.к. обладает реляционной полнотой и при этом отличной читабельностью.
С читабельностью, увы, не очень хорошо, особенно в его оригинальной версии. И совсем плохо с декомпозицией (я знаю про СТЕ и пользовательские функции, но этого очень мало). Впрочем, качество дизайна SQL относительно терпимо.
V> И да, SQL-ем после некоторого навыка может пользоваться даже не программист. И его разрабатывали не с потолка, это был результат обобщения многолетнего опыта разработки и эксплуатации первой промышленной БД.
К сожалению, при его разработке много чего принесли в жертву похожести SQL запросов на естественный язык. Толку с того вышло немного, а вот дизайн подзасрался основательно. Надо было делать что то вроде того, что сделали в шарпе в query comprehension. Но поезд давно ушел, увы.
V>ИМХО, это хорошо, что последние годы в кремнии встряли, т.е. не ожидается такого роста быстродействия...
Да не встрял никто в кремнии. Просто у Интела исчезла в high end процессорах конкуренция и он начал искусственно тормозить прогресс.
V>Для некоторых нужд я бы променял. Только не по физической структуре, а по некоторому АПИ итерирования по данным. Из-за того, что сложные вычисления на SQL не айс, т.к. интерпретатор.
Итерирование по данным, видишь ли, проблематично не из-за SQL, а из-за проблемы обеспечения ACID для таких курсоров. С точки зрения масштабируемости намного выгоднее выплюнуть все клиенту, и пусть он уже сам ковыряется. Ясно, что на маленьких инсталляциях это дало в разы просадку по абсолютному перформансу, но производителей больше заботят жирные заказчики с большими потребностями.
V> А преобразовать реляционные исчисления в реляционные уравнения — не бог весть какая наука.
Я тебе больше скажу — оказывается, можно преобразовать реляции SQL в навигации NoSql и обратно.
... << RSDN@Home 1.2.0 alpha 5 rev. 31 on Windows 7 6.1.7601.65536>>
Здравствуйте, Sinclair, Вы писали:
S>Поздравляю, вы почти изобрели .dfm. Один-в-один. С точностью до способа группировки — индентация вместо явного object ... end.
А dfm тоже компилировали в C++ или что-то подобное? Тогда это был не плохой dsl наверное. Возможно стоит какие-то идеи взять с него.
S>Вы же только что критиковали "языки размётки", в которых "всего лишь привязываются обработчики, написанные на системном языке". И тут же делаете то же самое. Принципиальный момент, которого тут не хватает — согласование сигнатур. Грубо говоря, хорошо, когда у вас евенты без параметров, и методы без параметров.
Ну во-первых тут как раз видно два вида вызовов — из системного языка и непосредственно из gui объекта. Т.е. уже не просто язык размётки. Потом в любом случае необходимы составные операторы типа:
onclick
[calculate]
this.Update
Далее, я думаю что что бы полностью замкнуть весь интерфейс на себе только вызовов будет недостаточно — нужны ещё какие-то операторы для логики. Не знаю насколько универсальные. Но допустим возможность писать код типа такого:
onrclick
if Tree.selected
ContextMenu.Show
должна там быть.
и т.д...
S>Но это как раз неинтересно. Интересно, когда вам нужно передать данные из одного контрола или формы в другой. Вот коллега Wolfhound предлагает делать это через биндинги и ViewModel, а от событий (как я понял) отказаться вовсе.
Такой вариант может быть ещё интереснее, но я пока так до конца и не представил его себе вне html+javascript области. Вот может кто-нибудь написать мне пример для решения буквально той же простейшей задачи (что я приводил выше с парой окон) на подобном dsl? Т.е. я понимаю что всю мощь mvvm на нём не продемонстрируешь, но ведь наш язык должен хорошо решать и тривиальные задачи...
Здравствуйте, alex_public, Вы писали: _>А dfm тоже компилировали в C++ или что-то подобное? Тогда это был не плохой dsl наверное. Возможно стоит какие-то идеи взять с него.
DFM — это язык разметки, принятый в VCL. Его не надо было "компилировать в C++", потому что классы VCL умели его десериализовывать напрямую.
_>Ну во-первых тут как раз видно два вида вызовов — из системного языка и непосредственно из gui объекта.
Нет, не видно тут никаких разных видов вызовов. Вы вызываете метод либо формы, либо одного из контролов на форме.
С точки зрения VCL, например, они совершенно одинаковы. Главное, чтобы была доступна метаинформация об этих методах — для выполнения связывания.
Т.е. уже не просто язык размётки. Потом в любом случае необходимы составные операторы типа: _>
onclick
_> [calculate]
_> this.Update
_>Далее, я думаю что что бы полностью замкнуть весь интерфейс на себе только вызовов будет недостаточно — нужны ещё какие-то операторы для логики. Не знаю насколько универсальные. Но допустим возможность писать код типа такого: _>
onrclick
_> if Tree.selected
_> ContextMenu.Show
_>должна там быть.
Отлично. Давайте поймём, где граница между этим языком и системным. И в чём преимущество наличия целого отдельного языка для описания обработчиков.
_>Такой вариант может быть ещё интереснее, но я пока так до конца и не представил его себе вне html+javascript области. Вот может кто-нибудь написать мне пример для решения буквально той же простейшей задачи (что я приводил выше с парой окон) на подобном dsl?
Ну, пусть WolfHound прокомментирует.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>На С и на VB можно писать эти библиотеки.
Не-не-не-не-не, Дэвид Блейн. Это получается бесконечная рекурсия. Вот, допустим, в чистом C у нас нет возможности работать с портами 8086. Подключив библиотеку, я могу добавить туда эту возможность через inp() и outp().
Но каким образом я напишу эту библиотеку на С? Если бы я мог обращаться к портам на С, мне не потребовалась бы библиотека.
Уйдемте отсюда, Румата! У вас слишком богатые погреба.
Здравствуйте, vdimas, Вы писали:
V>Чего сомнительного? ИМХО, это программистская привычка. Изначальный смысл слова "язык" — это вообще медиа. Ну, звук то бишь. V>До сих пор вроде есть языки, не имеющие текстового представления.
В том что у любого языка есть свой словарь. И у графических и у звуковых и у текстовых. У того же UML его примитивы хорошо всем известны. У текстовых dsl их словарь задаётся синтаксисом. А тут вот совершенно непонятно что является единицами этого нашего графического dsl. Набор контролов, которые можно двигать мышкой? Но он кстати задан не авторами редактора, а авторами фреймворка, под который редактор генерирует код. В общем как-то мутно это всё.
V>У графических языков и спецификации графические.
Ну так тогда это совпадает с моей точкой зрения и спорить надо с Sinclair. )))
Здравствуйте, PSV100, Вы писали:
PSV>Естественно, ведь её популярность не на пустом месте была (кроме политических причин: распространённость Паскаля в учебных заведениях и развитость пиратства). И сейчас её уже столько лет все хоронят и хоронят, а она всё живёт себе и живёт (хотя, далеко не все хоронят).
Краем уха слышал, что там ещё некий Lazarus набирает силу. )
PSV>Или вот попался пример на WPF (я в нём не разбираюсь). Здесь TextBox будет виден только тогда, когда включён CheckBox (насколько приятно в таком XML ковыряться, я не в курсе, лично мне не очень): PSV>
PSV><Window x:Class="ParaPlan.Windows.Window1"
PSV> xmlns="http://schemas.microsoft.com/winfx/2006/xaml/presentation"
PSV> xmlns:x="http://schemas.microsoft.com/winfx/2006/xaml"
PSV> Title="Window1" Height="300" Width="300"
PSV> xmlns:converters="clr-namespace:ParaPlan.Converters">
PSV> <StackPanel Orientation="Vertical">
PSV> <StackPanel.Resources>
PSV> <converters:BooleanToHiddenVisibility x:Key="boolToVis"/>
PSV> </StackPanel.Resources>
PSV> <CheckBox Content="Check to show text box below me" Name="checkViewTextBox"/>
PSV> <TextBox Text="only seen when above checkbox is checked"
PSV> Visibility="{Binding Path=IsChecked, ElementName=checkViewTextBox, Converter={StaticResource boolToVis}}"/>
PSV> </StackPanel>
PSV></Window>
PSV>
Вот это уже ближе к тому, что мне хотелось бы. Но в таком дико уродливом виде естественно не имеет смысла. И насколько я вижу тут все проблемы от того, что ставилось требование обязательной декларативности. Кстати, тут вот параллельно проблемы sql обсуждали — тоже самое опять же. Похоже для некоторых разработчиков декларативность является чем-то священным, не смотря на то что в дальнейшем она приводит к ужасающему коду.
PSV>Я в соседнем сообщении
Да, я посмотрел — это как раз ближе к тому, что мне интересно для нативных предложений, но что я не стал бы применять в вебе (это я про первый пример оттуда). В современной веб разработке обычно стараются уйти от каких либо намёков на код внутри html. А тут некие привязки и т.п. В то же время для приложения с нативным интерфесом это возможно было бы удобно, причём возможно даже можно было совместить в единое целое view и view-model.
А разница на мой взгляд в том, что под дизайном в случае сайта и в случае приложения с нативным интерфейсом частенько подразумеваюся достаточно различающиеся вещи.
Здравствуйте, Sinclair, Вы писали:
S>DFM — это язык разметки, принятый в VCL. Его не надо было "компилировать в C++", потому что классы VCL умели его десериализовывать напрямую.
Там был какой-то практический смысл тащить в рантайм лишнюю сущность или это просто "так реализовали"?
S>Нет, не видно тут никаких разных видов вызовов. Вы вызываете метод либо формы, либо одного из контролов на форме. S>С точки зрения VCL, например, они совершенно одинаковы. Главное, чтобы была доступна метаинформация об этих методах — для выполнения связывания.
Как раз есть. Изнутри dsl мы чётко видим два вида вызовов: родные вызовы контролов и некий внешний вызов куда-то там. Да, при той реализации компиляции языка, что я предложил, они потом оказывались членами одного C++ класса. Но это уже вне языка (dsl) и только одна реализация, простейшая, которую я бы мог сам с ходу закодировать. А можно же представить себе много других вариантов. Например dsl компилируется непосредственно в последовательности вызовов win api (или же gtk api или же android api, в зависимости от целевой платформы), а наша функция calculate вообще написана на ассемблере и подключается через библиотеку. И это всё будет работать и в одной реализации и в другой, для одного и того же dsl кода.
S>Отлично. Давайте поймём, где граница между этим языком и системным. И в чём преимущество наличия целого отдельного языка для описания обработчиков.
Преимущество естественно в простоте и удобстве. А вообще изначально задача ставилась не про язык для обработчиков, а про отделение "языка интерфейса" (который вбирал бы в себя всё, включая дизайн, логику интерфейса и т.д.) и "языка движка" с удобной связью между ними. Сейчас же в основном присутствуют (не в вебе) варианты разделяющие "язык размётки интерфейса" и "всё остальное". И как я уже писал, в таком случае, мне даже сам язык размётки как таковой не нужен — полностью хватает визуального генератора, генерирующего системный код. Вариант выше с языком размётки, расширенным возможностью написания примитивных (но достаточных для логики интерфейса) обработчиков, — это просто моя первая мысль на эту тему. Если есть решение удобнее, то с удовольствием рассмотрю и забуду свой вариант.
Пока писал это, пришёл в голову альтернативный вариант. Я вроде уже писал что не исключаю вариант такого dsl реализованый как встроенный в системный язык. Т.е. условно говоря вот у нас сейчас есть визуальный редактор умеющий генерировать C++ (допустим для примера) код. При этом он не задаёт никаких отношений логики между элементами, максимум отношения взаимного расположения. Если мы добавим возможность вставлять в редакторе код обработчиков на неком простеньком языке (а не имя функции как сейчас), то получим возможность удобно задавать и логику интерфейса. Причём редактор в принципе может сильно подсказывать при редактирование обработчика, т.к. он видит все существующие сущности и т.п. Да, так вот, а этот самый простенький язык в принципе можно реализовать на макросах или шаблонах C++. Соответственно получаем готовую систему минимальными усилиями и даже без создания дополнительных парсеров/компиляторов. Эх, было бы сейчас свободное время, может быть даже попробовал бы сам (код того визуального редактора в открытом доступе, так что...) такой вариант набросать.
Здравствуйте, WolfHound, Вы писали:
T>>Это и показывает, что материал сложный. Когда материал простой, все студенты его на раз умеют. WH>Нет. Это показывает, что студентов учат не правильному материалу.
Если так, то это значит, что тема компиляторов сложна даже для преподавателей.
Здравствуйте, oldjackal, Вы писали:
O> Прелесть подхода с употреблением DSL в том, что плевать на общие случаи, и решать надо всегда лишь примитивные частные задачи. Общее решение, при необходимости, само получится. Потом.
А для чего дсл для примитивных частных задач ? их тыщи. ДСЛ нужен там где можно закрыть общий случай.
T>>Пример — почему ты не предложил html+css примерно 40 лет назад ?
O> А вот когда html таки появился, я сразу говорил что это чушь, и что все делают заведомо неправильно. Недоумевал, почему вылезло это SGML-отродье и почему забыли про DPS и другие умные технологии. Да что там — latex тот же уже на всю катушку был популярен (и Тим Барнс-Ли его прекрасно знал, как и про DPS). Но все равно родилась фигня, а до хотя бы отдаленно приличного состояния вся эта шелуха не дошла и по сей день.
Вот-вот. А сейчас для UI считай ничего лучше html+css вобщем то и нет. А говоришь одного раза достаточно.
