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

Теперь представим ситуацию — исходники существуют сами по себе, а программа на выходе — не есть пассивная копия исходников, а как бы живет своей жизнью (притом разумной, хотя и не до конца контролируемой). Например, возможны "фазовые переходы": т.е. при нарастании кода в исходниках объемность кода и сложность структуры программы — взаимоотношеия частей — могут до какого то момента соответствовать исходникам, а потом после некоторого момента резко (фазово) перестаиваться и упрощать (или усложнять — при наличии собственной базы знаний у компилятора и ситуационного контекста) внутреннюю структуру самостоятельно (интеллектом компилятора).
Или другой пример (хотя речь идет о том же самом): исходники могут задавать сколь угодно сложную взаимосвязь частей, а результирующий код будет содержать эквивалентную по функциям, но ИНУЮ (не обязательно упрощенную) структуру взаимосвязи и функционирования.
Что то подобное работает при оптимизации кода, логических выражений булевой алгебры, но я задаюсь "проблемой" распростарнения этого подхода на функциональную структуру в целом.

Жду любых соображений...

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

S>Тема реально философская. Как-то это можно сформулировать в математических терминах и возможно есть даже мат.теории на эту тему, но я не знаю как.
S>О чем речь.
S>Допустим вы что-то пишете на языке программирования типа С++. И вы точно знаете — если вы добавляете код в программу, то соответствующим образов в результирующем коде на выходе компилятора код будет практически пропорционально содержать кода (функций) больше. Если вы описываете функционирование программы как либо в ЯП, то в воплощенной программе функционирование (действия) как и структура (взаимосвязь) частей почти точно будут повторять те же взаимосвязи в исходнике.

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

S>Жду любых соображений...
Соображение №1: попробуй упорядочить свои мысли. Что такое, к примеру, "функциональая структура"? Чего именно ты хочешь добиться? Распространение подхода — это не проблема. Какую именно проблему ты хочешь решить?

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

S>Соображение №1: попробуй упорядочить свои мысли. Что такое, к примеру, "функциональая структура"? Чего именно ты хочешь добиться? Распространение подхода — это не проблема. Какую именно проблему ты хочешь решить?

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

Здравствуйте, salog, Вы писали:
S>>Соображение №1: попробуй упорядочить свои мысли. Что такое, к примеру, "функциональая структура"? Чего именно ты хочешь добиться? Распространение подхода — это не проблема. Какую именно проблему ты хочешь решить?

S>Проблему программирования без программирования
А подробнее?

S>и создания (поиска) компилятора реализующего, как вариант, эвристический алгоритм.
Вопрос создания (поиска) компилятора реализующего, как вариант, эвристический алгоритм, подробно освещен в литературе.
В частности, очень помогает серия Аппеля "Modern Compiler Implementation", он ее уже по-моему про все языки написал.

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

S>Тема реально философская. Как-то это можно сформулировать в математических терминах и возможно есть даже мат.теории на эту тему, но я не знаю как.
S>О чем речь.
S>Допустим вы что-то пишете на языке программирования типа С++. И вы точно знаете — если вы добавляете код в программу, то соответствующим образов в результирующем коде на выходе компилятора код будет практически пропорционально содержать кода (функций) больше. Если вы описываете функционирование программы как либо в ЯП, то в воплощенной программе функционирование (действия) как и структура (взаимосвязь) частей почти точно будут повторять те же взаимосвязи в исходнике.

Эквивалентность двух программ — тема исключительно общирная и в тоже время древняя как говно мамонта (по меркам ИТ). Обычно говорят, что программа А эквивалента программе Б если, на всех возможных исходных данных обе программы 1) либо завершаются с одинаковым результатом, 2) либо зацикливаются. К сожалению в общем случае задача эквивалентности алгоритмически неразрешима. Это следует еще из трудов великого и могучего Алана Тьюринга. Поскольку задача в общем случае неразрешима, то человечество придумало "зауженные" аналоги понятию эквивалентности, которые могут применяться в отдельных частных случаях. Имхо наиболее далеко в этом деле ушла теория схем программ. Вот тут книжка.

ЗЫ вообще тем исключительно инетересная, сейчас как раз пишу кандидатскую по сходной проблеме.

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

S>Жду любых соображений...

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

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

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

S>>Тема реально философская. Как-то это можно сформулировать в математических терминах и возможно есть даже мат.теории на эту тему, но я не знаю как.
S>>О чем речь.
S>>Допустим вы что-то пишете на языке программирования типа С++. И вы точно знаете — если вы добавляете код в программу, то соответствующим образов в результирующем коде на выходе компилятора код будет практически пропорционально содержать кода (функций) больше. Если вы описываете функционирование программы как либо в ЯП, то в воплощенной программе функционирование (действия) как и структура (взаимосвязь) частей почти точно будут повторять те же взаимосвязи в исходнике.

C>Эквивалентность двух программ — тема исключительно общирная и в тоже время древняя как говно мамонта (по меркам ИТ). Поскольку задача в общем случае неразрешима, то человечество придумало "зауженные" аналоги понятию эквивалентности, которые могут применяться в отдельных частных случаях. Имхо наиболее далеко в этом деле ушла теория схем программ. Вот тут книжка.

C>ЗЫ вообще тем исключительно инетересная, сейчас как раз пишу кандидатскую по сходной проблеме.

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

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