Обсуждение

Графические языки просто тупо очень не компактные. Когда программный код на килобайты, графический код раздувается на квадратные метры монитора. Когда на мегабайты — графический на гектары, это просто не обозримо. На том и горит... Второй серьёзный минус — способ ввода. Мышкой таскать примитивы с палитры и искать в гектарах простыни элементы — по сравнению с вводом с клавиатуры, это как чайной ложкой черпать море. На том пепел от затеи развеивается вовсе.

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

Ну вот "инфографика" это и есть "генерация представлений независимо от генерации смыслов" ))) Суть же поста в том, что наиболее интересным вариантом для старта проекта может быть embedded DSL в Julia, а уж диаграммы там можно потом (как справедливо замечено) генерировать сбоку и потом. В Modelica там диаграммы хитро получались аннотированием, можно подождать, чтобы поглядеть, что с диаграммами сделали в Jilia DSL Modia (они там пока до этого не дошли, но ведь дойдут -- утопия ж себя обязательно проявит! Инженеры без картинок не понимают, им кажется, что так полегче будет, рулит perceived learning curve, а не actual learning curve).

всё правда. работает иногда гибридный метод - когда в текстовый мегадокумент забрасывается невод, который селектирует нужный кусочек и строит графическое представление только по нему. но и тут резкое падение восприятия происходит сразу после превышения магического количества элементов в 7±2 единиц штук. ну или обратный - когда в графический мегадокумент забрасывается невод, и лишь конкретный кусочек представлен в текстовой нотации, которую возможно относительно оперативно править руками.

EDSL для списков/деревьев фактов это builder из .15926. Его можно включать в разные языки, и отличия будут лишь синтаксические. Вопрос в том, куда эти факты потом девать. Потому что Вася занимается всяким exploratory на Julia, у Пети аналитическая система на Python, а у Коли промышленная числодробильня на C++, которая специально собирается только интеловским компилятором, дабы выжать финальные проценты скорости с вычислительного кластера. То есть, "внутри" уже было в .15926. Но для "между" там были лишь неэффективные технологии из самого стандарта.

Ну да, я понимаю, что в .15926 было много чего интересного сделано. С точностью до ограничений самого Питона и ISO15926-2 (хотя последние версии .15926 были существенно сдвинуты и к работе с "просто OWL" как родным). Кстати, на Julia особое внимание обращают на то, как быть липким к другим языкам. Всякие там wrappers и намеренно оставленный интерфейс объектных модулей "ровно тот, что у С".

Опубликовал версию 1.0 нотации туннельного моделирования: https://habr.com/post/414861/ Возможно, найдутся интересные идеи. По крайней мере учебник системноинженерного мышления на иллюстрации разложить удалось :)

Ну, RDF и OWL для практически любых данных _сильно_ неродные, что даёт машинные и когнитивные потери, и в результате приводит к фейлам проектов их использующих. В принципе, любая база данных это специализация документной. Снижение гибкости ради упрощения оптимизатора запросов. В SQL вместо документов кортежи, в SPARQL - триплы, etc. Но есть нюанс, что современные имплементации SQL пытаются решить проблему недостаточной гибкости путём введения json/jsonb типов и индексов над ними, а в semantic web тусовочке просто делают вид, что "проблемы нет". Пример с интерфейсами Julia несколько не про это, он про внутрисистемное, а не междусистемное.

Есть тема с полувековой историей — программирование промконтроллеров (ПЛК). Живут на белом свете графические языки FBD, SFC, LD тот вообще с царских времён существует. С их текстовым представлением какие-то непонятки, лично я не встречал толковых текстовых/двухрежимных тулчейнов. С _удобными_ текстовыми форматами описания Finite State Machines лично я тоже ничего удобоваримого не обнаружил. Подозреваю, что плохо искал (VHDL Verilog не предлагать, мы за них помним ;).

Дык триплеты вроде максимально гибки, потому и проблемы нет. Не?

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

/// Да ладно вам, граф переходов конечного автомата, как и любой граф, прекрасно записывается текстом! /// Это в учебных примерах всё выглядит легко и красиво. И только для случаев "объект-система" (все любят лифт расписывать). А если надо описать не систему, а среду, то всё гораздо хужее. Там же по соседству есть ещё другая "FSM", которая не Finite, а Fuzzy.

Нет. В современных документных и реляционных СУБД можно настраивать основные представления и индексы под определённые сценарии использования. В триплсторах же представление фиксировано и неэффективно практически для всего, требуя как неадекватных машинных затрат на разбиение/сборку из триплов, так и когнитивных затрат на создания мэппинга в трипловое представление. Даже EAV с единицами измерения может мэппиться разными способами, с разными сопутствующими проблемами. И я сомневаюсь в существовании сейчас хотя бы одного практического юз кейса для триплсторов. Реляционки гибче и быстрее.

Справедливости ради: колоночные БД/хранилища пожалуй ближе к триплетным.

Нет триплсторов с индексами?? Хм

Колоночные - практичное решение в своей нише, оптимизация под кейсы реальных данных. В отличие от триплсторов, которые для всего одинаково (плохо).

Читайте внимательнее. Там есть индексы, которые так же прибиты гвоздями, как и внешнее представление. Какие именно - зависит от схемы конкретного триплстора. Но дополнить это вы не можете.

/// В отличие от триплсторов, которые для всего одинаково (плохо). /// А графовые/гиперграфовые движки не на триплетах хорошо строятся?

Возможно. Например, Cypher (Neo4j) не только заточен под определённый класс задач, но и поддерживает пользовательские индексы. Но с ним, в отличие от реляционок или триплсторов, я не работал, так что оценить и сравнить не могу.

Кстати, раз ушли так далеко, а какая именно кривизна с индексами в триплсторах (и/или в каких именно) вас так заряжает? У меня почти практический интерес — рано или поздно придётся креативить гиперграфовый движок (я пока что только поливаю грядки, авось что-то прорастёт).