Приложения по программированию будущего

В. К. ПЕТРОСЯН (Вадимир). Общая теория металогарифмов. В 2 тт.


*********
© В.К.
Петросян (Вадимир) © Lag.ru [Large Apeironic Gateway, Большой Апейронический
Портал (Шлюз), Суперпортал в Бесконечность].
При копировании данного материала и размещении его на другом сайте, ссылки
на соответствующие локации порталов Lag.ru и Proza.ru обязательны
Работа написана на основе концепции и разработок В.К. Петросяна при полноценном соавторстве (активном творческом и техническом участии) ChatGPT (OpenAI), GPT-5.6 Sol
******



КОНЦЕПТУАЛЬНЫЕ ПРИЛОЖЕНИЯ ПО ПРОГРАММИРОВАНИЮ БУДУЩЕГО


Предыдущие приложения подвели к идее математического языка, в котором сложная структура нижнего уровня может становиться элементарной семантической единицей уровня более высокого.

В программировании происходит сходный процесс.

Исторически программист последовательно переходил:

от машинных команд;

к символическим инструкциям;

от инструкций:

к функциям;

от функций:

к объектам и модулям;

от модулей:

к библиотекам, фреймворкам, предметным языкам и генераторам.

Но этот процесс может быть продолжен.

Следующим уровнем может стать язык, в котором элементарной единицей является уже не отдельная функция и даже не обычный программный модуль, а:

семантически завершённая функциональная конструкция, способная автоматически развернуться в сложную программную систему.

В настоящей книге для подобной единицы используется понятие:

программного кодона.

Из кодонов могут формироваться:

программные генотипы.

Генотипы могут порождать:

исполняемые фенотипы.

Генераторы могут создавать:

генотипы.

Метагенераторы:

генераторы.

Так появляется многоуровневая архитектура программирования, в которой человек всё меньше описывает:

каждую конкретную инструкцию

и всё больше определяет:

цели;

ограничения;

инварианты;

семантические компоненты;

архитектурные отношения.

Важно подчеркнуть:

термин «генеративное программирование» уже используется в информатике в различных значениях.

В настоящем проекте предлагается не объявление самого термина новым, а его расширение в сторону:

генеративного программирования высоких семантических уровней

на основе:

кодонов;

программных генотипов;

многоуровневой компиляции;

контролируемой экспликации;

семантической трассировки.

ПРИЛОЖЕНИЕ 28. КОДОННОЕ ПРОГРАММИРОВАНИЕ
28.1. Понятие программного кодона
Программным кодоном называется:

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

Обычная программная инструкция может означать:

сложить два числа;

загрузить значение;

выполнить переход.

Функция может означать:

отсортировать массив;

прочитать файл;

вычислить результат.

Программный кодон потенциально может означать существенно более крупную структуру:

построить систему поиска;

развернуть распределённую службу;

создать проверяемый пользовательский интерфейс;

сформировать модель данных;

организовать эксперимент;

создать симуляционную среду;

построить систему обучения;

создать целый программный сервис по заданной спецификации.

При этом кодон не должен быть просто красивым именем для скрытого произвольного кода.

Его семантика должна быть:

определена;

типизирована;

проверяема;

декодируема.

Общая форма
Концептуально:

CODON(parameters) -> SUBSYSTEM

или:

CODON(inputs,constraints) -> outputs

Но результатом кодона может быть не только значение.

Он может создавать:

архитектуру;

процесс;

службу;

модель;

программный компонент;

набор взаимодействующих компонентов.

28.2. Кодон как функционально завершённый блок
Ключевое свойство кодона:

функциональная завершённость.

Это означает, что кодон представляет определённую смысловую функцию, которую пользователь способен рассматривать:

как одну единицу.

Например, условный кодон:

AUTH_SYSTEM

может включать:

регистрацию;

вход;

хранение учётных данных;

контроль сессий;

авторизацию;

восстановление доступа;

журналирование;

политику безопасности.

Пользователь языка высокого семантического уровня не обязан вручную перечислять каждую из этих подсистем при каждом использовании кодона.

Но внутренняя структура остаётся:

формально доступной;

декодируемой;

проверяемой.

Кодон и модуль
Обычный модуль часто является:

организационной единицей исходного кода.

Кодон определяется прежде всего:

семантической функцией.

Один кодон может быть реализован:

одним модулем;

несколькими;

целой системой сервисов.

Поэтому:

CODON != SOURCE FILE

и:

CODON != MODULE

в обязательном смысле.

28.3. Семантика кодона
Кодон должен иметь формальный паспорт.

Минимально:

NAME

VERSION

INPUTS

OUTPUTS

PARAMETERS

SEMANTICS

PRECONDITIONS

POSTCONDITIONS

CONSTRAINTS

