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

S>Не те "слои" берете. Лучше возмем: стекло и форма.

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

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

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

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

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

XC>>В предлагаемой парадигме появляется N иерархий, независимых друг от друга. При этом один и тот же объект может принадлежать одновременно разным иерархиям. А сами иерархии становятся менее жесткими, благодаря чему объекты становятся более свободными.

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

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

Просто пока не очень понятно (думаю, я здесь не одинок), о чём идёт речь и что же такое здесь должно взлететь

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

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

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

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

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

V>Неплохо было бы добавить немножко конкретики. Приведите пожалуйста примерчик "типичной" для этого метода задачи и покажите, как она легко и непринуждённо решается.

Хотя бы понять что именно пытаемся упростить...

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

V>Ну при чём же здесь мультиметоды? Я эту тему вообще не поднимал.

...как способ частичного "отлучения" от необходимости "жесткого наследования"

V>Зачем засахаривать наследование? Как показала практика, проще вообще отказаться от использования ООП, чем сначала родить уродца, попытавшись уложить сложную предметную область в прокрустово ложе иерархии классов, а потом иметь с ним вечный геморрой.

в случае с CLOS "прокрустово ложе иерархии классов" уже не такое "жесткое"... Но если вам и на нём "твёрдо" — добавьте/используйте ФП/ДП.

Я к тому, что ваш "поток сознания" без технической конкретики начинает напоминать... есть здесь один "адепт" "семантического программирования"

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

По описанию выглядит похоже на MPS, Intentional Programming и так далее, только сформулировано слишком неясно. Есть книга на эту тему — Чарнецки и другие, "Порождающее программирование"

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

V>>Ну при чём же здесь мультиметоды? Я эту тему вообще не поднимал.

CU>...как способ частичного "отлучения" от необходимости "жесткого наследования"

Sorry, мультиметоды, они на то и "мульти", что к одиночному объекту не применяются. Они ведь сделаны для описания логики взаимодействия объектов. А если объект один, но одновременно является и бумажкой, и самолётиком, куда тут приткнуть мультиметод? Что с чем взаимодействовать будет?

CU>в случае с CLOS "прокрустово ложе иерархии классов" уже не такое "жесткое"... Но если вам и на нём "твёрдо" — добавьте/используйте ФП/ДП.

Адепты ФП/ДП часто преподносят его как универсальное лекарство от всех болезней. Действительно штука весьма очаровательная. Но, к сожалению, применима не ко всем задачам. Бывает так, что "побочные эффекты" и "внутреннее состояние", от которых ФП избавилось — это очень нужные вещи (про монады мне не рассказывайте, я о них знаю). Когда исполнение программы — это вычисление (в самом классическом понимании, как получение "Output" из "Input" через выполнение "Program"), то ФП и карты в руки. Но если работа системы — это непрерывная деятельность, то ФП, конечно, на отдельных участках применимо, но в целом система — не "Ф".

CU>Я к тому, что ваш "поток сознания" без технической конкретики начинает напоминать... есть здесь один "адепт" "семантического программирования"

Упс... Что за зверь "семантическое программирование" — не ведаю

Господи, какая такая техническая конкретика? Меня зацепили на тему множественной классификации, работу по которой я и не планировал в ближайшую пятилетку переводить в практическую плоскость (если кому интересно, расскажу почему). Так что, друзья, не ворчите.

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

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

В хреново написанных системах такое наблюдается. Чем хреновее написана, тем больше наблюдается.

S>Хороший пример — такая динамическая система как речь.

Зачем равнять природные вещи с искусственными? у природы ни сроков, ни клиентов, ни приемки работ нет — времени ну очень дофига, что выросло, то выросло.

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

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

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

Multi-stage Programming
A Taxonomy of meta-programming systems

V>(если кому интересно, расскажу почему).

Давай, интересно Тем более что и форум подходящий

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

V>>Меня зацепили на тему множественной классификации, работу по которой я и не планировал в ближайшую пятилетку переводить в практическую плоскость (если кому интересно, расскажу почему).

L>Давай, интересно Тем более что и форум подходящий

Всё просто. Дело в том, что практический выход этой штуки (см. здесь) может быть только один — создание системы программирования (язык + среды разработки для разных платформ + библиотеки + сообщество "пользователей"). А это либо должно стать делом всей жизни, либо за это вообще не стоит браться. А мне посвятить свою жизнь этому совсем не хочется. У меня есть другая "хрустальная мечта".

