> However functions still have single entry/exit that limit reusability of the contents
I argue that is due to granularity of function implementation. After all, if I have:
f(x) = 2x + 3
That is really
g(x) = 2x
h(x) = x + 3
and f(x) = h(g(x)). So by breaking the function into irreducible pieces I have achieved maximum reusability.
It seems like the core argument here is that if we (effectively) break down all functions into their smallest granularities and have some sort of ability to (SQL) "SELECT" / project / join those functions together we'll enable some sort of higher-level ability to construct complex software.
There are three reasons I disagree with this:
1) The universe of irreducible functions is infinite.
2) The universe has state and evolves. This means that the (SQL) "SELECT" / project / join of functions described above must itself necessarily change its behavior with the evolution of the universe, and I suspect this (in itself) is an intractable problem.
3) From an API perspective, 99% of the APIs today do not even form a category. That is, I cannot directly connect one object (API) to another object (API) because no morphism currently exists to enable me to do so. Worse, what that morphism is depends on the product of the domain and range of the APIs being connected. Automatic code traversal via some sort of SELECT is doomed to failure unless the set of morphisms is complete. The alternative is to try to automatically generate the correct morphism based on the SELECT...
... and that is exactly what software developers do. So while Multix has some interesting features built into it, based on the above it appears that the goal of the research is to essentially build a god-like AI that writes the software for us. I think that's really why there is abundant skepticism here.
I argue that is due to granularity of function implementation. After all, if I have:
f(x) = 2x + 3
That is really
g(x) = 2x
h(x) = x + 3
and f(x) = h(g(x)). So by breaking the function into irreducible pieces I have achieved maximum reusability.
It seems like the core argument here is that if we (effectively) break down all functions into their smallest granularities and have some sort of ability to (SQL) "SELECT" / project / join those functions together we'll enable some sort of higher-level ability to construct complex software.
There are three reasons I disagree with this:
1) The universe of irreducible functions is infinite.
2) The universe has state and evolves. This means that the (SQL) "SELECT" / project / join of functions described above must itself necessarily change its behavior with the evolution of the universe, and I suspect this (in itself) is an intractable problem.
3) From an API perspective, 99% of the APIs today do not even form a category. That is, I cannot directly connect one object (API) to another object (API) because no morphism currently exists to enable me to do so. Worse, what that morphism is depends on the product of the domain and range of the APIs being connected. Automatic code traversal via some sort of SELECT is doomed to failure unless the set of morphisms is complete. The alternative is to try to automatically generate the correct morphism based on the SELECT...
... and that is exactly what software developers do. So while Multix has some interesting features built into it, based on the above it appears that the goal of the research is to essentially build a god-like AI that writes the software for us. I think that's really why there is abundant skepticism here.