Обсуждение

-- о жути таблично-формовых мастдайных интерфейсов (или у вас абсолютно единообразный ужасный таблично-формовый интерфейс, или единообразные команды с не пойми какими ключами, или вам нужно учить десятки удобных текстовых и графических DSL -- которые вы просто не сможете все запомнить. Что делать?) А есть идеи, что делать? Собственная звучит примерно так: - графическим интерфейсам не хватает явной семантической нагруженности - таблички, поля и опять таблички - вся семантика находится в структуре таблиц и последовательности действий; - dsl не хватает детерминированности и учета динамики - заранее извиняюсь, я в dsl не зарывался, но все, что видел, было либо текстовыми языками, либо нотациями. если у кого есть существующие примеры других видов языков - сообщите пожалуйста; - нотациям, как форме dsl, нехватает еще и удобного управления - контекстные меню и те же формы с табличками - это ужасное зло. Рецепт решения: смешать и взбить. Нужен интерактивный графический язык (aka нотация с продуманным интерфейсом). Графический - потому что мало систем работают в одном измерении (а любые тексты хорошо подходят только для одномерных случаев, так как единственное явное отношение - «последовательность», остальные являются производными интерпретации текста). Язык - потому что с семантикой.

Уйти от процессов проектирования, похожих на бумажные, российским производствам будет боязно -- дураков переучиваться на старости лет нетути. Вот это и есть основная проблема. Нельзя автоматизировать без существенной переработки процессов. В Реинжиниринге Корпорации это явно говориться - если нацелиться на небольшие улучшения, реинжиниринг ждет крах. Нужно обязательно целиться на коренные изменения. Оно вобщем-то понятно: автоматизировать бумажный процесс в деталях очень дорого, в силу того что бумага от компьютера отличается. Надо заменять бумажные варианты решения проблем компьютерными. А что касается дураков, я тоже потихоньку пришел к выводу, что старого пса новым шуткам не выучишь. Т.е. перспективы, мягко говоря, невеселые.

Рецепт решения: смешать и взбить. Нужен интерактивный графический язык (aka нотация с продуманным интерфейсом). Графический - потому что мало систем работают в одном измерении (а любые тексты хорошо подходят только для одномерных случаев, так как единственное явное отношение - «последовательность», остальные являются производными интерпретации текста). Язык - потому что с семантикой. Оно конечно все правильно, только я боюсь что специалистов, способных это реально осуществить на практике (продумать нотацию, интерфейс и реализовать их) крайне мало. И вряд ли им интересно заниматься промышленными решениями. ЗЫ Я вот для верификации тоже бы хотел нотацию с продуманным интерфейсом. У меня даже идеи и задумки есть. Только вот реализовывать совсем не охота.

о жути таблично-формовых мастдайных интерфейсов (или у вас абсолютно единообразный ужасный таблично-формовый интерфейс, или единообразные команды с не пойми какими ключами, или вам нужно учить десятки удобных текстовых и графических DSL -- которые вы просто не сможете все запомнить. Что делать?) Теоретически, существуют подходы, которые позволяют решить проблему: агентское программирование, функционально-реактивное (интерактивное), логическое/в ограничениях. На практике, как я уже писал, нет людей (крайне мало), которые бы смогли и согласились бы за это взяться. И профинансировать/променеджерить - тоже. Т.е. тут образовательно/фандрайзинговая проблема, по моему мнению: нужно подготовить людей и нужно собрать кучу бабок на все это дело (причем не венчурно-кредитных, а нон-профит).

У меня даже идеи и задумки есть. поделитесь с общественностью? =)

