可視化編程能夠取代高級語言嗎？即使現代的計算機技術得到了飛速發展，可視化編程取代高級語言依舊是其行業內最高理想。本文將從國內外流行的可視化編程商業工具入手，分析現階段可視化編程的侷限性，以及未來可視化編程的發展前景。
之前在知乎看到了一則較早的問題 現在的可視化編程發展到什麼程度了，什麼時候可以取代高級語言？ 這在可視化編程行業內可是最高理想。但期中有一個回答真實反應了現實——可視化編程無法取代高級語言。接下來分析幾款國內外可視化編程商業工具（可以做出商業產品），從而分析一下可視化編程的桎梏，以及可能的發展前景。
國內外幾種商業可視化編程工具
1.Mendix
全行業做低代碼開發幾乎都用積木的方式去做，確實積木的拼接組合操作很容易，也符合程序員的操作習慣，但全行業似乎陷入了創意沼澤。這時候 mendix 出現在我眼前，流程圖式編程是哪個神經病想的，真有意思（下文的 Outsystems 也是相同的形式）。這裡引用一下別人對 mendix 的基本介紹:
“專攻企業應用開發，面向 B 端用戶，一般是面向有開發團隊的中大型企業，提供模型驅動 IDE 和微流，減少代碼量，使業務人員可以通過可視化組件參與到開發過程中，與程序員在 Mendix platform 上合作開發本企業的應用。提供一些企業解決方案、模板，開發平臺上也支持自定義 UI 和組件。擁有 Atlas UI Framework 開發框架，根據應用和業務類型，會推薦相關的模板和組件，達到快速開發的目的。內置 DevOps 功能，可以持續交付，也可以使用 Mendix platform API 集成其他 DevOps 工具。”
可以做原生 app，web 系統。但編輯器功能本身並不完善，給定的功能模塊無法滿足企業用戶的全部需求。本身有全棧的能力，最近還引入了 socket，但其設計的出發點還不是很適合國內的生態。接入微信等需要額外配置，很煩。編輯器界面本身足夠硬核，流程圖繪製本身就是可視化的經典與難點，箭頭的直觀性也很強。其工具只能企業或學生郵箱註冊，有興趣的同學可以註冊試試。
2.Outsystems
和 mendix 一樣也是針對企業的可視化工具，註冊需要企業郵箱。較早版本只包含基本的前端 UI 組件，目前已經豐富了很多。支持數據驅動的 list 組件，每種組件都有封裝的事件（這點大同小異，視每個工具的設計思路，有需要可以發郵件提）。css 樣式的編輯及其複雜，基本就是原生 css，沒有經過任何的封裝，說白了還是給前端程序員做的。
數據庫關聯可視化，這算是一大特色。基於關係型數據庫的可視化工具都應該這麼 neng。。通過發佈後的項目可以發現，他們早期官網主頁都不是用他們自己的產品做的。現在官網是用自己產品做的，但是點主頁這裡的導航點之後點點會鬼畜地上下抖動，可以說每個在線編程的主頁都是自己的門臉，希望能儘快優化吧。
其實國外這種商業可視化編程的工具還不少 bpmonline、Zoho Creator、微軟的 Microsoft PowerApps 。功能上各有千秋，但受限於線路問題和工具語言，在國內想推行起來還是有難度，那麼國內前沿的可視化編程水平怎麼樣呢，我就直接四個二加兩個王了哈！
3.iVX
ih5 團隊打造的 v4 版本，在國內網頁編輯器中處於鄙視鏈的最頂層。對於一個程序員而言可以利用 js 進行開發才能滿足其工作的成就感，但 ivx 可以做到對沒有編程基礎開發人員的有效對接。ivx 的組件數量比起國外的產品不是最多的，但確是最契合中國開發需求的，封裝全面的微信功能，支持方便認證登錄（封裝好的取 openid/unionid 的方法），支持微信支付 / 紅包，各種移動端選擇器，直播組件（限企業用戶）。支持微信小程序、web 開發、原生 app（4.1beta），後端接口 / 數據庫的操作也相對簡單。對於國內做外包的從業者而言確實能節省人員和學習成本，但可視化編程即便如此依然有其無解的侷限。
scrtch 在可視化編程領域很具有代表性，但相對初級，僅針對兒童教育。另外像部分 apaas 的 crm 編輯器由於功能太過單一也沒有拿出來說。
侷限
1. 功能 / 性能的侷限
看了之前介紹的產品，即便是當中功能最完備的，相比起一門語言來說是不是依舊顯得單薄無力。即便可以代替傳統程序員開發中檔產品，但要說可視化能取代高級語言無疑是在宣稱制造零件不需要自然資源，不論用什麼新材料新工藝製造零件，其本源都要依賴自然資源。利用高級語言開發好比將礦石做成零件再拼裝，可視化編程好比拿到現有的零件組裝。零件是否好用只能依賴別人，雖然像 ivx、mendix 有自定義組件的功能，但那依舊是對已有組件的封裝，無法真正意義上與 w3c 完美對接。一門高級語言有多少的操作空間？想想 3-4 年前 js 都能寫人工智能了呢。可視化工具要想寫深度學習該怎麼做？估計只能引用外部接口。
性能問題就更不用說了，由於可視化編程的目的基於開發商業產品，其限定死了程序的執行只能是單線程的，最終將用戶的 js 用 evil 嵌入最終的包。因此沒有一款編輯器敢開放 web worker 功能。
2. 社會因素 / 混亂的生態 / 沒有標準
在大廠呆過的同學一開始一定很好奇為什麼要經常重複造輪子，網上明明有很多封裝好的庫，怎麼不能拿來直接用呢？安全問題、法律問題、技術儲備，這些都是社會屬性性對人類發展的影響。react 中發現存在隱藏協議的時候百度連夜重構代碼，之後改用修改過的框架開發了。
與開源的框架不同，可視化編輯器是開發團隊賴以為生的產品，除了麻省的 scratch、pblock 面向教育的公益類可視化開源項目外，其他不管 to B 還是 to C 的產品基本都要收費（Outsystems、mendix 針對在校生免費，ivx 在一定流量額度下免費，其餘國內大部分產品只要使用都收費）。這導致的第一個問題是生態的缺乏，一個人想要學習使用還要有這樣那樣的條件限制，那在校生或剛入行的人寧願去選擇行業認可的技術。第二個問題是由於市場沒有被某個或某些廠家壟斷（想想 dji 出數字圖傳套件前 fpv 圈子的生態），導致了一家一個標準。一個程序員熟練使用 5 個主流語言 3 款框架就差不多了，因為主流語言就那麼多，但是市場上的可視化編程公司幾百家，而且做得好的都是自研，沒有統一的標準，每家的特色和亮點都不同，到底選誰是很大的問題，都選怕你時間不夠。這種混亂導致了小白的迷茫和程序員的不屑，不如學好基礎自己開發。
3. 相關研究不足
low code develop 是國外傳入的概念，被中國互聯網人翻譯為低代碼開發，在國外炒了有一陣了。相關的技術文章有多少呢？先從 eric 查一下國外的研究狀態，完全搜不到相應的研究，怎一個慘子了得：
再來看看 cnki，3 個結果，一篇真相關還是科普文，學教育技術的同學你們的研究方向有了！
學界的研究向來喜歡偏向資本市場或爭議問題，區塊鏈、深度學習、轉基因等課題都要經過一段時間的資本宣傳或輿論發酵才能讓這些教授學者關注這些議題。比起可視化編程的市場綜述研究和發展潛力研究，學界倒是對可視化編程、scratch 等教育學議題更加關注，畢竟現在兒童編程有資本注入。當有了一定學術支撐後，研究和使用的人就會逐漸增多，相應的標準或評級也能展開，間接可以讓混亂的學習生態聚焦主流。
總結
可視化編程取代高級語言在短期內不可能實現。首先市場的發展陷入守城之勢，真的得出現類似 dji 參與 fpv 開發、騰訊出小程序等事件，某個大廠介入出一套東西然後主推，改變大家的編程習慣然後可視化編程立刻進入大家視野切逐漸形成一套生態。否則可視化編程依然只能是小眾的開發方式。
從技術角度說一款圖形 IDE 無論如何做不到一門語言的完整性，作為一種開發方案，可視化編程極力做到錦上添花，簡化開發流程，節約開發成本，完善最終編譯結果，代替一般 web/ 小程序項目的開發模式是完全沒問題的。
閱讀更多 JAVA柯尼塞克丶 的文章
