程式設計師們為什麼需要研究程式設計藝術
對於工作在第一線的普通程式設計師而言，討論計算理論就像在槍林彈雨中談論硝的化學性質一樣：可能都沒錯，但對解決擺在面前的問題並無直接幫助。當我們要解決的舊應用程式系統web使用者介面的乙個新問題已經有了最後期限時，為什麼要浪費時間想像haskell（哈斯克爾）和 alan kay（阿蘭.凱）死鬥的結果呢？我們為什麼要關心我們是否正在使用乙個monad或異常返回乙個錯誤狀態？「orthogonal（正交）」到底是什麼意思呢？不要給我乙份研究報告，只要把能工作的**給我就行了。於是「明日復明日」。
*purpleendurer注：關於monad，可參考：
在許多專案經理看來，涉足計算理論的程式設計師們造成的危險甚至比浪費時間更大：他們採用的新方法對專案構成了威脅。這種態度並非全無道理。每乙個承諾會徹底改變軟體開發的新想法，在炒作消退，在程式設計師可用工具箱中找到適當位置之前，似乎都對業界產生相當的傷害。把這些理論加以轉換，試圖把每乙個問題都硬塞進新模式，不管這適合與否。正如演化論的乙個駭人聽聞的誤用為**提供了乙個理由。例如，物件導向的誤用，導致了在修飾名上的各種各樣的程式設計陋習（願上帝溫寬恕我的靈魂）。
程式設計的歷史，點綴著挫折和搖擺。我記得dijkstra「go to語句是有害的」的著名論斷，這個論斷讓許多的程式設計師為了避免使用goto而創造出了各種怪誕扭曲的**，即使其中有一些迫切需要的。對結構化程式設計和其他規則的盲目服從危害甚大，我在ansi小組委員會工作時，曾有人提出了反對意見「程式設計並非總是具有結構性」，我回答說：「我不贊成結構程式設計。」每個人臉上的無聲震動使我估計會立即被除名。如果我的朋友和導師肯.李斯特（ken lidster）沒有發言和解釋，我確實可能會落得這個下場。肯.李斯特說，我的意思是反對結構化程式設計原則的教條主**釋。他是對的，儘管當時我覺得他已經淡化了我的大膽斷言。
不過，對程式設計理論追求的我們確實讓我們有所改進。如果不是所有這些應用於改善軟體開發實踐中的智慧型，我們都會被束縛在把機器指令打在紙帶上或在windows的visual basic中畫窗體。「必須有乙個更好的辦法！」謝天謝地，總有人把這句話掛在嘴上。
a little learning is a dangerous thing;（一知半解，為害不淺；）drink deep, or taste not the pierian spring. （知識淵遠，學無止境。）
專業程式設計師應該深刻體會。通過培養對本行業廣泛而深刻的認識，積累歷史知識，同時密切關注最新發展，他或她智慧型將會得到增長，去偽存真，讓每個工具物盡其用。（完）
程式設計師程式設計藝術總結
第一章 左旋轉字串 第二章 字串是否包含及匹配 查詢 轉換 拷貝問題 第三章 尋找最小的k個數 第三章續 top k演算法問題的實現 第三章再續 快速選擇select演算法的深入分析與實現 第三章三續 求陣列中給定下標區間內的第k小 大 元素 第四章 現場編寫類似strstr strcpy strp...
程式設計師程式設計藝術 回文判斷
鳴謝 感謝 july，您的部落格給予我很大的幫助，增強了我學習的動力。希望分享的力量永傳！本文問題源於 july的文章，修正了 july關於回文 的bug，現將本人 發布如下 如發現有問題，還希望不吝賜教。謝謝。include include using namespace std int max ...
程式設計師為什麼跳槽
程式設計師頻繁跳槽似乎成了乙個不可避免的現象。很多 請來所謂的職業分析人士，人力資源管理者座談，分析 看了看，多數屬於小兒科，很少有真正從乙個程式設計師的角度和眼光去看問題的。我認為，乙個程式設計師跳槽根本的原因，主要是公司團隊問題，其次是公司企業文化問題。很多人只看到了薪金問題這個表象，事實是，薪...