Боюсь что трудно будет объяснить. Все-таки верификация специфичная область. Но если в общих чертах, то: 1. нужно сделать обратную трансляцию из логических формул в конструкции целевого языка. Т.е. при верификации код программы определенным образом кодируется в логические формулы, но эти записи читать довольно-таки геморройно. Правда, для выражения некоторыъ формул, оригинальный язык нужно будет несколько расширить. 2. нужно сделать упрощение логических формул. Текущее состояние доказательства, либо контр-пример - это обычно куча формул, многие из которых лишние, многие вспомогательные. Вобщем, из них можно выкинуть кучу хлама, который только отвлекает, но избыточен для понимания сути. Это не всегда просто сделать, но какие-то эвристики можно сочинить. 3. графические интерфейсы более-менее разработаны, но какие-то мелкие улучшения можно придумать. Плюс надо интерфейс для сепарейшн лоджик.

А если бы вы писали про это в блоге, я бы например подписался, может даже понял бы и какие-нибудь умные мысли сообщал.

Если в терминах СПО по 1-му пункту - прямая и обратная трансляция (налету и кусками) между языками боле высокого и низкого уровней?

Не совсем. При верификации, генерируются так называемые VC - verification conditions. Т.е. теоремы которые нужно доказать, и если все теоремы верны, значит прога соответствует спецификации. Условно говоря, каждый путь в программе преобразуется в набор конъюнкций, где каждая конъюнкт ограничивает множество возможных значений переменных. В частности, там кодируются массивы и всякие вспомогательные конструкции. Вобщем получается много мусора, в котором трудно разобраться. Но из этого мусора, можно сделать обратную трансляцию, что-то типа стэк-трейса, только значения переменных задавать символически - в виде ограничений на их значения.

Дык желания нет, я выше писал. В каменте по поводу я еще могу отписаться, а вот трудиться над этим уже не охота.

А как эти три подхода (агентский, интерактивный, логический) помогают решить проблему с нотацией? Ведь речь тут не о том, чтобы софт отдавал человеку в разных нотациях один и тот же информационный объект (современные language workbenches, кстати, именно этим и хвастаются). Речь идет о том, чтобы люди умели со всеми этими нотациями работать. Есть, правда, и такой ответ: одна из этих нотаций будет для всех-всех ("ассемблер" одного из помянутых трех подходов, как и сегодня), а другие, более высокоуровневые -- их будет много, но будут использоваться разными людьми, и проблемы по факту нет.

Ключевой момент тут -- нумер раз. Для императивных языков это не всегда просто (например, супероткомпилированная программа, я не уверен, что может быть супердекомпилирована обратно в похожий на первоначальный код, в котором можно разобраться), а уж для других парадигм и подавно может быть затруднительно.

Для верификации тут проще. Там кодируется относительно просто в ФОЛ.

Современные интерфейсы дебильные потому что дебильны методы их создания. Сделать что-нить сложнее таблично-формочек весьма затруднительно. Таблички/формочки вообще говоря тоже, просто уже есть хорошие библиотеки и из них они легко тяп-ляпаются. Но возможность создания библиотек определяется возможностями языка. Для более современных динамичных, сильно-контекст-ориентированных интерфейсов нужны другие методы программирования, тогда можно сделать хорошие библиотеки, иначе нет гибких абстракций для нужной выразительности. Т.е. эти подходы дают новые возможности для создания новых парадигм интерфейсов. Которые уже не будут единообразны, а будут сильно зависеть от контекста и адаптироваться к уже введенной информации/потребностям юзера.

Не, это совсем не так. Сначала нужно знать что сделать, а потом происходит гораздо более простая работа по придумыванию как это реализовать. Например, "оконные" интерфейсы, они ж вообще гениально были придуманы по сравнению с текстово-командными. Где-то в 80е, и до сих пор принципиально ничего не изменилось. (А "таблички" в окнах наверно можно сказать из дооконных интерфейсов наследство). Что можно представить сопоставимое с переходом от текстово-командных интерфейсов к графическим-оконным? Меня вот на какие мысли наводит. Какбы рабочее название "Аналоговые системы счисления". Например. Опубликовал у лингвистов http://community.livejournal.com/terra_linguarum/645910.html. Может что-то интересное скажут, если не удалят модераторы. Там картинко Изображение «картинко» — открыть источник (Пытался нарисовать все и-е-языки, но чото поднадоело, половина только) Формы линий-областей могут ведь очень много информации отображать, причём в форме, доступной даже ребёнку. У человека мозг рассчитан на обработку большого количества визуальной информации, а текстовые представления наоборот несут в себе мало информации и воспринимаемы только после длительной дрессировки.