EXPANSION_RULE

INVARIANTS

NAME
Уникальное имя в соответствующем пространстве имён.

VERSION
Версия семантики.

INPUTS
Что кодон принимает.

OUTPUTS
Что он создаёт.

PARAMETERS
Что можно конфигурировать.

SEMANTICS
Что кодон означает независимо от конкретной низкоуровневой реализации.

PRECONDITIONS
Что должно быть истинно перед выполнением.

POSTCONDITIONS
Какие свойства должны выполняться после.

CONSTRAINTS
Какие ограничения нельзя нарушать.

EXPANSION_RULE
Как кодон преобразуется в структуру более низкого уровня.

INVARIANTS
Какие свойства должны сохраняться во всех допустимых реализациях.

Таким образом кодон представляет не просто:

«кусок программы»,

а:

контракт семантической генерации.

28.4. Параметры кодона
Кодон может быть:

непараметризованным;

слабопараметризованным;

многопараметрическим;

динамически параметризуемым.

Например:

DATABASE(type,scale,consistency,availability)

может принимать параметры:

тип хранения;

ожидаемый масштаб;

модель согласованности;

требования доступности.

Другой кодон:

SEARCH(domain,latency,quality)

может создавать различные реализации поиска.

Параметр и намерение
Высокосемантический параметр не обязан быть обычным числом.

Он может быть:

целевой характеристикой;

ограничением;

политикой;

классом качества.

Например:

LATENCY < 100ms

или:

PRIVACY=LOCAL_ONLY

или:

FAILURE_MODE=GRACEFUL

Так программа начинает описываться:

не только операциями,

но:

желаемыми свойствами.

Типизация параметров
Параметры должны иметь типы.

Например:

TIME_CONSTRAINT

RESOURCE_LIMIT

SECURITY_POLICY

QUALITY_TARGET

ARCHITECTURE_CLASS

Это предотвращает произвольное смешение семантически разных значений.

28.5. Композиция кодонов
Основная сила кодонного языка возникает не в отдельных кодонах, а в их композиции.

Простейшая:

