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