前面我講過(guò)了三種最最基本的編程范式：“文本編程”、“圖形化編程”、“自然語(yǔ)言編程”（也許不是教科書(shū)上的編程范式）。其中，自然語(yǔ)言編程其實(shí)是文本編程一種“泛化”后的結(jié)果，使得編程門(mén)檻變得非常低，當(dāng)然也存在一些自身的限制，我就不在這里多說(shuō)了，有興趣的，看我前面發(fā)的文章。

今天我們換一個(gè)新話題：面向“模型編程” vs. 面向“組件編程”。

低代碼平臺(tái)典型的——面向“模型編程”的平臺(tái)

怎么理解面向“模型編程”呢？這樣說(shuō)也許有點(diǎn)抽象，我給大家舉一個(gè)簡(jiǎn)單的例子，現(xiàn)在“低代碼平臺(tái)”基本上都是“面向模型”編程的例子，通常是這幾個(gè)模型的組合：BPM模型、表格模型（類似Excel）、表單模型、BI模型等等，還有一些做其它模型的，例如“網(wǎng)站模型（WorldPress）”、“電商模型”、“H5模型”、“游戲模型”、“CRM模型”、“ERP模型”、"大屏幕展示互動(dòng)模型"等等，由于這些很難融合在一起，基本上都是各做各的，以單獨(dú)的產(chǎn)品形態(tài)存在。

面向“模型編程”平臺(tái)優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

結(jié)合模型本身可配置性，修改的效率很高；

模型本身的操作復(fù)雜度不大，對(duì)于一些非專業(yè)人員，也可以簡(jiǎn)單操作配置和使用模型。

缺點(diǎn)：

模型本身的顆粒度相對(duì)將大，靈活性方面有限制；而很多模型并不夠支持復(fù)雜場(chǎng)景需求；

模型之間打通難度較大，不光是產(chǎn)品側(cè)的難度，有些技術(shù)上也很難打通；

模型的通用性會(huì)受自身的“編程語(yǔ)言”和“開(kāi)發(fā)框架”所限制，進(jìn)一步限制模型和現(xiàn)有系統(tǒng)的適配能力。

總結(jié)：

“面向模型”系統(tǒng)構(gòu)造一個(gè)代碼和應(yīng)用的中間層，甚至直接給“業(yè)務(wù)人員”使用（例如低代碼平臺(tái)），但是也同時(shí)會(huì)陷入兩難的困境，“如果拋棄代碼，靈活性受限制；如果使用代碼，業(yè)務(wù)人員無(wú)法使用”，所以，發(fā)明了“低代碼”這個(gè)詞。

面向模型編程尤其積極的一面，但是并不能很好解決開(kāi)發(fā)（特別是企業(yè)開(kāi)發(fā)）中各種復(fù)雜問(wèn)題，和現(xiàn)有編程環(huán)境和現(xiàn)有代碼資源結(jié)合也是一個(gè)很大的挑戰(zhàn)。

另一方面，由于模型之間的耦合問(wèn)題，很多“低代碼”平臺(tái)不得不整合很多個(gè)子系統(tǒng)，每個(gè)子系統(tǒng)完成獨(dú)立的事情，這無(wú)疑增加了開(kāi)發(fā)者的學(xué)習(xí)和操作成本。

iVX、Scratch典型的——面向“組件編程”的平臺(tái)

“一切皆組件”，是面向“組件編程”的特點(diǎn)。在產(chǎn)品設(shè)計(jì)中，一切的“面向?qū)ο蟆薄耙磺薪越M件”表現(xiàn)的非常明顯。組件的顆粒度還可以進(jìn)一步進(jìn)行分層設(shè)計(jì)，小顆粒的各種“變量”可以是組件、常見(jiàn)的應(yīng)用基本元素“圖片”“文本”“音視頻”是組件、容器是組件、邏輯結(jié)構(gòu)是組件，甚至后臺(tái)的“數(shù)據(jù)”、“加密”、“通信”等等都是組件；如果再加上分層的設(shè)計(jì)，幾乎萬(wàn)物都可以由組件構(gòu)成，并通過(guò)交互完成各種復(fù)雜邏輯。這有一點(diǎn)像“宇宙本身的設(shè)計(jì) Big Design”，基本粒子——原子（元素周期表）—— 復(fù)雜分子 —— 更復(fù)雜結(jié)構(gòu)。

（后圖1 iVX的組件架構(gòu)和元素周期表）

當(dāng)然，光有“一切皆組件”還是不夠的，還要加上“可視化邏輯”表達(dá)（或者說(shuō)邏輯編排），才能真正構(gòu)成應(yīng)用（這個(gè)我以后再講）。

iVX和Scratch就是典型的面向“組件編程”的平臺(tái)產(chǎn)品，免費(fèi)且自帶IDE，大家可以去體驗(yàn)一下。

面向“組件編程”的優(yōu)缺點(diǎn)

優(yōu)點(diǎn)：

顆粒度足夠小，如果設(shè)計(jì)好，功能可以很強(qiáng)大，和編程語(yǔ)言沒(méi)有太大差距；可以開(kāi)發(fā)各種企業(yè)和個(gè)人應(yīng)用，甚至做中大型應(yīng)用也沒(méi)有問(wèn)題；

和代碼兼容性好，甚至都可以生成各種語(yǔ)言的代碼文件，可以很好使用現(xiàn)有的代碼資源，也可以容易已有的開(kāi)發(fā)環(huán)境；

學(xué)習(xí)難度比“面向模型”要大很多，但是比學(xué)習(xí)“編程語(yǔ)言”那就要簡(jiǎn)單太多了，而且開(kāi)發(fā)效率、調(diào)試效率、運(yùn)維效率都要高很多。

缺點(diǎn)：

雖然去掉了語(yǔ)法，雖然是圖形化界面，但是相比面向“模型”編程仍然有一定學(xué)習(xí)曲線，需要開(kāi)發(fā)者有一定的“程序邏輯”思維；

產(chǎn)品稀缺，開(kāi)發(fā)這樣產(chǎn)品難度很大。

全面總結(jié)：

感覺(jué)面向“組件編程”很有可能是下一次“編程技術(shù)革命”的開(kāi)始，更低的編程學(xué)習(xí)門(mén)檻，更高的開(kāi)發(fā)效率和運(yùn)維效率，都可以進(jìn)一步釋放“技術(shù)生產(chǎn)力”。

兩種技術(shù)結(jié)合可能很有前景

現(xiàn)在來(lái)看面向“組件編程”更加底層，更具備“編程語(yǔ)言”屬性；而面向“模型編程”更容易操作，對(duì)用戶要求也更低，甚至，可以在模型側(cè)加入面向“自然語(yǔ)言”，那就完美了。所以我認(rèn)為，理想的編程體系應(yīng)該是這樣的：