C1 ][ C2

где выход C1 используется C2.

Но существуют разные типы композиции.

Последовательная
C1 ][ C2 ][ C3

Параллельная
Один вход поступает:

C1;

C2;

C3,

а результаты далее объединяются.

Перекрёстная
Выход одного кодона становится:

не обычными данными,

а параметром другого.

Например:

C1.OUTPUT -> C2.SCALE

Условная
Активируется один из нескольких кодонов.

Рекурсивная
Результат кодона влияет на последующее применение:

того же;

или другого

кодона.

Рефлексивная
Кодон получает информацию:

о состоянии всей программной системы

и меняет своё будущее поведение.

Метакомпозиция
Объектом операции становится:

сама схема соединения кодонов.

28.6. Программный генотип
Программным генотипом называется:

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

Концептуально:

PG={C1,C2,C3;LINKS;CONSTRAINTS;META}

где:

C1,C2,C3 — кодоны;

LINKS — связи;

CONSTRAINTS — ограничения;

META — метаправила.

Простой генотип
PG1 := C1 ][ C2 ][ C3

Графовый генотип
Для сложных систем линейной записи недостаточно.

Тогда:

PG=(NODES,EDGES)

где:

NODES — кодоны;

EDGES — типизированные связи.

Генотип и исходный код
Программный генотип не обязан содержать:

все функции;

все классы;

все запросы;

все конфигурационные файлы.

Он описывает:

архитектуру их порождения.

Поэтому один сравнительно короткий генотип может породить:

очень большой программный фенотип.

28.7. Исполняемый фенотип
Результатом развёртывания программного генотипа становится:

исполняемый фенотип.

Схема:

PROGRAM GENOTYPE

-> COMPILATION / GENERATION

-> EXECUTABLE PHENOTYPE

Фенотип может включать:

исходный код;

машинный код;

инфраструктуру;

конфигурацию;

схему данных;

развёрнутые сервисы;

пользовательский интерфейс;

политики;

тесты;

мониторинг.

Таким образом исполняемый фенотип может быть:

не одним бинарным файлом,

а:

целой работающей программной системой.

Генотипическая и фенотипическая сложность
Короткий генотип:

не означает простой фенотип.

И наоборот:

большой фенотип может иметь:

очень компактную генеративную причину.

Поэтому необходимо различать:

GENOTYPIC COMPLEXITY

и:

PHENOTYPIC COMPLEXITY.

28.8. Метакодоны
Метакодон действует:

не столько на данные,

сколько:

на другие кодоны или их композиции.

Концептуально:

MCD(PG) -> PG'

Метакодон может:

добавлять кодоны;

выбирать реализации;

менять топологию;

масштабировать архитектуру;

создавать новые экземпляры подсистем;

изменять профили конфигурации.

Метакодон масштабирования
Например:

MCD_SCALE

может анализировать:

нагрузку;

ограничения;

стоимость

и строить другую архитектуру развёртывания.

Метакодон специализации
MCD_SPECIALIZE

может преобразовать:

общий кодон

в:

специализированный под конкретную предметную область.

Ограничение
Метакодон не должен иметь неограниченного права произвольно переписывать систему.

Его область воздействия должна быть:

типизированной;

версионируемой;

проверяемой.

28.9. Саморефлексивные кодоны
В программном контексте саморефлексивным можно назвать кодон, параметры которого структурно связаны:

с его собственными характеристиками

или:

с характеристиками создаваемой им системы.

Например:

кодон может использовать один параметр N для одновременного задания:

числа рабочих процессов;

глубины резервирования;

числа уровней обработки.

Это структурная самосинхронизация.

Рефлексивный кодон
Более общий случай:

кодон анализирует:

собственные метрики;

состояние;

результаты

и регулирует дальнейшее поведение.

Например:

STATE_k -> POLICY -> STATE_(k+1)

Прямая самореференция
Если кодон определяется:

через ещё не существующую собственную структуру,

возникает задача самосогласования.

Как и в ОТМ, необходимо различать:

рекурсию;

рефлексивность;

саморефлексивность;

самореференцию.

28.10. Библиотеки кодонов будущего
Кодонное программирование предполагает существование:

библиотек высокоуровневых семантических компонентов.

Например:

DATA

SECURITY

SEARCH

AI

SIMULATION

FINANCE

EDUCATION

COMMUNICATION

UI

INFRASTRUCTURE

Каждая библиотека может содержать:

сотни;

тысячи

формально определённых кодонов.

Кодонный алфавит
Если библиотека содержит тысячу высокосемантических кодонов,

программист работает уже не с тысячей строк низкоуровневого синтаксиса,

а:

с тысячей высокоуровневых смысловых единиц.

Версии
Каждый кодон должен быть версионирован.

Совместимость
Необходимо описывать:

какие кодоны совместимы;

какие типы передают;

какие зависимости требуют.

Проверяемость
Кодон должен иметь:

тесты;

контракты;

инварианты;

формальные свойства

в той степени, в которой это возможно.

Эволюция библиотек
Кодоны могут становиться:

всё более высокоуровневыми.

Кодон одного поколения языка может стать:

низкоуровневой реализацией

для кодона следующего поколения.

ПРИЛОЖЕНИЕ 29. ГЕНЕРАТИВНОЕ ПРОГРАММИРОВАНИЕ
1. Предлагаемое расширение понятия
Под генеративным программированием высокого семантического уровня в настоящем проекте понимается парадигма, при которой программист задаёт:

цели;

ограничения;

семантические компоненты;

архитектурные отношения;

инварианты,

а значительная часть конкретного алгоритмического и программного фенотипа:

генерируется автоматически.

Общая схема:

SPECIFICATION

-> GENERATION

-> PROGRAM

-> EXECUTABLE SYSTEM

Но в развитой форме:

INTENTION

-> SEMANTIC SPECIFICATION

-> PROGRAM GENOTYPE

-> VERIFIED PHENOTYPE

29.1. От команды к намерению
Низкоуровневая программа описывает:

что машина должна сделать шаг за шагом.

Высокоуровневая:

какие операции выполнить.

Ещё более высокий уровень может описывать:

какой результат требуется получить.

Например вместо:

создай файл;

открой соединение;

выполни запрос;

обработай результат;

покажи таблицу,

пользователь задаёт:

«создай систему мониторинга показателей с ежедневным обновлением, проверкой аномалий и объяснимым отчётом».

Это уже:

не команда,

а:

намерение.

Намерение недостаточно само по себе
Естественно-языковое желание не является формальной программой.

Необходимо преобразование:

INTENTION

-> FORMAL SEMANTIC SPECIFICATION

Именно этот промежуточный слой является критически важным.

29.2. От алгоритма к генеративной спецификации
Классическая программная постановка:

«реализовать алгоритм A».

Генеративная:

«создать систему, удовлетворяющую набору свойств P».

Например:

GOAL: classify documents

LATENCY:<100ms

PRIVACY:local

QUALITY:>=Q

COST:<C

Система должна построить:

алгоритм;

архитектуру;

ресурсную конфигурацию.

Спецификация
Концептуально:

SPEC={GOALS,CONSTRAINTS,RESOURCES,POLICIES}

Это не программный код в традиционном смысле.

Это:

формальная область допустимых программ.

29.3. Программа как генотип
Если спецификация преобразуется в:

набор кодонов;

их связи;

параметры;

политики,

возникает:

программный генотип.

Схема:

SPEC

-> PG

-> PHENOTYPE

Генотип может быть:

компактным.

Фенотип:

огромным.

Идентичность программы
В такой парадигме возникает вопрос:

что является самой программой?

Исходная спецификация?

Генотип?

Сгенерированный код?

Развёрнутая система?

Возможно, понадобится различать:

логическую идентичность;

генотипическую;

фенотипическую;

операционную.

29.4. Автоматическое построение алгоритма
Одна и та же цель может допускать:

несколько алгоритмов.

Тогда генератор может:

создать кандидатов;

оценить;

выбрать.

Схема:

GOAL

-> {A1,A2,...,An}

-> VERIFY

-> SELECT

Критерии выбора
Алгоритм может выбираться по:

корректности;

скорости;

памяти;

стоимости;

устойчивости;

прозрачности;

безопасности.

Необходимость доказуемых ограничений
Для критических систем нельзя полагаться только:

на эмпирическую оценку.

Необходимы:

контракты;

доказательства;

сертификаты;

проверяемые инварианты.

29.5. Автоматическое построение архитектуры
Следующий уровень:

система генерирует не только алгоритм,

но:

архитектуру.

Например выбирает:

монолит;

набор сервисов;

очереди;

хранилища;

кэш;

репликацию;

модель отказоустойчивости.

Схема:

REQUIREMENTS

-> ARCHITECTURE GENERATOR

-> ARCHITECTURE

-> IMPLEMENTATION

Генератор архитектур
Такой генератор сам является:

метапрограммой.

Он работает:

не с отдельными командами,

а:

с классами программных систем.

29.6. Самопорождающиеся программы
Самопорождающей можно назвать систему, способную:

порождать новые программные компоненты

на основе:

собственного состояния;

входов;

правил.

Пример:

PROGRAM_k

-> GENERATOR

-> PROGRAM_(k+1)

Но необходимо различать:

создание конфигурации;

создание кода;

создание новой архитектуры.

Контролируемое самопорождение
Безопасная модель требует:

ограниченного пространства генерируемых компонентов;

формальной типизации;

проверки;

версий;

журналирования.

Самопорождение не должно означать:

произвольное создание непроверенного исполняемого кода.

29.7. Самомодифицирующиеся программы
Самомодификация означает:

изменение собственной программной структуры.

Например:

PG_(k+1)=Transform(PG_k,STATE_k)

Система может менять:

параметры;

кодоны;

связи;

политики;

алгоритмы.

Уровни самомодификации
Уровень 1:

изменяется конфигурация.

Уровень 2:

меняется выбор реализации.

Уровень 3:

меняется архитектура.

Уровень 4:

меняются правила генерации архитектуры.

Инварианты
Самомодификация должна происходить только внутри:

допустимого пространства состояний.

Необходимо сохранять:

критические свойства безопасности;

типовые ограничения;

контракты;

обратимость.

Версионирование
Каждое изменение должно создавать:

версию.

Схема:

PG_0

-> PG_1

-> PG_2

Должна существовать возможность:

сравнения;

аудита;

отката.

29.8. Рефлексивные программные системы
Рефлексивная программа способна использовать:

информацию о себе

для регулирования своего поведения.

Она может анализировать:

метрики;

архитектуру;

зависимости;

ошибки;

стоимость;

качество.

Схема:

SYSTEM STATE

-> REFLECTION

-> CONTROL DECISION

-> NEW STATE

Отличие от самомодификации
Рефлексивная система может анализировать себя,

но:

не изменять собственный код.

Например она только регулирует:

число рабочих процессов.

Самомодифицирующаяся система изменяет:

саму программную структуру.

29.9. Генераторы программ
Генератор программ:

PGG

может принимать:

спецификацию S

и создавать:

программный генотип PG.

Схема:

S -> PGG -> PG

После этого:

PG -> compiler -> phenotype

Генератор может быть специализирован:

для веб-систем;

симуляций;

аналитики;

математического ПО;

игровых миров;

научных экспериментов.

29.10. Генераторы генераторов
Следующий уровень:

создаётся не программа

и не генотип,

а:

генератор программ.

Схема:

MG

-> PGG

-> PG

-> PROGRAM

Следующий:

MMG

-> MG

-> PGG

-> PG

-> PROGRAM

Возникает открытая метаиерархия.

Зачем нужны генераторы генераторов
Разные предметные области требуют:

разных принципов генерации.

Поэтому вместо универсального генератора всех систем можно создавать:

специализированные генераторы

из более общего метагенератора.

Семантический подъём
То, что было:

самой программой

на одном уровне,

становится:

данными

для следующего.

Именно этот принцип объединяет:

генеративное программирование;

ОТМ;

кодонную математику;

теорию экспликации.