Заход на онтику ролевых/функциональных сущностях (или таки объектов?) в описаниях, проговариваю несколько возможных ходов: это типы, это affordances, это переменные (и ссылаюсь на свежий текст Валерия Крылова), и хорошо бы тут иметь и другие ходы, но пока особо нету. И ещё бонус: в Julia онтологическая проблема объяснения того, как решаются предметные проблемы в том или ином языке, и если приходит какой-то питонист в Julia, то разговаривать с ним нельзя, ибо у него в голове ролевые объекты предметной области уже заменены на конструктивные объекты из знакомого ему языка, а в Julia конструкты-то другие! А поскольку всё это про описания, то и разговор примерно такой же.

https://ailev.livejournal.com/1595281.html

Что за affordances?

Спасибо)

Вот у коллег в Julia неожиданно возникли вопросы по моделированию мира в структурах данных Julia. И там проблемы!

И разговор вышел на то, с чего начинался текущий чат: как моделировать реальный мир в структурах данных конкретного языка. Вот тут (начиная с реплики, что моделирование реального мира нельзя делать через иерархии и тем самым через наследование): https://t.me/JuliaLanguage/24718

отрывок из одного диалога.

Функциональные схемы автоматизации (ФСА)

Это все таки ФСА или схема автоматизации?
Извечный спор по определениям, большинство учебников дают именно такое обозначение ФСА. Схема без подвала чаще именуется "технологической", ее международный   аналог P&ID. В нормативной документации понятие "функциональная" не встречается вовсе. В этом и вижу проблему. В международном стандарте, там многое иначе.
Когда сдавал проект по  нефтянке, там документы делились на ФСА, схему автоматизации, технологическую схему. Все это было оправдано, ФСА - понятие из устаревшего РД, которое, тем не менее, действует.
Раз есть в учебниках, то придётся привыкнуть к этому названию. По ГОСТ по другому, но, возможно скоро не возьмут на работу если скажешь "Схема автоматизации"... И заказчик не примет и будет смотреть как на идиота - раз нее знает как выполнить ФСА, то не специалист...
Вставлю свои пять копеек. Все схемы так или иначе определяются ГОСТ 2.701-2008. И у любой схемы есть два кода - буквенный, обозначающий принадлежность к функциональному типу схемы, и цифровой, обозначающий назначение схемы и уровень декомпозиции. По этому стандарту нет понятия КСА, есть понятие Э2 - "схема электрическая функциональная", или Е1 "схема деления структурная". Просто АСУшники традиционно не любят относить себя к конструкторам, и любят изобретать свои обозначения документов, требования к оформлению, таблицы и т.п. Но формально все, вплоть до кода прошивки - конструкторская документация, и жестко регламентируется стандартами ЕСКД.

Какую-то часть моделирования можно делать через иерархии.

совсем уж без иерархий типов тоже неудобно — в том же хаскелле с его классами типов приходится всякие экзистенциальные типы выдумывать для имитации ООП-иерархий

Очевидно, что в описание мира требует и удобно описывать гетерархией, не иерархией.
Ну или частично-упорядоченными кусками иерархий.

Стандартный пример - алмаз Д.Совы.

А мир это синтаксис?

🙅‍♂️

Тогда херня получается

Любой объект/процесс обладает структурой, такие структуры можно называть синтаксисом.
—
Си́нтаксис (др.-греч. σύν-ταξις[1] «составление», «координация», «порядок»)
Синтаксис в буквальном переводе означает не только составление, но и упорядочивание, координирование, соединение слов в связный текст.
https://ru.wikipedia.org/wiki/Синтаксис
—

Если слово синтаксис трактовать несколько расширенно, то вполне можно и допустимо какие-то физические структуры называть синтаксическими.

Примерно также трактуют понятие модель. Есть физические модели, есть символьные модели и т.п.

Тогда мир не надо описывать

Он самоописанный

Какие-то структуры реализованы физически, какие-то структуры реализованы символьно и требуют интерпретирующее устройство.
Пример. Процессор, комп.

Пример. Логические операции и логические элементы, реализуемые физически, напрмиер, транзисторной схемой.