I think I'm not making my point across. There's no way to predict all procedures one will use and build functions before hand for all possible combinations, but if the building blocks allow certain rules, then nobody even needs to make knee-jerk functions for these and be delayed every time they try something new but only loop for something custom.
Whether you do the changes in a specific function or you do the changes with building blocks. Essentially it is both same - Semantics otherwise.
I think you might be mis-understanding my intent and taking my suggestion for creating your own functions as something more akin to writing a lengthy script that is only specific to your task at hand. But I wasn't.
Your functions can be the ‘building blocks’ where you combine the different functions which ever unique way you want to without ever having to build a new function.
The key to doing that effectively is to recognize what operations are you doing often and repeatedly. In such cases when you see something pop up like that often - it becomes a great canditate for a function.
Like your mentioning of ‘vector * vector’ . Not having used vops much I was assuming your always having to do ‘extra’ work repeatedly to get the result. So why not put that into a function was my suggestion.
But all this may be moot if you can't eassily ‘wrap’ those functions you create as a ‘node’ you can just drop down in a vops network like the other Houdini default selections.
Of course I am aware of the inline and vex smippet nodes. If it's possible the same way as with wrangle nodes;
You could externalize reference to those functions by just using #include <C
and call up your function whenever needed.