Обсуждение

а что с энергией приливов/волн? я слышал там тоже хорошие перспективы...

Если послушать всех этих "возобновляльщиков" по отдельности, то у всех хорошие перспективы. Затем нужно сравнивать ;)

Возобновляльщики хороши, да только с собой наружу не возьмешь... Местно - сравнивать, да.

Оу... спасибо. Не знал, что Wolfram Alpha доделали. :)

Доделать-то доделали... Ввожу свою любимую задачку, содержащую в формулировке двойное применение функции: f(f(x)). Она сначала заменяет это на "более удобную" запись f(x)², а потом забывает, что имелось в виду, и считает её возведением в квадрат. Это к вопросу о DSL и традиционной математической нотации. ;-)

... Три категории предвкушения чего-то приятного ...

Это вообще к вопросу о нотациях. Там ведь нотация от Mathematica. Но скобки на квадрат заменять -- это в любой нотации беспредел :)

Традиционная ещё и очень 2D со своей спецификой. При переводе в 1D компьютерное x^2+2*x смотрится несколько уместнее сплюснутого x2+2x, но в математических пакетах своя логика нотаций. Напоминает ситуацию с софтсинтами, когда приложение затачивается под look&feel исходного железа, как по интерфейсу, так и по ограничению возможностей.

Про IDE как средство интеграции кучи DSL, собранных под задачу — хорошо. Но на тему собственно интеграции надо много думать. Тем временем в параллельной вселенной о том же: http://egmg.livejournal.com/1263622.html

Согласен, что в тексте по ссылке про то же самое, но там заход абстрактный из серии "лучше бы всем быть здоровыми и богатыми, нежели бедными и больными", а у меня -- практический, понятно что можно было бы делать, и что обсуждать.

Тем не менее, в софтсинтах не пятилинеечная нотная запись, а piano roll, что я специально и отметил.

> Это все известно давно, но никто (правительства и корпорации) по этому поводу не чесался. Правительства безответственны, а у корпораций горизонт окупаемости проектов не более 5 лет. Тезис не соответствует реальности. Вот у Франции к примеру 80% электроэнергии вырабатывается на ядерных электростанциях. В Испании в районе 50%. В Германии пытались строить атомные станции, но им мешают зеленые - в данном случае, зеленые действуют по заказы Франции. В СССР ядерная энергетика тоже развивалась, ядерного топлива было очень много, так что если бы не либеральные реформы, то тоже с ядерной энергетикой было все хорошо, по крайней мере были возможности. Сейчас же возможностей нет, ядерное топливо продали. В Германии проблемы с углеводородами известны давным давно, и они давным давно купили долю в Газпроме и наладили поставки газа, это в литературе обычно называется "газовая пауза" - т.е. нужно какой-то период времени пересидеть на газе. Поставки газа в Германию идут, вот странам послабее, конечно бывают сбои. Таким образом, в Европе четко видно, что ведущие страны об этой проблеме в курсе и ее худо бедно решают. Не решают только убогие страны. Естественно, в интересах ведущих стран, чтобы подобный расклад сохранился, и они его старательно поддерживают. Ибо ядерное топливо - ресурс ограниченный. Кто успел тот и съел. Кто не успел - дерется за газ. Кто за газ драться не может - мерзнет.

Мне лично DSL и символьные вычисления видятся концепциями ортогональными, независимыми друг от друга. Ну т.е. для символьных вычислений конечно хочется использовать удобные DSL а DSL реализовывать с помощью символьных вычислений, но это возможности, которые слабо ограничивают развитие друг друга. Все же создание DSL - это очень затратное занятие, тулзы тут мало помогают. Т.е. персонально для себя я могу легко сделать DSL и без тулзов. Но для коммуникации с другими (и с самим собой в будущем) DSL сделать трудно, и никакой инструментарий тут не поможет. К примеру, Сан когда добавлял в Джава дженерики (что-то типа Сишных темплейтов), заказывал какому-то университету доказательство корректности. И все равно у них кривовато получилось. А ведь это изменение даже на DSL не тянет. Создание массового языка - это очень и очень сложная задача до сих пор. А маленький язычек для узкой группы всегда было не так уж и сложно сделать. Я к примеру часто одну и ту же проблему решают 5-10ю разными способами с применением разных языков и методологий, чтобы четко понимать задачу. Потом все выбрасываю нафиг, пишу на Жабе - так привычнее.

