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

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

Хороший пример — такая динамическая система как речь. Первоначальные попытки декомпозиции на фонемы потерпели фиаско. Выяснилось, что буква "а" это совершенно разная буква в зависимости от положения в слове и даже во фразе. Чтобы сгенерировать речь понадобилась не одна буква (звук) "а", а несколько десятков.
В данном случае, все равно все удалось свести к дискретному набору, выбору из готовых = стабильных вариантов. Но сделано это, конечно, весьма сложно, если не сказать топорно.

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

Как вариант:
Вероятно, для решения подходит матаппарат редукции графов. Следовательно, декомпозиция системы первоначально долдна происходить не на объекты — а на функции (характеристики).
Узлы — функции, ребра — отношения. Отношения могут быть нескольких типов.
Сочетание Узел+Отношение рождают Решение (заготовку шаблона, частично конкретизированный шаблон).
Уточняющие итерации с поглощением "ребер-отношений" в конце концов приводят к программе.

Например, вот это : суперкомпиляция и частичные вычисления — это вроде бы как раз то, что я имел ввиду.

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

S>Например, вот это : суперкомпиляция и частичные вычисления — это вроде бы как раз то, что я имел ввиду.

Не понял примеры, но у меня есть похожая идея.
Рассмотрим, например, организм. В нем есть разные подсистемы — нервная, кровеносная, пишеварительная и т.д. Все они выполняют разные функции, у них разная логика работы, но все они взаимопроникают друг в друга и используют друг друга в своей работе. Могут ли современные ООП-языки предложить удобный для программиста механизм реализации такого взаимопроникновения? Мне почему-то кажется, что нет. И, честно, с трудом представляю что бы это могло быть...

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

S>ООП — это, в частности, метод проектирования основанный на декомпозиции на объекты- черные ящики. Взаимовлияние (говоря образно — интерференция) объектов — исключается.
S>Собственно — замкнутость, независимость, самостоятельность и внутрення неизменность "объектов" — основа ООП или разработки на библиотеках компонент.

Декомпозиция на "чёрные ящики" применяется не только в ООП. Можно сказать, что таким образом проектируется почти всё, что хоть немного сложнее палки-копалки.

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

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

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

Здравствуйте, x-code, Вы писали:
XC>Не понял примеры, но у меня есть похожая идея.
XC>Рассмотрим, например, организм. В нем есть разные подсистемы — нервная, кровеносная, пишеварительная и т.д. Все они выполняют разные функции, у них разная логика работы, но все они взаимопроникают друг в друга и используют друг друга в своей работе. Могут ли современные ООП-языки предложить удобный для программиста механизм реализации такого взаимопроникновения? Мне почему-то кажется, что нет. И, честно, с трудом представляю что бы это могло быть...
Более того, я, если честно, с трудом представляю, для чего это может понадобиться.

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

S>Как вариант:
S>Вероятно, для решения подходит матаппарат редукции графов. Следовательно, декомпозиция системы первоначально долдна происходить не на объекты — а на функции (характеристики).
S>Узлы — функции, ребра — отношения. Отношения могут быть нескольких типов.
S>Сочетание Узел+Отношение рождают Решение (заготовку шаблона, частично конкретизированный шаблон).
S>Уточняющие итерации с поглощением "ребер-отношений" в конце концов приводят к программе.

IMHO такой подход будет иметь те же недостатки, что и нейронные сети или воспитание детей -- невозможность исправлять ошибки...

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

XC>>Рассмотрим, например, организм. В нем есть разные подсистемы — нервная, кровеносная, пишеварительная и т.д. Все они выполняют разные функции, у них разная логика работы, но все они взаимопроникают друг в друга и используют друг друга в своей работе. Могут ли современные ООП-языки предложить удобный для программиста механизм реализации такого взаимопроникновения? Мне почему-то кажется, что нет. И, честно, с трудом представляю что бы это могло быть...
S>Более того, я, если честно, с трудом представляю, для чего это может понадобиться.

Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.

