Обсуждение

Не все из этих альтернатив удовлетворяют "хотелкам" http://ailev.livejournal.com/1127145.html Или эти потенциальные плюшки уже отранжированы по важности? Думаю, в первую очередь нужно определиться с направлением: "совместно с менеджерами сползать" или "совместно с программистами заползать"

Эти хотелки были прописаны для варианта 5 (функциональные паттерны). Но с тех пор появилось и много других идей и пониманий. Про "к менеджерам и практикам" против "к инженерам и мультифизике" -- это правильно говорите, это развилка.

Уже есть самые общие требования к моделям (как к результату) и моделированию (как к процессу) и моделеру (как к инструменту)? Например: - "модели должны быть проверяемы, исполняемы и компилируемы, чтобы научить строить системы и проверять их" (с) vit_r - "моделирование должно быть как крупноблочным, чтобы любой инженер мог легко и быстро составить простую но объёмную модель из библиотеки справочных данных, так и детализированным до уровня мультифизики, чтобы инженер мог пусть трудно и долго, но составить сложную нетиповую часть модели" - "графическое представление модели должно генерироваться из текста автоматически, но должна быть и возможность получить читаемый текст модели путём манипуляций с графическими примитивами, то есть должно быть взаимно однозначное соответствие между графическими и текстовыми объектами" - "модельеру должны быть доступен ограниченный, но централизованно расширяемый набор аспектов и нотаций модели, чтобы нужную модель можно было легко получить одним стандартным способом (и очень трудно нестандартными), во избежание появления несовместимых между собой моделей одинаковой семантики" - "инструмент не должен решать ни одной частной задачи вычислительного моделирования (для этого есть и будут специнструменты), но должна легко склеивать все результаты их решения, а также должна решать задачи информационного моделирования" - "должны быть поддержаны как сценарии интеграции, так и федерирования моделей" ...

Нет, так подробно прописанных нет (и даже представленные тут спорны -- так, есть языки "всё только одним способом" и есть языки "всё многими способами", успешны бывают оба типа, но это даже не обсуждали пока). Но из требований к моделеру есть, например, http://ailev.livejournal.com/1041274.html (очень непростые требования, кстати). И отдельные заметки с требованиями типа http://ailev.livejournal.com/1122497.html Но правда в том, что это ни разу не напоминает ни инженерию требований ни даже управление требований. Ни приличных use cases (или хотя бы user story), ни GORE, ни даже списка требований как issues в одном месте пока нет. Сапожник без сапог ))) Спасибо за критику! ))) Главное, есть с чего начать, материала-то уже немало! Но пока решается главный вопрос: кому оно надо и зачем. Позиция пользователя и его concerns. И интрига последней недели тут -- социальные, а не "рациональные максимизации пользы" соображения. Ибо если дитёнку ПОТРЕБНО горькое лекарство, то не факт, что дитёнка БУДЕТ ЕГО ПИТЬ. Выборы языка и моделера, похоже, в большей мере делаются дитёнками, чем чисто рациональными взрослыми. Так что нужно притормозить и хорошо-хорошо подумать, как подсластить пилюльку и суметь это объяснить.

Не сочтите за Капитана Очевидность, но без таких требований непонятно как выбирать архитектуру - нужно элементарно их прочеклистить. По ссылкам же приведены заявленные цели и задачи, видимая выгода, а также критерии сравнения ожидаемого решения с прочими. Не хватает именно что выбора и приоритезации этих критериев. Нельзя же объять необъятного. "Кому" и "зачем" - это такая же вилка, как "сползать" vs. "заползать". Мой опыт тоже подсказывает, что выбирают (если без отката) инструменты по легкости освоения, быстроте получения первых результатов, невысоте ступенек для движения "вширь" и "вглубь", интегрируемости с привычным (excel, xml/xsd, posix, graph utils, ...), интуитивности для простых действий и логичности для сложных цепочек. Думаю, примерно таков рецепт подсластителя - мягкое погружение, сопровождаемое постоянным расширением перечня "плюшек". Чтобы начать могли массы, а закончить яйцеголовые.