Мне кажется, что тут не хватает обобщающей постановки вопроса -- с одной стороны, в таких терминах, чтобы охватывать и "традиционные DSL", и символьные вычисления, и прочую компиляторную тематику, и вопросы метамоделирования, а с другой стороны -- чтобы можно было выходить на какие-то облегчающие жизнь архитектуры IDE. Идея тут в том, что сами DSL имеют версии (и сегодня развитие DSL обязательно подразумевается в инструментарии! Это явно оговаривается, что у DSL есть жизненный цикл). Поэтому маленький язычок для узкой группы имеет шанс стать успешным и использоваться более широкими группами. Ну, и все то же самое, что относится к любым стандартам: конкуренция предметных языков, различные их группировки, реализация семантики/абстрактного синтаксиса путем вмазывания в другие конкретные синтаксисы и обильного посыпания синтаксическим сахаром, попытки неожиданного применения в совсем других областях (так, автор Tcl меньше всего ожидал, что на нем начнут писать программы общего вида, для него этот Tcl был именно что DSL для командных применений) и т.д. Нужно сделать язык, на котором можно было бы конструктивно обсуждать весь этот сложный круг вопросов. А то сейчас тут как с моделированием данных (которое называется и онтологиями, и моделированием данных, и семантическим вебом, и созданием схемы базы данных, и чем только не называется, в зависимости от тусовки -- это отмечается в книжке Andries van Renssen по Gellish).

Согласен. С другой стороны, такое разнообразие взглядов порождено разными требованиями и ожиданиями к DSL. Ну и опытом использования отдельных аспектов. Т.е. надо четче прояснить требования к DSL. К примеру, у меня основная польза от DSL и других передовых языковых/символьных конструкций - глубокое понимание требований. После понимания, можно примерно тоже закодировать и на обычной Жабе, даже в более-менее функциональном стиле. Просто в процессе анализа с помощью передовых методов будет получено простое и эффективное представление и это окупает использования сиих тулзов даже без получения соответствующих артефактов. С другой стороны, получить и интегрировать в промышленный процесс какие-то жизнеспособные артефакты получается слабо. Лучше всего получается нагенерить тестов/входных файлов. А массовое использование DSL и символьных вычислений безусловно подразумевает такую интеграцию. И тут есть куча технологических трудностей (довольно мелких на мой взгляд) и куча мировоззренческих трудностей (с которыми уже сложнее). Как-то в стать про Aspect-Oriented Prograaming я прочитал, что основная проблема внедрения этой методологии - адекватное тестирование. Действительно, если мы используем какую-то мощную идеи и генерим кучу кода небольшими усилиями, то встает вопрос - а как все это барахло протестировать? Ну т.е. часть проблемы решается на уровне мощной идеи - сама возможность высокоуровнего моделирования решает кучу проблем, но проблема конечного тестирования все равно остается. Учитывая что тестирование занимает 60-80% всех усилий на создание ПО, то получается что в результате применения мощной идеи, проблема тестирования лишь усугублется, ибо тестирование уже занимает 95% времени. К примеру, я недавно писал быстрый покерный калькулятор и я в основном писал тесты и код, который помог бы мне убедится что я считаю то что нужно, ибо перебирая 133 млн комбинаций, легко что-то упустить из виду. Резюмируя, DSL - это хорошо, символьные вычисления - хорошо, вопрос - как все это барахло приводить в соответствии с реальными требованиями? Имеется в виду как это делать технологически - тестирование, верификация, валидация. Т.е. практически мощной идеей является не сама DSL или там еще какая штука, а технология проверки результатов на соответствие целям заказчиков. А коротко даже так: есть технология тестирования - есть и возможность реализации мощной идеи. Наоборот - не обязательно верно.

Я, вроде, так и пишу: технически и методологически самое трудное -- это интеграция разных DSL в рамках одной IDE (технологически) и в рамках одной задачи (методологически). Про трудности квалификации (общее слово для валидации/верификации, а они в себя включают тестирование) ежели сами требования (а код -- это требования, да и код тестов -- это уж точно требования) я совершенно согласен. Мне кажется, что методически тут нужно что-то менять: даже различалка "валидации-верификации, включая тестирование" внутри квалификации мне кажется не слишком работоспособной. Опять же, разделение функциональных и конструктивных требований тоже полезно, но не слишком. Уровни абстрактности описания (стек метамоделей) как "детализация требований" тоже не работает. Разделение на код задачи и код тестов -- тоже странное. Доказательства -- будем доказывать то, что не соответствует намерениям клиента (например, докажем, что не будет внутреннего останова процессора, у которого система команд не нравится пользователю). Все тут плохо, нужно серьезная разборка с онтологией квалификации, и эта разборка с самого начала должна учитывать, что все записи делаются на различных связанных друг с другом DSL, в том числе неполнотьюринговых. Я думаю, что через эту точку (DSL-модели во взаимосвязи с их ) моделецентрическая системная инженерия может существенно поменяться по сравнению с "традиционной" системной инженерии с точки зрения процессной онтологии. Я бы с удовольствием сделал на эту тему рабочую группу русского отделения INCOSE (собственно, в четверг будет первая попытка как-то прообсуждать эту тему), но непонятно, кто еще заинтересован обсуждать подобную проблематику.