Здравствуйте, Erop, Вы писали:
E>IMHO такой подход будет иметь те же недостатки, что и нейронные сети или воспитание детей -- невозможность исправлять ошибки...

Но все же смирились с тем что SQL сервер сам рулит планом выполнения запроса. Или, например, что автоматизация на Excel имеет строго ограниченные рамки как по интерфейсу, так и по набору решений (маршрутам решений).
Другой пример — результат представления HTML. Возможности здесь тоже дизайнера не бесконечны. Дизайнер уже не бог и король. Можно задать общие требования, однако окончательное "поведение" (например переносы строк, масштабирование табличек) будет определять engine браузера.
Однако, это все широко используется. Так же как и автомобили и утюги. Никто не делает дома руками нечто тратя человеко-годы нечто, только ради полного контроля над процессом.

Здравствуйте, Voblin, Вы писали:
V>Идея хорошая, но есть ненулевая вероятность получения генератора случайных программ. Избегать этого или стремиться к этому — хороший вопрос.

V>Не знаю как кто, но лично я люблю программизм за то, что если не запутаться и не накосячить, то на выходе процесса я получаю "устройство", которое в области своей применимости решает задачу с предсказуемой (а иногда и абсолютной) точностью.

Но на вашем сайте однако есть же описание mixin технологии. Это довольно близко.

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

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

S>>Например, вот это : суперкомпиляция и частичные вычисления — это вроде бы как раз то, что я имел ввиду.

XC>Не понял примеры, но у меня есть похожая идея.

Я подумал что может кто то с этими параметрами знаком поглубже.
Ну вроде суперкрмпиляция — это как бы компиляция из функциональных требований в компилируемый язык.
Или компиляция из сырого и избыточного кода в сжатый и оптимизированный.

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

XC>Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.
Очень сложная поддержка. Культура + медицина + религия + ... требуюися, чтобы чуть-чуть заткнуть косяки природной архитектуры...

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

S>Но все же смирились с тем что SQL сервер сам рулит планом выполнения запроса. Или, например, что автоматизация на Excel имеет строго ограниченные рамки как по интерфейсу, так и по набору решений (маршрутам решений).
S>Другой пример — результат представления HTML. Возможности здесь тоже дизайнера не бесконечны. Дизайнер уже не бог и король. Можно задать общие требования, однако окончательное "поведение" (например переносы строк, масштабирование табличек) будет определять engine браузера.
S>Однако, это все широко используется. Так же как и автомобили и утюги. Никто не делает дома руками нечто тратя человеко-годы нечто, только ради полного контроля над процессом.

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

А ты, насколько я понял, собираешься целенаправленно культивировать сложность и повышать степень связанности...

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

S>Я подумал что может кто то с этими параметрами знаком поглубже.
У Дейкстры были похожие идеии.
Их можно найти по ключевым словам weekest precondition...

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

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

E>Здравствуйте, x-code, Вы писали:

XC>>Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.
E>Очень сложная поддержка. Культура + медицина + религия + ... требуюися, чтобы чуть-чуть заткнуть косяки природной архитектуры...

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

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

XC>На самом деле, это следующая после ООП идея. В ООП появились "объекты" и "взаимодействия", а в этой парадигме — можно назвать ее "многослойное" или даже "многомерное" программирование — появляется разбиение объектов по слоям-изменениям и системная композиция объектов на основе этих слоев. Возможно, первый шаг к этой парадигме — аспектно-ориентированное программирование, там есть нечто подобное в упрощенном виде.

Какая разница следующая или предыдущая? Ты объясни как с поодержкой бороться?

Сила ООП в том, что она позволяет эффективно поддерживать более сложные логические конструкции, чем процедурная парадигма. То есть ещё более эффективно борется за упрощение сложной задачи.
А у тебя какая цель? Навернуть посложнее? Ты с какими проблемами бороться содираешься? Какой практический сценарий использования твоей идеи?

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

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

