不是。搜Functional Reactive Programming有真相。
另外，FRP的概念被亂用太多，比如很多人誤以為Rx就是一個FRP系統，而其實根本不是。Rx是基於離散的Event Stream的，而FRP裡的一等公民不是Event，是連續的Behavior。基於連續的Behavior；有嚴格的指稱語義；滿足這兩點要求的引擎才是FRP。
提醒，還是加一些文獻引用吧。FRP的始祖論文是Conal Elliott和Paul Hudak的Functional Reactive Animation，不過文章年代久遠，不太好讀。建議從http://dl1.frz.ir/FREE/papers-we-love/functional_reactive_programming/a-survey-of-functional-reactive-programming.pdf這篇文章讀起，以及參考Conal Elliott今年的講座The Essence of FRP。開發方面，可以參考gelisam/frp-zoo · GitHub。
PHP和RUBY本身是非常適合寫GUI的，前者是無可非議的簡單，後者是無可非議的簡潔（內建一切常用函式的設定，使其書寫起來可以比同演算法的JAVA短七成）；不過像在下這樣RUBY和JAVA都幾乎沒寫過的人，坐下來想想也還是會選JAVA。嘛，就算真要讓使用者自己下個JDK也不會太費事兒啦（你夠）。話說機房不少機子會開機重置，弄得在下現在建立系統變數路徑的手速已經有點自信了……JAVA封裝exe的手段嘛，在下是記不太清了，不過企業方肯定是開發過不少好東西的，到時候要不要再去找找呢……用C的話，其實很快就能把系統框架寫好，這部分C++要比JAVA、PASCAL，甚至C SHARP還要快，但是C的圖形化實在是太煩了（至少對於在下來說），自己打到可調控的程度會累死人的（從零開始的話，真心可怕的工作量），普通的UI內部庫用C++寫是挺方便的啦，但除非真能找到現成的連結庫，不然這種差事兒在下是不會想選C的。也就是越底層，寫圖形化越煩死人……另，用其他手段封裝為GUI……在下還真不知道了，Microsoft的studio有沒有可能挑戰一下呢……想來是不行的吧。VB啊，如果是侷限於預設格式的話，這大概會是最方便的選擇了；不過擴充套件起來，呃，應該說要使介面更靈活一些的話，工作量瞬間就被抬高了；也算是個備選項了吧。——dspzzyP.S.像在下習慣的用文字編輯器寫完的“.JAVA”檔案，對比一下……幾百KB的檔案，這工程量，要老夫來至少是倆月的級別啊……一點都不小了啊喂……從經驗上猜測，你是要給幾個同事一個簡易平臺，使之對一些已有的資料庫檔案，或整合框架的一部分檔案，進行非框架的讀寫操作？假定規模是十人份級（嘛，針對IP工作的習慣，無視就好），物件是500KB的類級……這樣一想的話倒還真不一定要用JAVA了，反而順手下個VB就好了。唔姆……不過，從工程化的角度來講，在下還是會建議JAVA吧，嗯……
不是。搜Functional Reactive Programming有真相。
另外，FRP的概念被亂用太多，比如很多人誤以為Rx就是一個FRP系統，而其實根本不是。Rx是基於離散的Event Stream的，而FRP裡的一等公民不是Event，是連續的Behavior。基於連續的Behavior；有嚴格的指稱語義；滿足這兩點要求的引擎才是FRP。
感謝@neo lin提醒，還是加一些文獻引用吧。FRP的始祖論文是Conal Elliott和Paul Hudak的Functional Reactive Animation，不過文章年代久遠，不太好讀。建議從http://dl1.frz.ir/FREE/papers-we-love/functional_reactive_programming/a-survey-of-functional-reactive-programming.pdf這篇文章讀起，以及參考Conal Elliott今年的講座The Essence of FRP。開發方面，可以參考gelisam/frp-zoo · GitHub。
PHP和RUBY本身是非常適合寫GUI的，前者是無可非議的簡單，後者是無可非議的簡潔（內建一切常用函式的設定，使其書寫起來可以比同演算法的JAVA短七成）；不過像在下這樣RUBY和JAVA都幾乎沒寫過的人，坐下來想想也還是會選JAVA。嘛，就算真要讓使用者自己下個JDK也不會太費事兒啦（你夠）。話說機房不少機子會開機重置，弄得在下現在建立系統變數路徑的手速已經有點自信了……JAVA封裝exe的手段嘛，在下是記不太清了，不過企業方肯定是開發過不少好東西的，到時候要不要再去找找呢……用C的話，其實很快就能把系統框架寫好，這部分C++要比JAVA、PASCAL，甚至C SHARP還要快，但是C的圖形化實在是太煩了（至少對於在下來說），自己打到可調控的程度會累死人的（從零開始的話，真心可怕的工作量），普通的UI內部庫用C++寫是挺方便的啦，但除非真能找到現成的連結庫，不然這種差事兒在下是不會想選C的。也就是越底層，寫圖形化越煩死人……另，用其他手段封裝為GUI……在下還真不知道了，Microsoft的studio有沒有可能挑戰一下呢……想來是不行的吧。VB啊，如果是侷限於預設格式的話，這大概會是最方便的選擇了；不過擴充套件起來，呃，應該說要使介面更靈活一些的話，工作量瞬間就被抬高了；也算是個備選項了吧。——dspzzyP.S.像在下習慣的用文字編輯器寫完的“.JAVA”檔案，對比一下……幾百KB的檔案，這工程量，要老夫來至少是倆月的級別啊……一點都不小了啊喂……從經驗上猜測，你是要給幾個同事一個簡易平臺，使之對一些已有的資料庫檔案，或整合框架的一部分檔案，進行非框架的讀寫操作？假定規模是十人份級（嘛，針對IP工作的習慣，無視就好），物件是500KB的類級……這樣一想的話倒還真不一定要用JAVA了，反而順手下個VB就好了。唔姆……不過，從工程化的角度來講，在下還是會建議JAVA吧，嗯……