Не, это совсем не так. Сначала нужно знать что сделать, а потом происходит гораздо более простая работа по придумыванию как это реализовать. Есть такая гипотеза Сепира-Уорфа: язык определяет мышление и восприятие мира. Если вы мыслите в объектно-ориентированной парадигме, то вы придумываете таблично-формовые интерфейсы.

Полезный пост, спасибо. Мне сейчас по долгу службы приходится разбираться с платформой Dassault, на предприятии-флагмане спутникостроительной промышленности страны... Буду частично автоматизировать проектирование спутников. Я сам к проектированию отношения никакого не имею, я программист. Подскажите, в какую сторону покопать, какие ресурсы почитать, чтоб побыстрей разобраться с тем, как с CATIA работать проектантам, как это делать правильней в плане методологии.Я сам к проектированию отношения никакого не имею, я программист. Но сейчас придется такую задачу осилить.

Я бы начинал копать не с CATIA, а с ENOVIA. Главное -- это процесс системной инженерии, а процесс сидит не в CATIA, а в ENOVIA. Увы, в России про это практически не говорят, а сие сокровенное знание по методологии использования находится в R&D подразделении Dassault Systemes и через сейлзов на территории страны пока не проникает. Мы выдали несколько дружеских советов сотрудникам российского офиса ("внедряйте не софт, внедряйте системную инженерию" -- у них ведь это заложено в сам продукт, нужно только воспользоваться!), дальше нужно будет смотреть, восприняли ли они этот совет. Вообще, эти САПРы очень сложны, так что "по телефону не вылечишь".

И согласен и нет. Да, дело в мышлении. Но, нет, языки здесь не причём. (Гипотезы про естественные языки малоприменимы к ЯП). Там вот пообщался по поводу этой картинки выше с лингвистами. Все говорят про "деревья". Ну как можно говорить что деревья лучше? Тут же в сотни раз меньше информации помещается, и в гораздо менее приятном человеку виде. Плюс, все эти группы вообще искусственно-человеком придуманные разделения, а графически можно было бы как-то реальное положение дел показать независимое от названий/разделений. Просто люди привыкли с детства видеть одну схему, и тяжело представить что-то принципиально другое. С интерфейсами тоже - привычные штамповые вещи набросать легко, а вот придумать что-то новое, более мощное, при этом и ребёнку интуитивно понятное очень не просто. Да и реализовать это может быть в сто раз сложнее.

И согласен и нет. Да, дело в мышлении. Но, нет, языки здесь не причём. (Гипотезы про естественные языки малоприменимы к ЯП). Применимы. Дело в том, что идея (которую нужно запрограммировать) должна быть реализуема. Иначе ее обсуждать смысла нет (кроме случая шизофрении). А как определить реализуемость? Тут включается интуиция, а она определяется опытом, навыками программирования. Соответственно, если программер имеет объектно-ориентированный опыт, то он бессознательно оценивает реализуемость идеи с помощью ОО конструктов. Но кроме того, сами идеи приходят исходя из практического опыта, т.е. идеи о том что сделать тоже приходят исходя из обобщения опыта манипулирования ОО шаблонами. Вообще, тут можно и на глубинную психологию перейти - интериоризация объектов, в определенный период созревания детской психики (замещения внутренним объектом матери/кормилицы). Если такие внутренние объекты начинают доминировать в психической жизни, то это кагбэ называется неврозам, ибо внутренние объекты не адекватны реальным. Поэтому более адекватно функциональное мышление, т.е. это уже приносит динамику - объект статичен, функция динамична.