Subject: 經驗交流一 : 如何增進程式寫作能力(加強版) Date: Sun, 26 Mar 2000 12:31:32 +0800 From: lgsing.bbs@cis.nctu.edu.tw To: k1228341@ms15.hinet.net 發信人: ax@phoenix (pa), 信區: programming 標 題: 經驗交流一 : 如何增進程式寫作能力(加強版) 發信站: 交大資工鳳凰城資訊站 (Jan 13 14:16:00 1994) 轉信站: phoenix dragon cis_nctu topic: 如何增進程式寫作能力 發信人: lc@cis_nctu (藍天之外有白雲) ------------------------------------ 老師說我寫的程式很不錯但仍有改進的地方. 我學程式的地方是每本書 東抄抄西學學, 看到好的就拿來自己用. 沒有一個系統. 寫的程式多半 是自己覺的有效率罷了! 我是學大氣的, 常常需要處理大量的資料, 請 問, 要增進程式寫作能力, 有什麼書可以看嗎? 發信人: jie@cse_ttit (可教之孺子) --------------------------------- TO lc: 建議你修資料結構(Data Structure),或到市面上找一些Data structure 的書來看,相信你會大有進步的..... 發信人: Harimau@Maxwell (小虎) ------------------------------ 猶記得一位電腦大師在他某書的序言中說 : " 學習寫好的程式的方法, 往往是要 抄取他人的傑作, 再加以本身對該程式不斷的改善, 直至該程式逐漸變成自己的為止。" 我覺得這話蠻有道理的, 你認為呢? 發信人: lp@phoenix (tony) ------------------------- 去找個要你做苦工的程式工作就可以大大增進功力, 我以前有個經驗 , 當你對一種語言的程式寫到上萬行時, 以後這個語言就像是中文一樣自然的 用出來. 資料結構與演算法可以這樣做: 先寫一個保證正確的"爛程式", 再用這個"爛程式"當成你以後精鍊的 對照版本, 這個爛程式裡, 除了正確性之外, 你什麼都不用管, 只要再以後的 那個程式裡注意就可以了. 程式是個苦海, 永遠游不完, 江山代有才人出, 我老了 發信人: zheng@cis_nctu (zheng) ------------------------------ Dear User : 想學好語言重點不是在於指令,而是在於語言的精神...... C++ 的精神在那? Quick Basic 的精神在那 ? 這是先必須思考的問題 再來要確立自己的寫作風格 , 是先經美而後大成 , 抑或是先大成而後精美,易 影響寫作的方式及方向 第三 多找自己有興趣的題目作練習 , 如 簡單的PE2 , GAme 均是很好的練習對象 第四 找同伴互相研究 第五 多看書,多問別人, 多練習 ........ 小小心得, 不免貽笑大方 ....... 發信人: PaladinMu@cis_nctu (Paladin) ------------------------------------ ==>[Author]: zheng@cis_nctu (zheng) on board 'programming' > 想學好語言重點不是在於指令,而是在於語言的精神...... > C++ 的精神在那? Quick Basic 的精神在那 ? 這是先必須思考的問題 > 再來要確立自己的寫作風格 , 是先經美而後大成 , 抑或是先大成而後精美,易 > 影響寫作的方式及方向 > 第三 多找自己有興趣的題目作練習 , 如 簡單的PE2 , GAme 均是很好的練習對 > 第四 找同伴互相研究 > 第五 多看書,多問別人, 多練習 ........ 寫得好。 :) 在我的觀點中，先有概念，後有語言，語言是支持某個概念而 設計的。Pascal的概念是structured programming，發展到後來就產生了更 進一步的Modular 2. LISP2的概念是recursion & list processing, PROLOG 的觀念是邏輯... LISP程式可以寫得像C一樣，但是就等於不會LISP了. C呢？Hmmm... 老實說，覺得C是個沒有觀念的語言.... 關於您說的後面幾點，想補充一下：Robert W. Floyd 在他的Turing Lecture : Paradigm of Programming中說到了一個好觀念。Paradigm, "典範", 是借用孔恩 的說法。先舉個例子，我們控看到這樣的pattern : bool=do_something(); while not bool do begin .... .... bool=do_something(); end; 最早學生們通惇O在input一系列的資料時學到這個pattern, 比如說輸入0 時結束input, 這時do_something就是read函數，loop的條件判斷就是 input <> 0。但是以後學生會發現這個同樣的pattern在很多場合中看得到 。之所以要"找同伴互相研究", "多看書,多問別人, 多練習", ，並且 以前也有網友建議〞多看別人的程式〞，實際上都是為了學這些pattern， 或者更廣義的說，不只是有形的pattern, 而是觀念上的paradigm。 Programmer 依不同的領域，而有許多個典範，structured programming 是一個通用的典範，divide & conqure, dynamic programming, cocurrent programming是一些比較小的典範。 上面舉例的技巧就是更小的典範了。 但是不可否認的，這些典範已經被我們視為理所當然，成為programming 的基本依據。 遺憾的是，我們的計概課先教語言，語法，規定，然後教某個特定的 演算法，背下他... 學生們只能自己去摸索、體會典範的存在了. 發信人: william@cis_nctu (C++/ASM/Win Master) --------------------------------------------- ==>[Author]: PaladinMu@cis_nctu (Paladin) on board 'programming' > 寫得好。 :) 在我的觀點中，先有概念，後有語言，語言是支持某個概念而 > 設計的。Pascal的概念是structured programming，發展到後來就產生了更 > 進一步的Modular 2. LISP2的概念是recursion & list processing, PROLOG > 的觀念是邏輯... LISP程式可以寫得像C一樣，但是就等於不會LISP了. 所以: 學一個語言, 到最後一定要達到 "知其然" 的境界, 才算有所收穫. 否則, PLs 一個接著一個學, 和堆棧沒啥兩樣. > C呢？Hmmm... 老實說，覺得C是個沒有觀念的語言.... 和它的實用性的背景有關... ;-) 其實, "實用" "彈性" "程式師至上" 就是它的觀念... ;-) > 遺憾的是，我們的計概課先教語言，語法，規定，然後教某個特定的 > 演算法，背下他... 學生們只能自己去摸索、體會典範的存在了. 先教 paradigm , 有多少人會懂? 以台灣目前的情形看... 如果高中的計概能真正好 好的上的話, 或許在大一能做到這理想. 但現實... 想想: 一年前, 如果計概老師一 開始就教結構化, functional, logical, OO... 你的同學消化得了嗎? 如果先教 tool, 能讓人邊實習邊培養及觀摩良好的 paradigms, 較具體些. 遺憾的是: 目前的教育偏重 tools, 而 paradigm 只有靠自己有心去觀察與學習. 但有心人又有多少? 平時的程式作業, 我想只有少數人會像我這個傻子一樣, 寫 完了還會考慮: 能用另一種較精簡的指令來替代嗎? (練習語言的掌控) 能改成較好的流程嗎? (結構化方法論之述備矣... ) 時空效率已達到很好的地步了嗎? (資料結構及演算法的再考量) 整體結構夠自然嚴謹嗎? (軟體的整體架構, 庖丁解牛... ) 有沒有另一種切入的觀點或作法? (可能另有海闊天空... ) 有無符合軟體工程上的要求? (分析, 設計 coding debug 維護... ) 有無前人的經驗可供事後觀摩學習? (他山之石) ...... 如果平時的作業都沒有這些反思, 恐怕就沒有其他機會來思索訓練了, 恐怕就不會 有心在其他場合做這種自我要求. Paradigms, 許多前輩已為我們鋪路; 只看是否有有心人去搜尋或粹取. 發信人: littletsai@cis_nctu (Little Tsai (阿哲)) ------------------------------------------------ ==>[Author]: william@cis_nctu (C++/ASM/Win Master) on board 'programming' > 先教 paradigm , 有多少人會懂? 以台灣目前的情形看... 如果高中的計概能真正好 > 好的上的話, 或許在大一能做到這理想. 但現實... 想想: 一年前, 如果計概老師一 > 開始就教結構化, functional, logical, OO... 你的同學消化得了嗎? > 如果先教 tool, 能讓人邊實習邊培養及觀摩良好的 paradigms, 較具體些. > 遺憾的是: 目前的教育偏重 tools, 而 paradigm 只有靠自己有心去觀察與學習. > 但有心人又有多少? 平時的程式作業, 我想只有少數人會像我這個傻子一樣, 寫 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ 你當然不是傻子. > 完了還會考慮: > 能用另一種較精簡的指令來替代嗎? (練習語言的掌控) > 能改成較好的流程嗎? (結構化方法論之述備矣... ) > 時空效率已達到很好的地步了嗎? (資料結構及演算法的再考量) > 整體結構夠自然嚴謹嗎? (軟體的整體架構, 庖丁解牛... ) > 有沒有另一種切入的觀點或作法? (可能另有海闊天空... ) > 有無符合軟體工程上的要求? (分析, 設計 coding debug 維護... ) 看了你的 Post, 學長我頓時覺得汗顏, 雖然寫過的程式不少, 但是 如果是為了應付修課的話, 通常交了之後就很少再精鍊了. 平時的作業不可能所有的人都能自我要求, 有些人對 coding 比較沒有 天份(或者根本不喜歡), 只要能交出個稍微像樣的已經不錯了. 至於有 心要訓練自己者(比如 你,我,他...) 就自我充實並互相切磋, 不管其 他人怎麼作. 雖然不必要求別人, 但是別人有求時, 一定要互相幫忙. 因為往後的程 式會越來越大, 不可能獨力完成. 如果不幸的, Partner 的功力沒有自 己強, 往往累死的是自己, 所以若有機會提昇 Partner 的功力, 才是自 己的福氣. 以整體的角度來看, programmers 平均水準的提昇比一二個 天才會來得好一些, 正所謂的 "兼善天下". P.S. 我曾因為 Partners 不符自己的期望而鬱鬱, 後來才了解幫助他人 才對整體環境有益, 不知道你會不會步入我曾經有過的心情? 發信人: PaladinMu@cis_nctu (Paladin) ------------------------------------ ==>[Author]: william@cis_nctu (C++/ASM/Win Master) on board 'programming' > 先教 paradigm , 有多少人會懂? 以台灣目前的情形看... 如果高中的計概能真正好 > 好的上的話, 或許在大一能做到這理想. 但現實... 想想: 一年前, 如果計概老師一 > 開始就教結構化, functional, logical, OO... 你的同學消化得了嗎? 喔，其實我所謂的paradigm並不單指這些大題目，許多在programming的路上 我們曾碰到過的小技術，其實已經被我們天天在用，也是值得教的。比如 上次提到的那種loop（把一部分放在外面），或者該lecture中提到的 平行assignment: a'=f(a,b) b'=g(a,b) 程式必須寫成： for (i=1;i > 如果先教 tool, 能讓人邊實習邊培養及觀摩良好的 paradigms, 較具體些. > 遺憾的是: 目前的教育偏重 tools, 而 paradigm 只有靠自己有心去觀察與學習. > 但有心人又有多少? 平時的程式作業, 我想只有少數人會像我這個傻子一樣, 寫 > 完了還會考慮: 嗯，說得好... :) 其實這態度的影響是很大的。我親眼看到很成功的例子... 說真的，要了解結構化的好處, OOP的好處，其實都等得自己有經驗了， 吃過苦頭了，發現問題了，才體會得到。否則再好的觀念也淪為死規矩了... 依我們現在的情況... 哎，其實呀，這學期交的程式不多，但幾乎都是到 交程式的前一天晚上，十舍才開始騷動... 大家胡亂寫寫交出去， 或是胡亂改改交出去... :) 我想，這樣下去會很慘的... 但是這也難怪，我們其他的時間都有期他作業要趕... 唉, 雖然學長們都說我們的 課好，大三可以修比較多東西，但我還是怕負面效果也大，課太多，到頭來沒有 一樣學的透。.... :< 發信人: william@phoenix (william) --------------------------------- ==> PaladinMu@cis_nctu (Paladin) wrote: : 喔，其實我所謂的paradigm並不單指這些大題目，許多在programming的路上 : 我們曾碰到過的小技術，其實已經被我們天天在用，也是值得教的。 : 須用一個temp變數。這在我們是理所當然囉，我本來也覺得沒什麼好教的， : 可是這學期碰到一些從來沒寫過程式的學弟，才發現這對他們是很難的... : 當然還有一些更難的例子，某種流程，某種遞迴。 像這種例子, 我總認為: 1. 入門的書會提, 當然, 前提是: 那本入門的書夠好... 像我以前愛不釋手的 許慶芳的 BASIC 入門... 2. 看別人的例子 (不論是書上的或是同學寫的或是雜誌上的) , 發現自己不會、 不曾想過的招式, 就好好觀摩... 3. 自己在解題過程中, 慢慢發掘問題、克服問題... 嗯... 好像在搞「學習理論」... ;-) 當然, 有系統的教學是比較好的, 但要先有人將這些零碎的東東整理成一個系統才 行; 否則, 只有零零碎碎的吸收了... 至少就我所知, 還沒有一個較有系統的這種 技巧整理。 幾年前倚天雜誌初創刊時, 有舉辦「程式競賽」, 每期後面都有刊登第一名、第二 名或佳作等等數篇的完整原始程式, 這對學電腦沒多久的我來說, 等於是至寶, 常 常觀摩如何切題、解題、coding tricks... 可惜現在沒有登了。 : 一般教完語言後，接下來教演算法，但是在如何implement演算法上， : 並沒有給一個橋樑，留給個人練功了。然後我們會看這個人寫出來的 : code漂不漂亮，當作這個人寫程式的style。但是style其實是可以教的。 : 我們觀摩別人的程式，所觀摩的也是這個... 有幾本不錯的 programming styles 的書, 等考完後我整理過再 post 上來。 : 不過，無論如何，在這之前對語言本身的確是一定要有足夠的基礎.... : 最近在想，資訊營的學員沒有語言基礎，教起來實在是很困難了。 唉... 當初定位得太高了些... 殷鑑不遠, 慎之! 戒之! : 話題逐漸轉到對初學者的教育上了，原來本來是針對稍advanced的programmer : 如何增強功力....gees... :> ;-D ---------------------------------------------------------------------------- 感謝各位對本篇經驗交流的熱烈迴響 -- PA -- Pallas Athena -- - Wisdom, Art, Technique, Production and Defence - - Smile to Victoria .......... :)