EOS/普元：中國IT業的悲哀

公司引入了普元的EOS做爲公司的基礎架構平臺，從此的全部項目將逐步向EOS的遷移，但對EOS的研究又讓我不得不說出如下話：

一、EOS確實夠簡單，但未免簡單過了頭：從語言層面看EOS
由於EOS將成爲咱們的開發語言，因此有必要從語言的層面認識EOS。
去除EOS的圖形化外衣，咱們看到EOS就是一門以XML表示的相似Basic的腳本語言，這門語言至關簡單，由於其語法元素極少，以下：

過程聲明 <-> 構件的建立
過程調用 <-> 構件調用
條件語句 <-> 構件圖中的IF結點
循環語句 <-> 構件圖中的"{" 和 "}"結點

由於語法元素少，加之圖形化的編程方式，這就造成了EOS的」入門容易「的優點。

如今讓咱們理清思緒，仔細考察這門簡單的語言，咱們會發現這門語言竟是如此簡單，甚至連最基本」變量聲明與賦值操做「的語法元素都不具有，你們是否會以爲驚呀？這是由於EOS不須要聲明變量，EOS提供了一個全局變量給全部的構件使用，這就是EOS大力吹捧的」XML數據總線「。
全局變量和局部變量都不需聲明，能夠直接使用，那麼語言編譯器是否能夠提供類型檢查，或者是否能提供」未用變量「的警告的呢？答案是不能，這些問題必須在運行時才能解決。

進一步沿着語言層面思考下去，咱們會發現這門語言」沒有類型「，注意我說的不是」弱類型「或」類型檢查「。這門語言中全部變量所有都是」字符串「，系統也不能提供格式化的機制實現其宿主語言(java)類型與字符串間的轉換。

有人可能會懷疑，既然這門語言這麼簡單，功能這麼弱，那它根本就不可能在實際項目中使用，而咱們從普元的宣傳和他長長的客戶名單列表裏頭看到的並非這樣的情況，這是爲何呢？其實答案仍是在java，由於java是EOS的宿主語言，也就是說咱們可將EOS看做相似groovy/jruby之類的擴展語言，當這些擴展語言實現不了某些功能時，咱們就能夠直接使用宿主語言進行開發，這就與在C語言中使用匯編相似。

好了，如今咱們已經清楚EOS實際提供了兩個語言層面：一個是簡單但功能弱的語言層面，一個是複雜（java複雜嗎？）但功能強大的語言層面。這種作法其實和groovy/jruby沒什麼區別。

討論了語言，如今能夠設想一下這門語言的應用，我設想的EOS應用的最佳方式是將EOS做爲一個工具包，以利用EOS的圖形化能力給應用提供可視化的配置能力，固然對於以工做流爲核心的應用，將EOS做爲流程配置的工具也是極佳的應用方式。這樣的應用方式就相似於將groovy應用於項目的單元測試同樣，由於這些擴展語言由於其某些不足不能夠成爲應用的基礎（核心）語言。

然而，普元公司可不這樣定位本身的產品，他們但願本身的EOS做爲應用的平臺或者核心語言，如今扯上SOA的大旗後，EOS甚至能夠做爲企業的基礎架構，我想問：EOS能當此大任嗎？

二、構件？
EOS宣傳的」構件「是什麼意思呢？其對」構件「的定義是」構之件也」，好象仍是不明白吧？
讓咱們再次從語言層面來看這個問題，EOS中的構件就是過程，其實再簡單不過，更準備地說，EOS中的構件就是一個不過參數沒有返回值的過程，這樣的過程其語義如何準確描述和定義呢？EOS的構件一樣沒法解決這一問題，那麼構件的組裝就和過程的嵌套沒有什麼兩樣。
甚至於EOS中的構件都算不上是」模塊「，由於模塊一般包括了一組功能或者說一組接口。而EOS的構件只有一個功能，所以將EOS的構件理解爲」接口「也是錯誤的。然而EOS的產品白皮書以及EOS在市面上的宣傳都有意忽略了EOS構件的本質的特徵，這些只是爲了忽悠的須要，說的和作的根本不是一個東西。固然咱們你們都能理解，這就是國情。

三、IDE的做用？
圖形化的IDE對咱們應用的做用是核心的，本質性的嗎？應用甚至企業的基礎架構的圖形化有這麼重要嗎？開個玩笑，也許EOS的插件自己就能夠用EOS自己來實現，這樣這門語言就是自洽的了。

四、EOS與IOC有關係？
EOS和IOC有關係，這個說法比較新鮮。EOS的構件本就是過程式的，何來依賴注入？難道是說EOS能自動注入一個構件所須要的嵌套構件，這就能夠稱爲IOC了？這樣說任何語言都是IOC的。

五、EOS的O-X mapping？
O-X mapping？照貓畫虎也畫得太不象了吧，EOS中何來對象，何來「O」？竟敢也趕這個時髦。
我理解EOS所說的O-X mapping只是將數據庫中的記錄取出放到其XML總線上，這就叫記錄到XML的映射了，只是仔細瞭解過EOS的數據庫操做構件的人都應該明白這個O-X mapping的含義吧。這樣的名詞只能拿來嚇唬一下半懂不懂的經理級人物，李佳不也說這應該叫作X-R mapping嗎？

六、EOS與AOP？
EOS有一個組件攔截功能，具體說就是容許爲組件配置一個過濾器，以實現組件調用前的處理和組件調用後的處理，這個功能實在是太簡單了，達到幾乎沒有實用價值的地步。這樣一個功能也能扯上AOP嗎？諸位本身判斷吧。



說了這麼多，在不斷佩服EOS的攻關能力的同時，也不斷地爲國內的IT技術人而悲哀。在我看來，稍有技術敏感的人都應該能看到EOS做爲企業技術平臺的嚴重問題，然而現實是那麼多的作了多年技術的程序員/經理/老總們，居然都那麼迷信圖形化，那麼討厭代碼，輕易作出將EOS作爲基礎架構的決策。這不是中國IT產業的悲哀嗎？

參考資料：
http://www.iteye.com/topic/13888?page=1
http://canonical.iteye.com/blog/33794
http://canonical.iteye.com/blog/33795
http://www.bjug.org/20050524.html

http://www.iteye.com/topic/210475