编程中，功能定义与执行分离

编程中，功能定义与执行分离-可行性及优势

暂时是没有什么语言可以支持功能定义与执行分离的，很多的情况下都是执行的机器有自己的功能定义加载的编译代码

可行性

也许对于看到这个标题的人有不清楚或者不屑阅读的，请见谅，可以当作我愚见的体现
当前功能定义域执行的特点：

1. 系统应用 ，编译打包后是需要在执行机器上传指定目录（不包括运行环境）；
2. 本地从存储加载到内存具有更快的速度；
3. 应用迭代会存在不断更新的内容，所有执行机器需要及时同步，扩展更多服务器需要检查运行环境及相关目录，用户权限；
4. 这是对于运维最容易理解的应用部署方式；

猜想的优势

1. 系统应用 ，编译打包后是只需要在系统应用管理机器上传指定目录，进一步编译成模块化的机器执行代码；
2. 执行机器可配置较少的运行环境，执行单位不以系统应用为单位，而以需要调用的服务或者功能为单位，忽略执行机器的业务层面的逻辑；
3. 应用迭代只需要系统应用管理机器更新内容，所有执行机器需要只需要同步获取功能可执行机器码，扩展更多服务器需要检查运行环境及相关目录，用户权限；
4. 执行机器的负载均衡颗粒度达到交易功能执行，充分并均衡的利用执行机器的执行能力，甚至可以根据不同交易的执行是否占用过多内存单独分配大内存的执行机器；

功能定义与执行分离-对编程语言的要求

增加对功能细分的机器码生成

以一种任务获取的标准请求，来返回固定格式的流等信息
系统应用管理机器上极细颗粒的机器码存储在内存中，
功能任务定义获取基于常见通信协议，支持中间层的负载

增加对功能细分的拆分打包

系统应用的打包可以拆分打包，针对较大型的应用要求耦合度层次不大于3，不存在循环依赖的问题
便于在不同的系统应用管理机器