Rifat писал(а):
Вообще есть такая тема, как Unifying Theories of Programming (UTP), где пытаются собрать все абстракции, которые нужны для описания любых программ. В принципе это близко к Лексикону программирования.
Качество уровня "инженерности" в программном деле на сегодня таково, что не существует некоего аналога теории автоматического управления (ТАУ) как в соответствующей инженерной дисциплине (даже нет единого изложения информатики, наоборот, полно "шедевров", которых даже вредно читать). Поэтому такие теории как UTP останутся лишь частными взглядами их авторов, и в частности благодаря авторитету этих авторов подобные обобщения где-то могут быть задействованы.
Обратите внимание как на альтернативу на "саморазвивающеюся" алгоритмическую алгебру от товарища Гуревича из Майкрософт (впечатление, что это то, что Вы желаете):
Машины Абстрактных Состояний (Машины Гуревича)Однако, возникает вопрос в практической применимости подобных моделей/теорий. Впечатление, что те же Машины Гуревича есть попытка создать базис для клепания своих "математических" языков программирования/спецификаций (некий сегодняшний жабский Graal, но для математики). Не в курсе, как именно обстоит дело в этих машинах с формальными методами проверок/верификации, тем более с учётом "пользовательских расширений". В плане формальных методов в качестве примера укажу на TLA+ (со своим языком моделирования/спецификаций) -- в частности, в своё время товарища Lamport-а достало разнообразие всяких "алгебр процессов" и непонятки/неудобства прикручивания к ним логик времени - плюнул на них всех и упростил всё "в лоб" для ряда типовых задач (почти как по Звереву), и получил соответствующую премию:
https://en.wikipedia.org/wiki/TLA%2BТак вот, если присмотреться, то заметно, что у UTP, машин Гуревича и TLA+ начальный базис довольно идентичный -- фактически, понимание системы переходов (функциональный граф или граф состояний по Звереву с надстройками), причём чётко (ну, пожалуй за исключением машин Гуревича, основания там какие-то мутные, всё-таки) выделяются выполняемые работы и передача "предметов труда" (понимание состояний переменных до и после работы), "холостые" работы (не влияющие на изменение состояний по заданным аспектам), различные структурные композиции переходов/шагов и пр. Но даже первичный базис каждый автор изначально адаптирует под возникающие потребности (возможно ситуация могла бы быть чуть иной, если была бы универсальная "ТАУ" для программирования).
Кстати, в ООП понятия выполнение работы и передача транзактов -- крайне размыты, кто-то называет методы как исполняемые, кто-то как отправку сообщений. Вершиной бардака, пожалуй, есть "точки входа" в "мониторы" в task-ах у Ada (и их "акцептирование") -- видимо, чтобы свести концы с концами (верифицировать) ещё нужно постараться перевести модели на нормальный язык:
https://en.wikibooks.org/wiki/Ada_Programming/TaskingА вот ещё один пример "развивающихся" алгоритмических алгебр от Глушковцев (но "развиваются" они по-другому, в отличие от Машин Гуревича):
Модифицированная алгебра алгоритмов и инструментальные средства обработки формул алгебры алгоритмовВ статейке выше, фактически, тамошняя предельная абстракция, но для задач оценки эквивалентности, преобразований, оптимизаций алгоритмов, причём именно вычислительных. В дальнейшем начинаются необходимые "клоны" (хоть схемы программ Янова и производные). На фоне моделей выше -- существенная разница в форме первичного базиса. А для моделирования взаимодействующих процессов у Глушковцев уже совсем другая алгебра ("инсерционное программирование" -- от "insert" -- погружение активного объекта в среду -- т.е. введение нового элемента системы, при котором изменяется (и вообще определяется) и элемент системы, и сама система -- моделирование/верификация начинается с этого этапа).
О чётком разделении вычислительных алгоритмов и управляющих процессов хорошо сказано в соседнем форуме -- в рамках "предикатного" (и "автоматного") программирования от В.И Шелехова -- коллеги Ершова (если не ошибаюсь) -- ещё один пример "лексикона", рожденного, так сказать, у истоков.
По ходу дела вспоминается ещё один очень привлекательный универсальный лексикон (для выражения поведения системы/компонентов), когда-то также был представлен на этом форуме --
ГрафКонт (видимо, сейчас (или уже вообще) сайт не работает) -- исчисление управляющих автоматов реального времени (благодаря которому, вроде как, российские космические корабли бороздят просторы Вселенной, некоторые, по крайней мере). Причём временные оценки в модели ГрафКонт-а, в принципе то, насколько я помню суть построений, можно воспринимать как бонус (если они не нужны). В модели, напр. в отличие или в дополнение к UTP, иные операции структурной композиции шагов/переходов системы (функциональных задач в терминах ГрафКонт-а) -- следовать позже, строго позже, синхронизация по началу/концу и др. При этом у задач есть понятие "многовходовости" (задание периодов исполнения, регулярных и относительных и пр.). А также к задачам прикрепляется булевый вектор как обобщение условий запуска (символизирующий наличие/отсутствие сигналов или ресурсов и т.п.), но для формальных методов вектора должны быть подготовлены. А если есть желание готовить подобные вектора не вручную, да и в целом оперировать формализмом, близким к языку программирования, то можно смотреть, напр., в сторону Esterel/Lustre (где также неизбежно имеется свой отпечаток или диалект лексикона).
В общем, если оценить (даже поверхностно) все модели для определения поведения выше, то окажется, что модели Зверева окажутся самыми общими (но и предельно абстрактными). А так, в целом, конечно же, гипотетически необходимо иметь единый вектор развития, с уклонами для конкретики задач, как во всех нормальных инженерных областях (а порядок необходимо наводить с самых-самых начал, ибо, к примеру, даже понятие "кортежа" не везде одинаковое, как было отмечено выше в теме).