Здравствуйте, Pzz, Вы писали:

Pzz>Ты суть-то опиши. В чем кайф от этой машины? А то твои математические определения скучно читать, пока не поймешь, зачем?

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

В двух словах, в чём ключевое отличие его "уникального способа" от классического.
Программа, по-сути, строится и видоизменяется "на лету".
На каждом шаге может сработать паттерн "стратегия" и прочие родственные, типа "фабрика" и т.д., которые, в свою очередь, могут изменить структуру программы.

Подобные трюки я иногда применяю для ускорения "горячих" мест, например, по неким развесистым условиям программа пробегается лишь однажды, строя на лету через (в идеале даже не ООП-стратегии, а просто указатели на ф-ии), в общем через какой-либо из механизмов косвенности/виртуализации на лету стрится требуемая "прямая" логика, которая будет работать в цикле до некоторых пор уже без повторных проверок условий. При смене внешних условий может сработать обработчик соответствующего события и перестроить программу.
Т.е., условно нелинейная логика каждый раз строит условно линейную программу (потому что "исполнитель" тупой-линейный).

Автор захотел выделить подобный подход в чистом виде, но запутался в ролях и придумываниях терминологии.
(язык программирования и прочий инструментарий тут нужны для большей выразительности описания происходящего, ИМХО, и ни для чего более)
Изначально у элементов этой техники никаких ролей нет (т.е. даже просто пытаться придумывать роли сущностей в отрыве от конкретных задач было ошибкой), а есть просто трюк косвенности (в общем случае — ассоциативной памяти) и перебор получаемых на модели ассоциативной памяти бесконечной комбинаторики эффектов.

Разумеется, это несколько отличается от привычного, "более линейного" программирования, что автору показалось, что он изобрёл новую парадигму.
Не изобрел.
Ассоциативный доступ к данным и подпрограммам — ключевые низкоуровневые технологии современного ПО.

В ООП это виртуальные ф-ии, инкапсулированные в объекты данные, в ФП это абстрактная сигнатура ф-ии, которая также может захватывать в лямбду данные и т.д. до бесконечности, вплоть до банальных адресов обработчиков пронумерованных прерываний в таблице их в программе на асме или си.

Отличие его подхода от классического в том, что подобное "конфигурирование" программы в классике происходит редко (часто вовсе однократно при запуске), а автор предлагает эксплуатировать подобный подход бесконечного реконфигурирования программы в качестве ключевого этапа работы этой программы, а не вспомогательного этапа, как оно чаще есть сейчас.

Здравствуйте, Pzz, Вы писали:

Pzz>Ты суть-то опиши. В чем кайф от этой машины? А то твои математические определения скучно читать, пока не поймешь, зачем?

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

В двух словах, в чём ключевое отличие его "уникального способа" от классического.
Программа, по-сути, строится и видоизменяется "на лету".
На каждом шаге может сработать паттерн "стратегия" и прочие родственные, типа "фабрика" и т.д., которые, в свою очередь, могут изменить структуру программы.

Подобные трюки я иногда применяю для ускорения "горячих" мест, например, по неким развесистым условиям программа пробегается лишь однажды, строя на лету через (в идеале даже не ООП-стратегии, а просто указатели на ф-ии), в общем через какой-либо из механизмов косвенности/виртуализации на лету стрится требуемая "прямая" логика, которая будет работать в цикле до некоторых пор уже без повторных проверок условий. При смене внешних условий может сработать обработчик соответствующего события и перестроить программу.
Т.е., условно нелинейная логика каждый раз строит условно линейную программу (потому что "исполнитель" тупой-линейный).

Автор захотел выделить подобный подход в чистом виде, но запутался в ролях и придумываниях терминологии.
(язык программирования и прочий инструментарий тут нужны для большей выразительности описания происходящего, ИМХО, и ни для чего более)
Изначально у элементов этой техники никаких ролей нет (т.е. даже просто пытаться придумывать роли сущностей в отрыве от конкретных задач было ошибкой), а есть просто трюк косвенности (в общем случае — ассоциативной памяти) и перебор получаемых на модели ассоциативной памяти бесконечной комбинаторики эффектов.

Разумеется, это несколько отличается от привычного, "более линейного" программирования, что автору показалось, что он изобрёл новую парадигму.
Не изобрел.
Ассоциативный доступ к данным и подпрограммам — ключевые низкоуровневые технологии современного ПО.

В ООП это виртуальные ф-ии, инкапсулированные в объекты данные, в ФП это абстрактная сигнатура ф-ии, которая также может захватывать в лямбду данные и т.д. до бесконечности, вплоть до банальных адресов обработчиков пронумерованных прерываний в таблице их в программе на асме или си.

Отличие его подхода от классического в том, что подобное "конфигурирование" программы в классике происходит редко (часто вовсе однократно при запуске), вместо чего автор предлагает эксплуатировать подход бесконечного реконфигурирования программы в качестве ключевого этапа работы программы, а не вспомогательного, как оно чаще есть сейчас.