«Всякая задача становится тривиальной, если ее сформулировать в адекватном языке» И. М. Гельфанд
«Серебряной пули нет», сказал Ф.Брукс без малого двадцать лет назад и надолго остудил пыл благородных рыцарей от программирования в борьбе с Драконом сложности. С тех пор его Величество Дракон служит оправданием тому, что пользователям вместо одних плохо работающих программ, навязываются все новые и новые, которые не намного лучше, но пожирают все больше быстродействия и памяти компьютеров. В угоду Дракону, выращена специальная разновидность программистов — «code & fix» («программируй и исправляй ошибки»). «Не умением, а числом!», «Каждая кухарка может управлять программным проектом!» — написано на их знаменах. Чтобы прокормить Дракона каждый день ими создаются гигабайты исходного кода, значительная часть которого никогда не будет востребована пользователями. За прошедшие годы этот отвратительный Дракон разросся и стал «Идеей. Исторической необходимостью. Нашим государственным интересом. Могущественным фактором, оправданием наших объединенных усилий» (С. Лем, О выгодности дракона).
Я не собираюсь искать очередную «серебряную пулю», но не потому, что ее нет, а потому, что не очень верю в драконов. Драконы, как правило, рождаются в сознании людей, когда они сталкиваются с явлениями, которые не находят объяснения в их предыдущем опыте. Для информатики наличие пробелов не удивительно потому, что это очень молодая отрасль человеческого знания. Если сравнивать производство программного обеспечения с производством технических систем, которое насчитывает многие тысячелетия, то можно заключить, что оно пока пребывает в эмбриональном состоянии.
Я не очень верю в драконов, зато верю в то, что сложность это понятие субъективное. Одно из определений слова «сложный» — трудный, запутанный. Например, сложная задача, сложная (а может быть точнее запутанная?) программа. То, что для одного человека является трудным и запутанным для другого может быть легким и ясным. Движение планет в геоцентрической модели Птолемея по циклам и эпициклам с поправками к ним выглядит сложным. Движение по эллипсам Кеплера – простым. Если редактировать изображения в битовом формате, получится сложно, а если в графическом редакторе, то просто. Изображение множества Мандельброта может просто загипнотизировать своей сложностью непосвященного наблюдателя (Шабаршин А.А., ВВЕДЕНИЕ ВО ФРАКТАЛЫ), но на адекватном языке множество Мандельброта описывается крайне просто: «множество точек C на комплексной плоскости, для которых итеративная последовательность Z0 = 0; Zn+1 = Zn^2 + C не уходит в бесконечность».
В природе нет ничего трудного и запутанного. Нечто может только казаться трудным и запутанным человеку, который это нечто пытается понять. Может быть, программные системы только кажутся сложными? Я порой ощущаю себя шарлатаном, когда пытаюсь объяснить заказчику, почему так сложно добавить к программе функциональность, о которой он просит.
Еще в 1977 году в своей лекции при получении премии Тьюринга Джон Бекус говорил, что императивные языки программирования вынуждают программиста сосредоточится на операциях с памятью компьютера, а не на проблеме, которую надо решить. Что изменилось с тех пор? Ничего. Мы по-прежнему описываем задачу, которую должна решать программа, на языке битов, команд процессора, передачи управления. Мне представляется, что в будущем среды программирования будут в основном похожи на CAD системы с встроенным DSL. Программные системы будут создавать специалисты прикладной области, например, инженер-электронщик будет собирать программную модель электронной схемы из готовой элементной базы: моделей транзисторов, резисторов, конденсаторов, переключателей, соединителей и проч. Аналогично, будут собираться из готовых компонентов и бизнес-приложения: бухгалтерия, склад, производство и др. А что нам может помешать двигаться в этом направлении? ИМХО, это лишь дело времени.
Ведь для некоторых решений затраты на разработку поддержки DSL (генератора, например) гораздо больше чем то что можно описать через DSL. В результате мы можем не получить никакой выгоды от языкоориентированного подхода?
То есть когда в проекте модель относительно не большая, а функциональность очень разнообразная и требует больших не DSL описаний.
Здравствуйте, Blazkowicz, Вы писали:
B>У меня такой вопрос.
B>Ведь для некоторых решений затраты на разработку поддержки DSL (генератора, например) гораздо больше чем то что можно описать через DSL. В результате мы можем не получить никакой выгоды от языкоориентированного подхода? B>То есть когда в проекте модель относительно не большая, а функциональность очень разнообразная и требует больших не DSL описаний.
B>Или я в чем-то ошибаюсь?
Вопрос правильный и актуальный.....
С одной стороны сомнение в выгодах от такого подхода возникают, но с другой стороны если об етом пишет такой авторитет, то возникает мысль "а может в етом что-то есть"
интересно услышать мнение тех, кто близко пробовал создавать синтаксисы своих языков (или хотя бы XML схемы даных) для подобных задач... не было ли проблем с поддержкой таких языков и был ли вииграш в простоте понимания всей системы?
Здравствуйте, Sergi, Вы писали:
S>интересно услышать мнение тех, кто близко пробовал создавать синтаксисы своих языков (или хотя бы XML схемы даных) для подобных задач... не было ли проблем с поддержкой таких языков и был ли вииграш в простоте понимания всей системы?
У нас на одном проекте использование DSL было бы как нельзя кстати. Что-то типа визуального редактора. В котором число виджетов постоянно растет. К примеру как в MS Visio. Если бы не вышестоящий "архитектор", то вся работа сводилась бы только к модификации внутреннего DSL. Вот в этом проекте я вижу очень большую выгоду от такого подхода.
Но есть у нас и другой проект модель которого спокойно укладывается в десяток таблиц в базе данных. Но этот проект обвешан большим количеством несвязаного функционала. Даже представить себе не могу что же в нем можно было бы вынести в DSL.
Вот из-за второго примера мне и интересно может ли языкоориентрированный подход стать панацеей. Или все же можно выделить по какому-то признаку ряд систем в которых этот принцип не применим.
Здравствуйте, craft-brother, Вы писали:
CB> инженер-электронщик будет собирать программную модель электронной схемы из готовой элементной базы: моделей транзисторов, резисторов, конденсаторов, переключателей, соединителей и проч.
Здоровски. А сейчас как работают инженеры-электронщики?
Здравствуйте, Sergi, Вы писали:
S>интересно услышать мнение тех, кто близко пробовал создавать синтаксисы своих языков (или хотя бы XML схемы даных) для подобных задач... не было ли проблем с поддержкой таких языков и был ли вииграш в простоте понимания всей системы?
Первый пример из статьи описывает парсинг стандартного формата обмена данными между телефонными компаниями. Я делал практически в точности то же самое с описанием структуры на XML года три назад. Формат данных укладывался в XML, софтинка сама подбирала подходящий формат, парсила это дело и складывала в БД. По окончании запускаласть сохранённая процедура для обработки. Вся работа заняла несколько дней, после чего набиванием XML файлов занимались совсем другие лиди.
Интервьюировал я как-то одного китайца. Он 4! годя занимался подобными задачами. 4 года писал парсеры на C, которые делали тоже самое, что мая софтика, написанная за неделю.
... << RSDN@Home 1.2.0 alpha rev. 0>>
Если нам не помогут, то мы тоже никого не пощадим.
Здравствуйте, Blazkowicz, Вы писали:
B>Вот из-за второго примера мне и интересно может ли языкоориентрированный подход стать панацеей. Или все же можно выделить по какому-то признаку ряд систем в которых этот принцип не применим.
Панацей конечно не бывает. Но если учесть, что языки бывают визуальные и очень разные, то подход очень и очень гибкий. Вопрос толко в том где черта после которой разработать ДСЛ проще чем решить проблему в лоб.
... << RSDN@Home 1.2.0 alpha rev. 620>>
Есть логика намерений и логика обстоятельств, последняя всегда сильнее.
Здравствуйте, VladD2, Вы писали:
VD>Панацей конечно не бывает. Но если учесть, что языки бывают визуальные и очень разные, то подход очень и очень гибкий. Вопрос толко в том где черта после которой разработать ДСЛ проще чем решить проблему в лоб.
Не думаю что тут можно подобрать формальные параметры. ИМХО это решение должно приниматься на уровне интуиции ведущего программиста или архитектора.
... << RSDN@Home 1.1.4 beta 6a rev. 436>>
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Blazkowicz, Вы писали:
B>У меня такой вопрос.
B>Ведь для некоторых решений затраты на разработку поддержки DSL (генератора, например) гораздо больше чем то что можно описать через DSL. В результате мы можем не получить никакой выгоды от языкоориентированного подхода? B>То есть когда в проекте модель относительно не большая, а функциональность очень разнообразная и требует больших не DSL описаний.
B>Или я в чем-то ошибаюсь?
нужно еще учитывать, что DSL можно использовать повторно, так же как и библиотеки функций
DSL для описания GUI, DSL для описания данных и ORM — это только начало
Здравствуйте, Дарней, Вы писали:
Д>нужно еще учитывать, что DSL можно использовать повторно, так же как и библиотеки функций Д>DSL для описания GUI, DSL для описания данных и ORM — это только начало
Разве? Мне кажется что при повторном использовании нет различия между языкоориентированым подходом и ООП.
Как можно использовать повторно DSL без генератора и пр?
Здравствуйте, Blazkowicz, Вы писали:
B>Разве? Мне кажется что при повторном использовании нет различия между языкоориентированым подходом и ООП.
Наверно, ты не так понимаешь идею DSL. Нет никакого смысла в создании DSL конкретно под штучную задачу, чтобы по завершении проекта отправить его в Recycle Bin. DSL обычно создают для решения какого-то определенного класса задач или подзадач. Регулярные выражения, SQL и т.д. и т.п.
B>Как можно использовать повторно DSL без генератора и пр?
а как можно использовать интерфейс библиотеки классов без бинарных файлов с реализацией? Правильно, тоже никак.
Здравствуйте, Дарней, Вы писали:
Д>Наверно, ты не так понимаешь идею DSL. Нет никакого смысла в создании DSL конкретно под штучную задачу, чтобы по завершении проекта отправить его в Recycle Bin. DSL обычно создают для решения какого-то определенного класса задач или подзадач. Регулярные выражения, SQL и т.д. и т.п.
Не согласен. Уже приводил пример выше. У меня есть визуальный редактор с конечным, но все же очень большим набором визуальных копманент. DSL там бы не помешал, потому что 70% работы это дописывание компанент в существующую систему. Но смысла использовать тот же DSL в дальнейшем и наращивать эти компаненты до бесконечности — нет.
B>>Как можно использовать повторно DSL без генератора и пр?
Д>а как можно использовать интерфейс библиотеки классов без бинарных файлов с реализацией? Правильно, тоже никак.
Здравствуйте, Blazkowicz, Вы писали:
B>Не согласен. Уже приводил пример выше. У меня есть визуальный редактор с конечным, но все же очень большим набором визуальных копманент. DSL там бы не помешал, потому что 70% работы это дописывание компанент в существующую систему. Но смысла использовать тот же DSL в дальнейшем и наращивать эти компаненты до бесконечности — нет.
DSL для какой конкретно подзадачи?
B>>>Как можно использовать повторно DSL без генератора и пр?
Д>>а как можно использовать интерфейс библиотеки классов без бинарных файлов с реализацией? Правильно, тоже никак.
B>Ну тогда смысл говорить о reuse?
о reuse библиотек классов? Ну конечно же, никакого смысла
Здравствуйте, Blazkowicz, Вы писали:
B>Ведь для некоторых решений затраты на разработку поддержки DSL (генератора, например) гораздо больше чем то что можно описать через DSL. В результате мы можем не получить никакой выгоды от языкоориентированного подхода? B>То есть когда в проекте модель относительно не большая, а функциональность очень разнообразная и требует больших не DSL описаний.
Если язык поддерживает макросы (Lisp, Nemerle и т.п.), то проблема разработки отсутствует. Если не поддерживает, можно взять встраиваемую версию Scheme например.
Здравствуйте, Blazkowicz, Вы писали: B>Ведь для некоторых решений затраты на разработку поддержки DSL (генератора, например) гораздо больше чем то что можно описать через DSL. В результате мы можем не получить никакой выгоды от языкоориентированного подхода?
Правильный вопрос.
Собственно говоря мы уже в нескольких проектах использовали DSL-и.
На их опыте могу отметить несколько моментов.
1. DSL-подход оправдан если выполняется хотя бы одно из двух условий:
— Над одной моделью предметной области планируется выпутить серию близких приложений.
— Одно приложение требует большой модифицируемости (паралетльно — под разных клиентов, или последовательно — при изменении ситуаций во времени). И при этом есть увереность, что базовое ядро модели предметной области останется неизменным.
2. Создание DSL очень хорошо дисциплиниует мышление разработчиков (это я сейчас с позиции ситем-архитектора говорю ). Библиотеки, которые лежат "под" DSL обычно получаются качественнее, чем те, которые писались только как библиотеки. У разработчиков не возникает соблазна "протащить" лишний настроечный параметр, или открыть прямой доступ к внутренним данным. В результате их можно потом хорошо использовать просто как библиотеки.
3. Текст на DSL боле "понятен" прикладнику. Не стоит особо надеяться, что прикладной специалист начнет сам писать эти тексты (возможно, но скорее исключение). Но он часто может их читать. То есть его можно спросить: "- Посмотри, ты это имел в виду?"
Если нам не помогут, то мы тоже никого не пощадим.
). Библиотеки, которые лежат "под" DSL обычно получаются качественнее, чем те, которые писались только как библиотеки. У разработчиков не возникает соблазна "протащить" лишний настроечный параметр, или открыть прямой доступ к внутренним данным. В результате их можно потом хорошо использовать просто как библиотеки.