> Доказательства -- будем доказывать то, что не соответствует намерениям клиента (например, докажем, что не будет внутреннего останова процессора, у которого система команд не нравится пользователю) Верификация настолько трудоемкое занятие, что его просто так никто не делает. Это либо явное требование клиента. Либо явная инициатива разработчика под свою ответственность. Т.е. если доказывают что нет внутреннего останова, значит есть требование, чтобы проц был ну очень надежный. А это требование есть независимое от требования удобства команд пользователя. Т.е. если так вышло система команд пользователю не нравится, то это проблема где-то в другом месте, а проводить доказательство корректности надо было по любому. Далее, результаты верификации повторно используемы по большей части. В частности это касается понимания требований, но и доказательства можно повторно использовать. В третьих доказательство - отличный способ анализа требований. Т.е. куча проблем в дизайне будет выявлена на ранней стадии. Проблема того, что система команд не нравится пользователю выявлена не будет, но повторюсь, это другая проблема, к задачам верификации не имеющая отношения. > Я думаю, что через эту точку (DSL-модели во взаимосвязи с их ) моделецентрическая системная инженерия может существенно поменяться по сравнению с "традиционной" системной инженерии с точки зрения процессной онтологии. Я тоже в этом уверен. Т.е. к примеру рассматривая проблему верификации, я считаю, что ее имеет смысл проводить в любом случае когда это возможно, соблюдая бюджетные ограничения естественно. Ибо верификация хорошо выявляет принципиальные проблемы дизайна. Т.е. проверифицировав ограниченные модели на ранних этапах, можно избежать дорогих ошибок на более поздних этапах. В терминах рисков, можно сказать так: если бюджет позволяет, то нужно потратить кучу усилий на профилактические мероприятия как можно раньше, ибо ранние ошибки самые дешевые. Мне кажется это важное отличие от традиционной системной инженерии (как я ее понимаю) - некоторых "лишних" усилий не нужно избегать, наоборот нужно их наращивать в пределах разумного. Если потом выясниться, что их провели "зря" - то это хорошо, ибо "зря" и есть результат профилактики.

Еще камент в догонку: может так получится, что даже требование надежности более приоритетное нежели требование удобства пользования. В сфере безопасности, удобство и надежность - противоречивые требования зачастую.

По поводу соотношения DSL и символьных вычислений. Различные методы символьных вычислений можно рассматривать как своеобразный DSL над системой перебора вариантов. Т.е. внутри любой технологии символьных вычислений лежит массовый перебор вариант, только оптимизированный под какой-то математический домен, будь то булева логика, или логика с ограниченным кол-вом переменных и конечными доменами (constraint satisfaction problem) или первопорядковая логика с какими-то теориями в ее рамках. А для удобства пользования этим движком есть интерфейс, который можно считать DSLем. Далее, в современных тулзах по поддержки DSL символьные технологии играют огромную роль. Т.е. весь интеллект этих тулзов начиная от IDE кончая компиляторами базируется на символьных вычислениях, порой весьма мощных и ресурсоемких. К примеру релизы Eclipse уже год включают в себя Sat4J джавовскую SAT библиотеку, которая нужна для управления конфигурациями плагинов. Ну и третий момент, автоматическое тестирование тоже по сути основано на символьных технологиях и тоже в какой-то мере использует DSL как сугубо тестовые (инварианты, пре-, пост-условия), так и относящиеся к решаемой проблемы (типа Mock объекты).

> Все тут плохо, нужно серьезная разборка с онтологией квалификации, и эта разборка с самого начала должна учитывать, что все записи делаются на различных связанных друг с другом DSL, в том числе неполнотьюринговых. Согласен, особенно в том, что дефакто в продвинутых системах тестирования (квалификации) используются DSLи. Скажем, я обычно делаю более менее формальную модель тестируемого объекта, отличную от моделей используемых для целей спецификации/разработки. Т.е. эта модель уже типа как DSL. Далее, для генерации тестов тоже нужна DSL. Можно придумать еще, две это как бы минимум. Причем они подчинены сугубо целям тестирования, т.е. слабосвязаны с другими описаниями - в том смысле, что невыводимы автоматическим способом из них, хотя когда более общие требования меняются, их конечно надо пересматривать. Но это обычно требует участия человека.

> Я бы с удовольствием сделал на эту тему рабочую группу русского отделения INCOSE (собственно, в четверг будет первая попытка как-то прообсуждать эту тему), но непонятно, кто еще заинтересован обсуждать подобную проблематику. Непонятно совершенно, ибо Вы наверное единственный человек за 15 лет, с кем у меня есть пересечения по данной тематике, и то неполные, потому как Вы системной инженерией в целом занимаетесь, а я больше софтовыми аспектами. Ну т.е. в литературе конечно можно найти упоминания и проекты в мире есть, а так чтобы вживую мне встречать не приходилось. Нельзя сказать, что это массово востребованная сфера :).