共1 條記錄, 每頁顯示 10 條, 頁簽:
[1]
[瀏覽完整版]
標題：最近關(guān)于delphi python java 和設(shè)計的一些想法
1樓
wangxinxin 發(fā)表于：2010-12-14 10:50:19每個程序員就是藝術(shù)家，每個系統(tǒng)構(gòu)架師都是哲學家
這段時間我一直在思考各種設(shè)計上面的問題，原來一直寫delphi和一些其他腳本語言。對java一直沒有碰，這段時間看的比較多，也寫了一些小的程序，過程不說，1個月下來感覺只有四個字：不堪重負 ToT，可能你們還記得前段時間我抱怨了一下java的類庫之間的復雜關(guān)系，讓我完全沒有任何的線索
隨即切換到python重新實現(xiàn)一些功能，也許是有了前面的經(jīng)驗，寫的輕松了很多，雖然這段時間我連很多python的基本用法都沒學完，比如那個lambda函數(shù)，新奇呀~
用twisted寫了一個server，10多行代碼，java那邊用mina還沒有實現(xiàn)邏輯就已經(jīng)4、5個java文件了，當然大部分代碼ide都幫忙寫了，不過java類庫之間的邏輯關(guān)系復雜程度可見一斑。
以我對這兩個語言的了解程度，還不足以對他們評頭論足，我發(fā)現(xiàn)他們在設(shè)計思路上有一些很有意思的地方，寫下來，大家看看。
delphi聞名是他的RAD套路，還有就是所謂的“優(yōu)雅”，因為寫出來的代碼規(guī)范而且可讀性強，不過很遺憾，delphi的rad貌似也沒有太大的進展了，至于用“begin end”來保持的優(yōu)雅，我持保留意見，呵呵。期待后續(xù)的版本能繼續(xù)發(fā)揚RAD，這次支持泛型和unicode就很不錯，要是再多些語法糖就好了，恩啊恩啊。delphi仍然是我windows平臺下開發(fā)的不二選擇。
python的設(shè)計思路很像delphi，走的是rad的套路，用python寫東西的時候，明顯感覺到是拋開了詳細設(shè)計的，就是一切都面向?qū)崿F(xiàn)功能，他的語言設(shè)計是鼓勵你這么做的。python強調(diào)了函數(shù)和模塊，他的面向?qū)ο笪业椒炊X得有點半調(diào)子，不過無所謂，這些是意識形態(tài)上的東西，能解決問題就好。
而用java的時候，我還沒開始寫一行邏輯代碼，已經(jīng)被迫實現(xiàn)了4、5個接口了，而且我在沒有寫完之前，還不能把他們整合起來，也不知道是對是錯。心里懸著，感覺不舒服。
很有意思的是，python的思路很接近我最初寫程序的時候，什么都不知道，只要把東西做出來就好的那種思路，所謂初級程序員的做法。不過這個不是全部，python的開發(fā)過程非常強調(diào)自省，也就是重構(gòu)，說白了就是重新寫。而且目前的開發(fā)中更加注重的是在各種測試的情況下進行重構(gòu)，也就是是有保障的重構(gòu)，而非程序員一時性起，寫了也不知道對不對。我個人覺得這個是符合邏輯的，在沒有了解一個東西的時候做再多的設(shè)計都是空的，我原來也嘗試過，也看到過開發(fā)中到最后，完全和最初的設(shè)計沒有關(guān)系。失去控制，全靠程序員自己努力，更要命的是，牛B的SA還不愿意承認……
python可以做到這一點，是因為python代碼很精簡，程序員寫作的時間很短，就算是重構(gòu)這個時間消耗也比其他語言低很多，我覺得這是python做的最好的地方，他給這種“初級程序員”的開發(fā)模式提供了一個升級的可能
這段時間也很關(guān)心各種語言的效率，不可否認，java的jvm虛擬機是一個很厲害的東西，java的執(zhí)行效率在高端機器上和C在一個水平，一個可以自動管理內(nèi)存的語言做到這個地步，實在讓人驚嘆。同時java的開發(fā)效率比C又高了不知道多少倍。所以在服務(wù)器端java可以說當之無愧的王者。
這次準備放棄java轉(zhuǎn)而用python的主要原因其實是考慮到開發(fā)效率和rad的需求。前段時間考慮的方案是用java寫框架和效率要求嚴格的地方，然后用jython實現(xiàn)邏輯和效率要求不高的地方，不過這個想法首先被jython的超級低效率擺了一道，這個低效非常明顯而且不是幾十倍的問題，
然后自己感覺java的各種代碼之間各種交互很多，設(shè)計上找不到rad的感覺，我也會設(shè)計很多接口，封裝，然后工廠，不知道是不是被引誘了呵呵。
然后就是這次做的東西有探索的性質(zhì)在里面，所以我自己是沒有太多經(jīng)驗的，整個開發(fā)過程我預算了1次完全的重構(gòu)和數(shù)次的迭代的重構(gòu)。
現(xiàn)在我基本上決定用python寫原型，先跑，然后如果效率上出了問題，profile一下，找問題的地方，用psyco編一下，如果還不行，就直接寫C的擴展或者用jtype在java里面做好，python里面調(diào)用。個人感覺python比較合適我的思路，也許是因為我不是一個合格的SA，我只是一個程序員
多process的情況我也推翻了我原來的設(shè)計，盡量減少process之間的狀態(tài)共享，把程序都往單進程順序執(zhí)行上堆，直到我決定寫erlang的哪一天，呵呵
對于general purpose的框架來說，開發(fā)者一定是對這個領(lǐng)域很有經(jīng)驗的，所以可以抽象出一套比較好的邏輯框架，然后實現(xiàn)成各種接口，工廠，封裝，分層來保證靈活性，這個在python的twisted庫里面也是一樣的，虧他們居然用python半調(diào)子的面向?qū)ο蟾阏诉@么多東西出來。不過還好他們暴露出來的接口并不復雜，也就是一些回調(diào)和事件
不過在面臨專業(yè)領(lǐng)域的問題的時候，這種一來就高層建模的方式或許就有點行不通了，因為沒有人敢站起來拍胸膛說，這個項目所有需求我都了解了。而且大部分需求都在根據(jù)時間變化。所以導致開始建模的那些封裝到后面可能會變成完全不適用或者需要大量適配才能使用的東西
另外這段時間突然感覺各種語言蜂擁而起，而起很多都有自己的明確的主題，
比如erlang對并發(fā)的處理簡直就是一絕，
scala在jvm上的表現(xiàn)，整合的非常好，
還有我最喜歡的跨平臺pascal：lazarus今天也剛剛出了0.9.26版本完美支持mac平臺的新界面框架（好像叫carbon把），跨平臺的native程序開發(fā)估計也只有他能做了，
ruby新版的效率居然比python2.6還要高，好吧我承認，我沒有選ruby和jruby是因為不太喜歡他的語法- -，感覺啰嗦
groove是瞄準ruby去的，不過現(xiàn)在還差一截
最近看到有句話很喜歡：程序設(shè)計有兩種思路，一種是設(shè)計的很簡單以至于明顯沒有缺陷，一種是設(shè)計的很復雜以至于沒有明顯的缺陷
以上是這段時間的一些感受，水平很有限，拉拉雜雜一堆，行家眼里看來肯定是漏洞百出，說出來讓大家笑話了。歡迎拍磚
這段時間我一直在思考各種設(shè)計上面的問題，原來一直寫delphi和一些其他腳本語言。對java一直沒有碰，這段時間看的比較多，也寫了一些小的程序，過程不說，1個月下來感覺只有四個字：不堪重負 ToT，可能你們還記得前段時間我抱怨了一下java的類庫之間的復雜關(guān)系，讓我完全沒有任何的線索
隨即切換到python重新實現(xiàn)一些功能，也許是有了前面的經(jīng)驗，寫的輕松了很多，雖然這段時間我連很多python的基本用法都沒學完，比如那個lambda函數(shù)，新奇呀~
用twisted寫了一個server，10多行代碼，java那邊用mina還沒有實現(xiàn)邏輯就已經(jīng)4、5個java文件了，當然大部分代碼ide都幫忙寫了，不過java類庫之間的邏輯關(guān)系復雜程度可見一斑。
以我對這兩個語言的了解程度，還不足以對他們評頭論足，我發(fā)現(xiàn)他們在設(shè)計思路上有一些很有意思的地方，寫下來，大家看看。
delphi聞名是他的RAD套路，還有就是所謂的“優(yōu)雅”，因為寫出來的代碼規(guī)范而且可讀性強，不過很遺憾，delphi的rad貌似也沒有太大的進展了，至于用“begin end”來保持的優(yōu)雅，我持保留意見，呵呵。期待后續(xù)的版本能繼續(xù)發(fā)揚RAD，這次支持泛型和unicode就很不錯，要是再多些語法糖就好了，恩啊恩啊。delphi仍然是我windows平臺下開發(fā)的不二選擇。
python的設(shè)計思路很像delphi，走的是rad的套路，用python寫東西的時候，明顯感覺到是拋開了詳細設(shè)計的，就是一切都面向?qū)崿F(xiàn)功能，他的語言設(shè)計是鼓勵你這么做的。python強調(diào)了函數(shù)和模塊，他的面向?qū)ο笪业椒炊X得有點半調(diào)子，不過無所謂，這些是意識形態(tài)上的東西，能解決問題就好。
而用java的時候，我還沒開始寫一行邏輯代碼，已經(jīng)被迫實現(xiàn)了4、5個接口了，而且我在沒有寫完之前，還不能把他們整合起來，也不知道是對是錯。心里懸著，感覺不舒服。
很有意思的是，python的思路很接近我最初寫程序的時候，什么都不知道，只要把東西做出來就好的那種思路，所謂初級程序員的做法。不過這個不是全部，python的開發(fā)過程非常強調(diào)自省，也就是重構(gòu)，說白了就是重新寫。而且目前的開發(fā)中更加注重的是在各種測試的情況下進行重構(gòu)，也就是是有保障的重構(gòu)，而非程序員一時性起，寫了也不知道對不對。我個人覺得這個是符合邏輯的，在沒有了解一個東西的時候做再多的設(shè)計都是空的，我原來也嘗試過，也看到過開發(fā)中到最后，完全和最初的設(shè)計沒有關(guān)系。失去控制，全靠程序員自己努力，更要命的是，牛B的SA還不愿意承認……
python可以做到這一點，是因為python代碼很精簡，程序員寫作的時間很短，就算是重構(gòu)這個時間消耗也比其他語言低很多，我覺得這是python做的最好的地方，他給這種“初級程序員”的開發(fā)模式提供了一個升級的可能
這段時間也很關(guān)心各種語言的效率，不可否認，java的jvm虛擬機是一個很厲害的東西，java的執(zhí)行效率在高端機器上和C在一個水平，一個可以自動管理內(nèi)存的語言做到這個地步，實在讓人驚嘆。同時java的開發(fā)效率比C又高了不知道多少倍。所以在服務(wù)器端java可以說當之無愧的王者。
這次準備放棄java轉(zhuǎn)而用python的主要原因其實是考慮到開發(fā)效率和rad的需求。前段時間考慮的方案是用java寫框架和效率要求嚴格的地方，然后用jython實現(xiàn)邏輯和效率要求不高的地方，不過這個想法首先被jython的超級低效率擺了一道，這個低效非常明顯而且不是幾十倍的問題，
然后自己感覺java的各種代碼之間各種交互很多，設(shè)計上找不到rad的感覺，我也會設(shè)計很多接口，封裝，然后工廠，不知道是不是被引誘了呵呵。
然后就是這次做的東西有探索的性質(zhì)在里面，所以我自己是沒有太多經(jīng)驗的，整個開發(fā)過程我預算了1次完全的重構(gòu)和數(shù)次的迭代的重構(gòu)。
現(xiàn)在我基本上決定用python寫原型，先跑，然后如果效率上出了問題，profile一下，找問題的地方，用psyco編一下，如果還不行，就直接寫C的擴展或者用jtype在java里面做好，python里面調(diào)用。個人感覺python比較合適我的思路，也許是因為我不是一個合格的SA，我只是一個程序員
多process的情況我也推翻了我原來的設(shè)計，盡量減少process之間的狀態(tài)共享，把程序都往單進程順序執(zhí)行上堆，直到我決定寫erlang的哪一天，呵呵
對于general purpose的框架來說，開發(fā)者一定是對這個領(lǐng)域很有經(jīng)驗的，所以可以抽象出一套比較好的邏輯框架，然后實現(xiàn)成各種接口，工廠，封裝，分層來保證靈活性，這個在python的twisted庫里面也是一樣的，虧他們居然用python半調(diào)子的面向?qū)ο蟾阏诉@么多東西出來。不過還好他們暴露出來的接口并不復雜，也就是一些回調(diào)和事件
不過在面臨專業(yè)領(lǐng)域的問題的時候，這種一來就高層建模的方式或許就有點行不通了，因為沒有人敢站起來拍胸膛說，這個項目所有需求我都了解了。而且大部分需求都在根據(jù)時間變化。所以導致開始建模的那些封裝到后面可能會變成完全不適用或者需要大量適配才能使用的東西
另外這段時間突然感覺各種語言蜂擁而起，而起很多都有自己的明確的主題，
比如erlang對并發(fā)的處理簡直就是一絕，
scala在jvm上的表現(xiàn)，整合的非常好，
還有我最喜歡的跨平臺pascal：lazarus今天也剛剛出了0.9.26版本完美支持mac平臺的新界面框架（好像叫carbon把），跨平臺的native程序開發(fā)估計也只有他能做了，
ruby新版的效率居然比python2.6還要高，好吧我承認，我沒有選ruby和jruby是因為不太喜歡他的語法- -，感覺啰嗦
groove是瞄準ruby去的，不過現(xiàn)在還差一截
最近看到有句話很喜歡：程序設(shè)計有兩種思路，一種是設(shè)計的很簡單以至于明顯沒有缺陷，一種是設(shè)計的很復雜以至于沒有明顯的缺陷
以上是這段時間的一些感受，水平很有限，拉拉雜雜一堆，行家眼里看來肯定是漏洞百出，說出來讓大家笑話了。歡迎拍磚
共1 條記錄, 每頁顯示 10 條, 頁簽:
[1]