Что касается идеи множественной классификации, то это конечно восхитительная вещь, но мэйнстрим всей своей колоссальной массой ломанулся, не подумав, по другому пути. Ну представьте себе, что будет если выяснится, что в очередной версии MS VC++ лишится механизма наследования, а вместо этого этого появится какая-то странная штука, про которую в Буче не написано? Это ж мировой катаклизьм!

Так что если у кого-то есть желание подхватить знамя, то you are wellcome! А что, на этой штуке уж по крайней мере диссер-то можно защитить. Я ж готов в свободное от остальных дел время выступить в роли полувиртуального отца-основателя. В качестве бонуса даже могу ещё каких-нибудь идей накидать

Здравствуйте, palm mute, Вы писали:
PM>Multi-stage Programming
PM>A Taxonomy of meta-programming systems

Спасибо. Читаю...

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

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

PM>Multi-stage Programming
PM>A Taxonomy of meta-programming systems


Почитал. Ладно.
Предложу некую реализацию того о чем я говорю.

Реализация состоит в том, что

1) есть набор примитивов кода таких как структуры и функции.
Это то — из чего будет состоять код конечной программы. Это с одного полюса.

2) На другом полюсе существуют слои абстракции- множество объектов и допустимых отношений между объектами.

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

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

3) Слои абстракций транслируются с верхнего уровня на нижий.

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

НИ ОДИН ИЗ ОБЪЕКТОВ, кроме объектов на самом нижнем уровне НЕПОСРЕДСТВЕННО НЕ связан с примитивами кода.

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

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

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

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

Далее процесс повторяется.

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

V>Sorry, мультиметоды, они на то и "мульти", что к одиночному объекту не применяются. Они ведь сделаны для описания логики взаимодействия объектов. А если объект один, но одновременно является и бумажкой, и самолётиком, куда тут приткнуть мультиметод? Что с чем взаимодействовать будет?

Ну может хоть краем глаза гляните на дженерики в CLOS, [пере]определение "наследования" — в кавычках не случайно, а намеренно, ибо реализация выбора (какой метод /* НЕПРАВИЛЬНО — какую _дженерик-функцию_ */ выполнять) делает "наследование" лишь одним из возможных (и по умолчанию) вариантом поведения /* который опять-же может меняться по ходу выполнения программы в зависимости от каких угодно факторов */, на MOP. Можно ещё на AspectL посмотреть — для примера как он всем этим пользуется, но для этого лисп/CLOS уже надо знать/понимать

V>Адепты ФП/ДП часто преподносят его как универсальное лекарство от всех болезней.

Я же писал _ДОБАВИТЬ_, а не _использовать только его_.

P.S. И плюс к этому превосходный мета-аппарат...

P.P.S. Я к тому что попытаться изобразить концепт вашей идеи было бы проще на лиспе (каюсь "проще" — мне Но я своим закостенелым сознанием так и не могу "осознать" чего же вы хотите

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

...
S>В остальных случаях для трансляции с одного уровня на другой используется многостадийный транслятор,
S>с некоторым неизменным механизмом, но изменяемой базой знаний.

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

<сорри, отквотить надо было больше, но тут такие злые модеры... >

Мне напоминает "макры, которые генерят макры, которые генерят макры... которые локально переопределяют глобальные макры, которые..." — короче "гипер-динамическая супер-генерация" кода . Или я так и не понял?

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

S>Почитал. Ладно.
S>Предложу некую реализацию того о чем я говорю.

S>Реализация состоит в том, что

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

V>>>Меня зацепили на тему множественной классификации, работу по которой я и не планировал в ближайшую пятилетку переводить в практическую плоскость (если кому интересно, расскажу почему).

L>>Давай, интересно Тем более что и форум подходящий

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

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

L>Ты знаешь, почитал твою статью и не увидел (или не заметил?) ни слова о языках с динамической типизацией. А они как раз ИМХО отлично подходят для того класса задач на который ты нацелился.

Не то чтобы отлично, но подходят. Говорю как человек, который в основном такие языки и юзает

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

Хлеб должен быть белым. А икра... чёрт с ней, пусть будет чёрной.

V>заранее определённый и описанный набор типов).
Почему заранее определённый? Это для статических языков он заранее определённый, для динамических — всё вычисляется в рантайме. По крайней мере, никаких преград перед тем чтобы изменять типы в рантайме я не вижу.