Хм Ща меня (в роле Лоханкина ) наверно будут сильно бить, но у меня опять осеннее обострение, извиняйте и если чего, то это скорее всего отправится в юмор, но пока злые черти побермудят воду во пруду...
Закралась давным-давно у меня навязчивая идея, не решался огласить вслух всем, ибо стыдно(хотя совести у меня нет) за обострение! Может её бессмысленности уже сто лет, но на то я и... что бы увидеть в ней брешь неизученности Причиной произошедшего явилось то, что начитался тут судьбоносных тем по поводу ФП/АОП, статичиской и динамической типизации, ИИ, нейросистем, управляемого термояда, вопросов применения Ur-235 и Co-60 в домашних условиях и даже попытки создания R#, а про генетику, акромя скромных потуг на клонирование, ничего не звучало, хотя это и есть, как мне кажется неприкрытый пуп Земли После чего наверно я окончательно рассеялся как обычно
Скажите мне правду!
Может были некоторые задумки/исследования или уже где-то применяется ... генно-ориентированное программирование или что-то подобное?
Ой, может я перебощил, может это все-таки того не стоит называть...
Интересует конечно не библиотеки, сборки и даже не пространства имен генетической направленности (хотя это тоже интересно), а простая на мой взгляд, хотя может и бредовая по-сути /прошу мне на это указать как можно деликатнее / идея написания программ в такой среде разработки с языковыми средствами, которая могла бы самостоятельно понимать как совмещать (не знаю, как правильно и назвать то это, может — абсорбировать /агрегировать/конкатенировать или ещё как...) классы по общим признакам доминирующих и рецессивных (подавленных) полей виртуальных методов их одноименных полей одинаковой сигнатуры в некий суб-класс (от слова "субъект") на этапе разработки и при множественно-сборочной компиляции (т.е. в рамках компонентной модели). Реализации чего-то сродни принцыпу генетических механизмов подавления признаков. При этом мне кажется уместно было бы предусмотреть методы-агенты для "совмещения несовместимого" кода методов при замене доминирующими методами рецессивных (наподобии специализаций в дженериках), а так же какие-то правила (наподобии области видимости кого с кем вообще можно совмещать,а кого нет ), а может быть нужны и сложные механизмы приоритетов при отборе доминирования. Нужно понимание о прозрачных и простых правилах и конструктивных средствах употребления всего этого вместе с ООП и ИЯ. Например, просто создавая объект какого-то класса, компилятор сам понимал какой цепочкой классов (доминирующего и набора рецессивных ему) надо воспользоваться и проч. Интересны общие правила автоматической компановки цепочек по признаку этого всего, что бы можно было понять это не только на интуитивном уровне. Если об этом что-то было, то мне думается что обязательно как-то должно укладываться в компонентную модель.
Прошу так же заметить, что кажется это не лежит в плоскости вопросов о множественном наследовании, и тем более дженериков/шаблонов, скорее наверно наоборот, должно решать им ортогональную задачу. Кажется, что необходимость в этом только при совмещении классов, не имеющих общих предков, т.е. описывающих разные, но имеющие некоторое соприкосновение предметные области классов, ну или только на уровне общего базового класса.
И ещё... вот это уже может быть и совсем не к месту... органические и неорганические классы
Т.е. идея в том, что органические классы не могут иметь конструкторы/деструкторы, а их роль — быть вспмогательными к органическим и совмещаться с ними при создании такой агрегации, или может это называется вирусами?
Здравствуйте, AMogil, Вы писали:
DG>>Генные алгоритмы используются для оптимизационных задач, когда нет четких алгоритмов для решения этих же задач.
AM>... или они слишком дороги.
Генетические алгоритмы это один из самых дорогих способов решения задачи, хуже как правило только полный перебор вариантов.
Здравствуйте, DarkGray, Вы писали:
DG>Генные алгоритмы используются для оптимизационных задач, когда нет четких алгоритмов для решения этих же задач.
Ну в принципе об этом и речь — оптимизация библиотек классов на этапе их проектирования наверно не всегда заранее имеет четкие алгоритмы?
Это дело программиста, а тут и с рефакторингом могут помочь такие языковые средства и инструменты разработки, несущие в себе генетический подход поверх существующего императивного или декларативного... ну как вносит АОП свой вклад с помощью атрибутов
Здравствуйте, AndrewVK, Вы писали:
AVK>Здравствуйте, AMogil, Вы писали:
DG>>>Генные алгоритмы используются для оптимизационных задач, когда нет четких алгоритмов для решения этих же задач.
AM>>... или они слишком дороги.
AVK>Генетические алгоритмы это один из самых дорогих способов решения задачи, хуже как правило только полный перебор вариантов.
Дорогих в чем? В том, что их использование не поддается хорошей формализации и общности при применении?
В простейшем виде это работает в Паскале. Можно написать sin или Sin или SIN, система сама все уладит.
Сложнее в Прологе. Но там данные тоже все еще формализованы, в частности отрицание работает. Система либо доказывает отрицание цели либо находит все решения. А в общем случае нужна огромная база знаний.
MA>1) Интересует конечно не библиотеки, MA> сборки MA> и даже не пространства имен генетической направленности (хотя это тоже интересно), а
... MA> 2) идея написания программ в такой среде разработки с языковыми средствами, которая могла бы самостоятельно понимать как совмещать (не знаю, как правильно и назвать то это, может — абсорбировать /агрегировать/конкатенировать или ещё как...) классы по общим признакам
MA>доминирующих и рецессивных (подавленных) полей виртуальных методов их одноименных полей одинаковой сигнатуры в некий суб-класс (от слова "субъект") на этапе разработки и при множественно-сборочной компиляции (т.е. в рамках компонентной модели).
MA> Реализации чего-то сродни принцыпу генетических механизмов подавления признаков. При этом мне кажется уместно было бы предусмотреть методы-агенты для "совмещения несовместимого" кода методов при замене доминирующими методами рецессивных (наподобии специализаций в дженериках), а так же какие-то правила (наподобии области видимости кого с кем вообще можно совмещать,а кого нет ), а может быть нужны и сложные механизмы приоритетов при отборе доминирования.
MA> Нужно понимание о прозрачных и простых правилах и конструктивных средствах употребления всего этого вместе с ООП и ИЯ.
MA> 3) Например, просто создавая объект какого-то класса, компилятор сам понимал какой цепочкой классов (доминирующего и набора рецессивных ему) надо воспользоваться и проч. Интересны общие правила автоматической компановки цепочек по признаку этого всего, что бы можно было понять это не только на интуитивном уровне.
MA> 4) Если об этом что-то было, то мне думается что обязательно как-то должно укладываться в компонентную модель.
MA>Прошу так же заметить, что кажется это не лежит в плоскости вопросов о множественном наследовании, и тем более дженериков/шаблонов, скорее наверно наоборот, должно решать им ортогональную задачу. Кажется, что необходимость в этом только при совмещении классов, не имеющих общих предков, т.е. описывающих разные, но имеющие некоторое соприкосновение предметные области классов, ну или только на уровне общего базового класса.
Интересно, даже очень.
В настоящее время меня интересуют схожие мысли, которые кратко можно назвать как Enviroment-based metaprogramming.
Знаете, как развивается ребенок из клетки ( в начале ткань одна, но потом происходят дифференциация, и.т.д. раскрутка и запуск процессов, более того, развитие каждой группы клеток базируется на окружении (enviroment) которое, в некоторой степени детерминирует этот процесс, т.е. фактически управление идет не сверху — раскрутка, а снизу — самоопределение).
Идея enviroment метапрограммирования имеет богатые пересечения с теорией Фреймов (контекст и распознавательные задачи Бонгарда, распознавание речи в контексте перестановки предметов (ШРДЛУ из MIT )).
Можно подумать
MA>И ещё... вот это уже может быть и совсем не к месту... органические и неорганические классы MA>Т.е. идея в том, что органические классы не могут иметь конструкторы/деструкторы, а их роль — быть вспмогательными к органическим и совмещаться с ними при создании такой агрегации, или может это называется вирусами? MA>
Предлагаю попытаться реализовать это на программном уровне, то есть попытаться полность переложить на процесс программирования (создания некого программного продукта) те процессы которые происходят в живых клетках. Если кому интересно то присоединяйтесь. http://neuronet.alo.ru всё необходимое (в плане ресурсов) есть, осталось только за малым найти безумных людей.
Здравствуйте, noxius, Вы писали:
N>Предлагаю попытаться реализовать это на программном уровне, то есть попытаться полность переложить на процесс программирования (создания некого программного продукта) те процессы которые происходят в живых клетках. Если кому интересно то присоединяйтесь. http://neuronet.alo.ru всё необходимое (в плане ресурсов) есть, осталось только за малым найти безумных людей.
А что, объединение теорий без компьютера провести нельзя?
Лучше этим займись. Потому что дело не в людях, а в построении теории.
Здравствуйте, mister-AK, Вы писали:
MA>Может были некоторые задумки/исследования или уже где-то применяется ... генно-ориентированное программирование или что-то подобное?
Какое то слишком громкое название:
Gene Oriented Programming, или сокращенно ЖОП
Это скорее ближе к вычислительной математике, для ЖОП конкуренты не столько ООП,АОП, сколько какой нибудь алгоритм градиентного спуска — ускорение случайного перебора. По разному его можно ускорять.
) наверно будут сильно бить, но у меня опять осеннее обострение, извиняйте и если чего, то это скорее всего отправится в юмор, но пока злые черти побермудят воду во пруду... 
генно-ориентированное программирование или что-то подобное?