S>>Но все же смирились с тем что SQL сервер сам рулит планом выполнения запроса. Или, например, что автоматизация на Excel имеет строго ограниченные рамки как по интерфейсу, так и по набору решений (маршрутам решений).
S>>Другой пример — результат представления HTML. Возможности здесь тоже дизайнера не бесконечны. Дизайнер уже не бог и король. Можно задать общие требования, однако окончательное "поведение" (например переносы строк, масштабирование табличек) будет определять engine браузера.
S>>Однако, это все широко используется. Так же как и автомобили и утюги. Никто не делает дома руками нечто тратя человеко-годы нечто, только ради полного контроля над процессом.

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

E>А ты, насколько я понял, собираешься целенаправленно культивировать сложность и повышать степень связанности...

Это верно в отношении HTML.

Но только не в отношении SQL или ДВС.

"Взаимопроникновение" я думаю — это как раз то, что превращает промышленное проектирование ДВС, самолетов и кораблей в ОЧЕНЬ (и очень) дорогой процесс, нисмотря на то, что в концептуальном смысле (в кубиках) все понятно пятикласнику за пять минут.

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

V>>Не знаю как кто, но лично я люблю программизм за то, что если не запутаться и не накосячить, то на выходе процесса я получаю "устройство", которое в области своей применимости решает задачу с предсказуемой (а иногда и абсолютной) точностью.

S>Но на вашем сайте однако есть же описание mixin технологии. Это довольно близко.

Спасибо что заглянули

В общем похоже, но есть отличия. У меня классы по-прежнему остаются "чёрными ящиками", но instance можно порождать сразу от нескольких классов. Взаимопроникновение, если это нужно, заранее чётко описывается. Если есть класс Foo и класс Bar, и мы предполагаем, что объекты, классифицируемые одновременно как Foo и как Bar имеют физический смысл и обладают какой-то дополнительной особенностью реализации, то эту особенность мы программим явно.

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

E>Здравствуйте, x-code, Вы писали:

XC>>Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.
E>Очень сложная поддержка. Культура + медицина + религия + ... требуюися, чтобы чуть-чуть заткнуть косяки природной архитектуры...

Ну не скажите, "срок службы" человека гораздо больше срока службы автомобиля, например.
Сколько стоит система серверов без поддержки и работает сама? Ну неделю ну две, а то иной раз приходишь в понедельник (всего то пару дней прошло) и начинаешь день с того, что то и это нужно перезапустить, перестартовать или перезагрузить, а то и посложнее ситуации.

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

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

E>>Здравствуйте, x-code, Вы писали:

XC>>>Думаю, раз в природе используется именно такая архитектура, то рано или поздно и в программинге она понадобится.
E>>Очень сложная поддержка. Культура + медицина + религия + ... требуюися, чтобы чуть-чуть заткнуть косяки природной архитектуры...

XC>На самом деле, это следующая после ООП идея. В ООП появились "объекты" и "взаимодействия", а в этой парадигме — можно назвать ее "многослойное" или даже "многомерное" программирование — появляется разбиение объектов по слоям-изменениям и системная композиция объектов на основе этих слоев. Возможно, первый шаг к этой парадигме — аспектно-ориентированное программирование, там есть нечто подобное в упрощенном виде.

Да, аспекты и моделирование характеристик.

Аспекты это весьма упрощено, а моделирование характеристик "позиционируется" как творческая методика.

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

S>Ну не скажите, "срок службы" человека гораздо больше срока службы автомобиля, например.
А пробег (если уж об автомобилях говорим) намного меньше...
S>Сколько стоит система серверов без поддержки и работает сама? Ну неделю ну две, а то иной раз приходишь в понедельник (всего то пару дней прошло) и начинаешь день с того, что то и это нужно перезапустить, перестартовать или перезагрузить, а то и посложнее ситуации.
Ресурс системы вообще-то часто можно любым спросктировать. У человека просто регенерация есть. Если ты к серверами регенерилку разработаешь, то и будет тебе счастье. Есть куча устройств, ПО которых работает бесконечно долго (много больше работы на отказ оборудования)

Во всяком случае мне лично неочевидно что предлагаемая метода это не то чтобы лучший способ повышения надёжности ПО, а вообще способ повышения надёжности...