Вы абсолютно правы. Просто есть два варианта: 1. инженерная задача. Заказчик понятен, пользователь понятен, требуется нарисовать требования, выбрать архитектуру -- и вперёд. 2. предпринимательская задача. Заказчик непонятен, разработчик непонятен, требуется нащупать окно возможностей. Начиналось оно как инженерная задача, составлялись списки требований и чеклистились (в agile чтобы начать с чего-то, а потом расти в фичах от релиза к релизу). Сейчас же задачу рассматриваю больше как предпринимательскую, поэтому неопределённость архитектуры тут уравновешивается неопределённостью стейкхолдеров. Увы, "алгоритма предпринимательства" нет, так что ползаем в тумане без радаров и чеклистов. Но более-менее общие требования к моделерам и языкам, конечно, есть. И постановка задачи заведомо большей, чем можно сделать, тоже есть. В какую сторону делать постановку задачи реалистичной, на какой объем исследований замахиваться -- вот в чём вопрос. Чтобы проект был успешен, он должен удовлетворить стейкхолдеров. Стейкхолдеры должны поддержать проект. Вот поиск таких стейкхолдеров и модификация проекта в эту сторону сейчас выходят на передний план. Ибо всех не осчастливишь, универсальный моделер не построишь.

>> от идентификаторов перейти к десигнаторам Если поддерживать вариативность (http://ailev.livejournal.com/1038571.html) то придётся решать проблему отношения "многие-к-одному" между ними

>> упрощение/умощнение моделирования по линии отплытия от языков программирования к чему-то доступному для не-программистов экселеподобному (опять же, забыли о факт-ориентированности) Почему забыли? А как же Gellish Table?

Ну, базовое различие -- идентификаторы обозначают что-то в тексте модели, а десигнаторы обозначают объекты в мире. У нас был небольшой спор с justy-tylor: он утверждал, что в языке должны быть идентификаторы, а десигнаторы должны идти значениями и текстовыми строками (в кавычках). Я же выдвинул гипотезу, что в языке моделирования мира главные (без кавычек) имена должны обозначать объекты мира, а не объекты самого языка. Поэтому нужно попробовать сделать язык с десигнаторами, язык моделирования (а программирование держать сбоку, в кавычках или скобках, на полях и т.д.). Конечно, десигнаторы для product lines -- это отдельная история. У нас было понимание, что реализуем десигнаторы из IEC 81346 настолько близко к тексту, насколько можно. А потом начинаем разбираться, что жмёт, какие варианты (первым вариантом шли десигнаторы для информационных объектов/документов/описаний, которые приписываются после амперсенда к десигнатору системы. Product lines, варианты для tradeoff studies и прочие изыски множественности описаний мы откладывали на потом). Прошедшее время пишу только потому что это всё рассуждения времён "функционального паттернового языка".

С одной стороны, хорошее напоминание. С другой стороны, эта форма представления хороша для обмена данными, машинного представления. Но не очень хороша для собственно деятельности моделирования, когда нужно сочинять модель и исследовать её по ходу сочинения. Я видел, как плохо было работать по методе TabLan (она как раз опиралась на умный эксель) и развитию этой методы. Но в нарисованном у нас "бесконечном дереве" и с использованием паттернов данных было уже много легче работать, чем с табличками. Заполнять готовые таблички данными по индивидам легко, трудней их разрабатывать! Но помнить о Gellish Table, конечно, нужно. Gellish жил, Gellish жив, Gellgish будет жить!

В простейших случаях можно будет выкрутиться, например =EM* для возможных =EM1, =EM2, ... , =EMn, или даже =EM(2-4) для "=EM1,=EM2", "=EM1,=EM2,=EM3", "=EM1, =EM2,=EM3,=EM4". Но для выражения совместимости конфигураций, опций и частных случаев, "матрёшечности" типовых наборов, придётся разрабатывать собственную систему обозначений для концептов, которые по мощности уже чем классы, но шире чем индивиды.

Я понимаю, что непосредственно работать с Gellish Table неудобно и трудозатратно. Видимо, поэтому Andries van Renssen и продавал свой Gellish Engine/Browser/Editor. Но сама идея Gellish очень хороша, что "модель - это таблица". Прикрутить к ней дерево, граф(-ику), и уже можно будет работать, без программирования, на одних лишь "кучерявых данных" с полным профитом от факт-ориентированности.

Если "прикрутить к ней дерево, графику", то тогда передавать данные можно в любом формате, таблица не нужна уже. Я же обсуждаю формат языка модельера, а не формат для программиста-ответственного-за-пересылку-и-хранение.

Да, через десигнаторы конечно будет удобнее, чем через ячейки таблицы.

Я вообще против использования несмысловых обозначений (типа тех же IEC 81346). Их миссия "впихивание всего и вся в куцые ячейки бумажных таблиц" давно закончилась. Сейчас можно использовать человекочитаемые идентификации сущностей и множеств: RadioModule.Capacitor123, article("ailev", "2015-02-26", "SysMoLan: альтернативы"), etc.

Электронные таблицы от бумажных таблиц не сильно отличаются в смысле куцости. И там рекомендовано пару-тройку первых уровней функций кодировать семантически (правда, это не столько функции, сколько дальние намёки на них, но всё же -- хоть какой-то контроль типов). Плюс не нужно придумывать 4-5 миллионов осмысленных имён (боюсь, это главный аргумент), а предложенный классификатор -- это возможность использовать имена типа Иван Петрович сын Василия Сидоровича, где все имена и фамилии хорошо знакомы, трудно ошибиться и нет соблазна по имени догадываться, что там за деталька такая, и ошибаться при этом по-крупному. Ну, и одинаковых винтиков опять же миллионы, на них можно экономить в плане сочинения имён. Вообще, с именованием 10 млн. сущностей в 3 аспектах минимум (плюс имена их описаний), при этом именование раскидано по 10тыс. контракторов по 1тыс имён от каждого -- вот с таким мало кто разбирался. Инженеры нахлебались всяких обозначений (и несмысловых, и осмысленных), придумали IEC 81346. В больших масштабах "осмысленные обозначения" не знаю, чтобы кто-то тестировал. А эффекты масштаба могут быть, легко.

Идентификаторы - штука деятельностная. Написал my_capacitor = RadioModule.Capacitor123 или my_capacitor = iec("...some IEC 81346 code...") и работаешь с этим. На них свободно маппится всё что угодно. А на IEC 81346 мапить можно только вручную и через китайскую классификацию животных. Кроме того, в современных языках программирования нет идентификаторов/десигнаторов для большинства statements, expressions, subexpressions. Для диагностики и модификации исходников используются locations (позиции в файле). Для винтиков такой подход тоже может быть полезен.

В любом случае, десигнаторы моделирования и идентификаторы программирования для меня имеют существенно разные оттенки думания о них и употребления, хотя они и про одно и то же (именование, прямое или косвенное). Собственно, начиналось всё с ассемблера (символические имена для машинного кода и адресов -- это поначалу была единственная его роль, макросы потом появились), потом много чего было придумано в этом плане, и продолжает придумываться (так, давно забытая идея любых символов в именах появилась в Julia из-за потребности в греческом в математике, и быстро расползается оттуда по другим языкам). Может, нужно все эти хитрые приёмы с именами в явном виде выписать, как "микропрактики именования" -- часть из них пойдёт в моделирование, часть из них будет только в программировании. В IEC81346 я бы брал независимо три главных идеи: независимое именование аспектов и выбор основных аспектов, структурную иерархию с учётом множества поставщиков и несмысловые (порядковые) имена систем, слегка разбавленные парой уровней убогого (намеренно) классификатора. Плюс идея IEC 61355-1 Classification and designation of documents for plants, systems and equipment -- что каждое описание (документ) описывает систему, и поэтому его обозначение это просто продолжение обозначения системы. Залезание в именование элементов одного текста это уже про описания, т.е.61355. Смысловость-несмысловость десигнаторов и связанная с этим множественность классификационных схем в имени (нужно ли в имя засовывать тип -- большинство людей обозначают предметы именно так, не задумываясь: тип-номер_экземпляра. Курица номер 11, метиз 14. Но у других людей в голове вполне могут быть другие типы или уровень иерархии в подробной классификации-- Птица номер 11, болт 14) тут дело даже не первое. Меня волнует, есть ли какая принципиальная разница между именованием в языках моделирования внешнего мира, и языками программирования? Потому как одно дело иметь чистый язык программирования и "приговаривать" к его идентификаторам, что они обозначают что-то во внешнем мире, или иметь язык моделирования, про который сразу известно, что тамошние десигнаторы обозначают что-то осмысленное, иерархичное, многоаспектное во внешнем мире. Осмысленность и множественность классификаторов тут побоку, с ними потом можно разбираться.

>>так, давно забытая идея любых символов в именах Во всяком случае, в Python 3, который появился в 2008 году, в именах можно было с самого начала использовать любые буквенные символы любых языков. Пример есть у меня в py-opf. Думаю в Javascript это появилось еще раньше, хотя плохо знаю его историю. Ну и конечно уж в Go это было с самого начала.

И несмотря на это, я несколько раз встречал в разных работах явную отсылку в Julia. Может быть потому, что с Python 3 или даже Go математическая нотация мало использовалась, а в Julia какое-нибудь ро-тета запросто встречалось, плюс часты примеры демонстрации разных сердечек и смайликов как идентификаторов. Так сказать, "выдра это та же крыса, только пиар другой".