前面我讲过了三种最最基本的编程范式：“文本编程”、“图形化编程”、“自然语言编程”（也许不是教科书上的编程范式）。其中，自然语言编程其实是文本编程一种“泛化”后的结果，使得编程门槛变得非常低，当然也存在一些自身的限制，我就不在这里多说了，有兴趣的，看我前面发的文章。

 

今天我们换一个新话题：面向“模型编程” vs. 面向“组件编程”。

 

 

低代码平台典型的——面向“模型编程”的平台

怎么理解面向“模型编程”呢？这样说也许有点抽象，我给大家举一个简单的例子，现在“低代码平台”基本上都是“面向模型”编程的例子，通常是这几个模型的组合：BPM模型、表格模型（类似Excel）、表单模型、BI模型等等，还有一些做其它模型的，例如“网站模型（WorldPress）”、“电商模型”、“H5模型”、“游戏模型”、“CRM模型”、“ERP模型”、"大屏幕展示互动模型"等等，由于这些很难融合在一起，基本上都是各做各的，以单独的产品形态存在。

 

 

面向“模型编程”平台优缺点

 

优点：

1. 结合模型本身可配置性，修改的效率很高；
2. 模型本身的操作复杂度不大，对于一些非专业人员，也可以简单操作配置和使用模型。

 

缺点：

1. 模型本身的颗粒度相对将大，灵活性方面有限制；而很多模型并不够支持复杂场景需求；
2. 模型之间打通难度较大，不光是产品侧的难度，有些技术上也很难打通；
3. 模型的通用性会受自身的“编程语言”和“开发框架”所限制，进一步限制模型和现有系统的适配能力。

 

总结：

“面向模型”系统构造一个代码和应用的中间层，甚至直接给“业务人员”使用（例如低代码平台），但是也同时会陷入两难的困境，“如果抛弃代码，灵活性受限制；如果使用代码，业务人员无法使用”，所以，发明了“低代码”这个词😆。

面向模型编程尤其积极的一面，但是并不能很好解决开发（特别是企业开发）中各种复杂问题，和现有编程环境和现有代码资源结合也是一个很大的挑战。

另一方面，由于模型之间的耦合问题，很多“低代码”平台不得不整合很多个子系统，每个子系统完成独立的事情，这无疑增加了开发者的学习和操作成本。

 

 

iVX、Scratch典型的——面向“组件编程”的平台

“一切皆组件”，是面向“组件编程”的特点。在产品设计中，一切的“面向对象”“一切皆组件”表现的非常明显。组件的颗粒度还可以进一步进行分层设计，小颗粒的各种“变量”可以是组件、常见的应用基本元素“图片”“文本”“音视频”是组件、容器是组件、逻辑结构是组件，甚至后台的“数据”、“加密”、“通信”等等都是组件；如果再加上分层的设计，几乎万物都可以由组件构成，并通过交互完成各种复杂逻辑。这有一点像“宇宙本身的设计 Big Design”，基本粒子——原子（元素周期表）—— 复杂分子 —— 更复杂结构。

 

（iVX的组件架构和元素周期表）

 

当然，光有“一切皆组件”还是不够的，还要加上“可视化逻辑”表达（或者说逻辑编排），才能真正构成应用（这个我以后再讲）。

 

 

iVX和Scratch就是典型的面向“组件编程”的平台产品，免费且自带IDE，大家可以去体验一下。

 

 

面向“组件编程”的优缺点

 

优点：

1. 颗粒度足够小，如果设计好，功能可以很强大，和编程语言没有太大差距；可以开发各种企业和个人应用，甚至做中大型应用也没有问题；
2. 和代码兼容性好，甚至都可以生成各种语言的代码文件，可以很好使用现有的代码资源，也可以容易已有的开发环境；
3. 学习难度比“面向模型”要大很多，但是比学习“编程语言”那就要简单太多了，而且开发效率、调试效率、运维效率都要高很多。

 

缺点：

1. 虽然去掉了语法，虽然是图形化界面，但是相比面向“模型”编程仍然有一定学习曲线，需要开发者有一定的“程序逻辑”思维；
2. 产品稀缺，开发这样产品难度很大。

 

 

总结：

感觉面向“组件编程”很有可能是下一次“编程技术革命”的开始，更低的编程学习门槛，更高的开发效率和运维效率，都可以进一步释放“技术生产力”。

 

 

两种技术结合可能很有前景

现在来看面向“组件编程”更加底层，更具备“编程语言”属性；而面向“模型编程”更容易操作，对用户要求也更低，甚至，可以在模型侧加入面向“自然语言”，那就完美了。所以我认为，理想的编程体系应该是这样的😝：

 

 

（简单来说就是：面向组件编程开发各种模型，然后通过自然语言接口来操作模型。😝完美）