Kickstarter 上的「可視化編程」項目 NoFlo 能寫出怎樣的程序？可以使編程更容易么？

01-28

相關鏈接：
Kickstarter &>&> NoFlo Development Environment by The Grid
NoFlo | Flow-Based Programming for JavaScript

我不樂觀：http://techsingular.net/?p=2041

歡迎探討。

對於大家編程的目的不一樣，讓程序員使用可視化編程，多少有點職業侮辱，但對於藝術家、設計師、新聞專業等行業的人來講，可視化編程（節點式）編程無疑為最快速地達到結果提供捷徑。現在的許多軟體都內置了節點式編程的模塊，如rhino的grasshopper，maya、houdini等動畫相關的軟體都有，有些為藝術家服務的程序本身就是node式編程，如vvvv。對於純理工科出身的人來講，應該也不陌生，比如世界上最早的node式編程應該是機械行業的labview。

我在建築行業呆過幾年，對grasshopper比較熟悉，用grasshopper編程後面都有點本能，需要高級功能自己coding，配合的效率比較高。但來到互聯網行業的時候，發現一個小小的模塊要寫很久，時間成本大的驚人。

對大方向還是很看好的，NoFlo了解不多，但我並不認為長篇的代碼會一直主流。

我對這種東西保持謹慎樂觀態度。

可視化的編程10多年前就有了，那時候就有些商業軟體提供UML的代碼生成，不僅僅是基於類圖對象圖的簡單框架生成，而是能一行代碼都不用寫的真正全程模型化。不過現實是，他們沒有流行起來。

去年做過一個項目。一個醫療器材公司希望用Model Based Development代替他們的現有開發流程，我的任務是用Rational Rhapsody實現一個prototype。RR是UML Based開發工具，理論上來說能把90%的代碼裝到UML圖裡。不過現實來說，理想和現實之間差距不小。

舉個簡單的例子，如果你想實現一個複雜的條件分支，嵌套的if和loop，如果你堅持用圖畫，那就是個悲劇。最後畫出來的圖誰也看不懂。如果你用圖來描述一個稍稍複雜的演算法，那恭喜你開啟了斯巴達模式。。

最本質的麻煩是，純代碼能提供的可能性是無限的，而且是明確無二意的。這些東西本質上無法用圖形提供更有意義的替代。想像一下，如果我讓你用圖形（不管什麼樣的圖形和翻譯規則，你可以自創）來描述一個冒泡排序，你該如何做？教科書上有許多冒泡的示意圖，但那僅僅是示意圖，隱藏了太多細節，無法被精確翻譯和執行。但是如果加入更多細節，那圖就變的沒法看了：你把麵條般的代碼真的變成麵條了。

圖形編程在大多數情況下都還是用來生成框架代碼的，這是它的長處。

我相信圖形編程在動態語言（比如javascript）上會有更好的表現，因為動態語言本身的就隱藏了很多細節，但是某些本質的問題是很難繞開的。

我覺得可視化編程的最終目的還是要化繁為簡的，如果可視化編程的粒度太細的話，那就沒有任何優勢了，如果能像python那樣模塊化，應該還不錯。

可視化編程我估計高手是絕對不幹的，大部分高手都喜歡搞底層開發，演算法，性能優化等等，如果一直抱著怎樣舒服怎樣來編程的態度的話，我覺得就當編程為一種興趣愛好，別當職業。

謝邀~這個作為程序員來說應該是觀望態度吧，可視化編程出現很久了。coder在code的時候，不僅僅只是考慮到可視化和快速，更應該考慮到程序的穩定，靈活，健壯性等，現在很多可視化的編程都能自動聲稱代碼，但是顯然，那些能夠使程序穩定高效的高質量代碼是無法生成的。

有太多的可視化編程了，也有太多的自動生成腳本了。但高質量的代碼，是無法生成的。