該學那些程式語言2008版

這主題向來是討論區上常被提出的問題，一言以蔽之，選擇最好的或最受歡迎的…

選擇最受歡迎的，站在你自己的角度來看，它可以提高你在市場上的身價，讓你找的到工作，可以填飽肚子。而站在別人的角度來講，你開發出來的系統容易讓別人接手，開發系統時可用的支援較多，市場的接受度較高，不用重新教育使用者。

選 擇最好的，一方面是可以接觸新思維，提供不同的視野。另一方面，則是期望有一天，最好的可以變成最受歡迎的。而早期投入者，多少可以收到 "傳教士" 般的尊崇待遇。還記得以前 XML 剛出來時，大力推廣 XML 的勞虎，在網路上廣泛傳送其免費電子書《無廢話 XML》，而今多少學習 XML 的網民，還是感念其恩德啊!

那麼，以下便是我的選擇。我會說明其主要應用，及個人對它的觀感。

最受歡迎：

C/C ++：這應該是正統資訊工程科系都必修的語言吧，它的應用不但能讓你直指核心(C)，也能讓你站在物件的具像高度(C++)，思考系統的構成。像是系統程 式、原生應用程式、軔體、Driver 等，皆是 C/C++ 應用所及之處。尤其台灣電子產業相對發達，在各種掌上型、智慧型裝置不斷推陳出新的今天，對C/C++的人力資源有高度需求。不過這個語言(尤其 C++)因為承載太多歷史包袱，各種實作變體太大，開發時常需用很多 tricks，在應用時需要付出較多心力，在程式語言本身及各種環境歧異的細節上!

Java：如果你唸資工 系，但學校 C/C++ 課程非必修，那麼至少 Java 是必修課程吧! Java 除了較少用在系統程式外，其他領域幾乎都占有一席之地。由於 Java 具有良好的物件導向基礎，當代許多企業應用皆採 Java Solution，尤其是在 SOA/ESB/EAI 等領域。採用 Java Solution 的好處是自由度高，但缺點就是很多事情沒有標準作法，或支援標準作法的解決方案太多，往往要花費不少時間在選擇如何架構系統上。

C# & VB.NET：這能讓你賺錢! 可以讓你快速的寫出漂漂亮亮的應用程式! 能讓你與微軟的企業系統做 完美的結合。像是 BI(OLAP、Reporting、Data Mining)那一塊，是 Java 在應用上比較需要費心的。而 .NET 相對於 Java 較緊緻的技術堆疊，能讓開發者較專注於應用程式的開發上。缺點是，離開了微軟平台的世界，就幾無用武之地。

PHP/Ruby：如果你想 run 自己的 business，或想建立一個像黑米、放P、挖女孩那樣的網站，相信我，這是一個很好的選擇。不過由於目前這兩個語言主要用途只在 Web 開發上，因此特別要注意典範的轉移，或是其原來專精的部分不再具有優勢。

就典範轉移：我的意思是，PHP/Ruby 除了在 Web 開發上已有成功的 killer apps 之外，其實它們能做的事，其他語言或平台也都能做，除非它們能在別的應用領域一樣成功，否則對其未來發展仍是一項危機。而就 "其原來專精的部分不再具有優勢"，這並非不可能發生，請見以下的 ECMAScript 說明。但好消息是，至少在 2007 年，這兩個語言的排名在 TIOBE 上的排名都是往上升的。

最好的：

Python： 真正的跨平台，除了跨 Windows, Linux 這類原生作業平台外，它也有 Java 及 .NET 虛擬機器的移植版本。在 Java 與 .NET 競相誇炫平台能力之際，Python 仍能堅守語言本身的原味之美，是令人讚賞的。也因如此，Python 的應用領域眾多，從 Web、文字及檔案處理、科學到研究等，幾乎無所不包。事實上，很多研究平台內定的 scripting language 就是 python，像是用於統計的 SPSS、用於資料探勘的 Clementine 等。

D：被視為是 "C++ done right!" 的一個程式語言，支援了許多 C++/Java/C# 共有的特徵(OOP)，但卻也有些特徵是其他語言所欠缺(或尚在研議中)像 Out function parameters,Nested functions,Function literals,Closures,Resizeable arrays...。在現今 VM 當道的年代，D 仍編譯為 native executable，可見其定位，是比較接近 C/C++ 的。也就是適合拿來撰寫系統程式、原生應用程式、伺服器程式，以及網路應用程式等。不過，對於 D 被廣泛接受仍有重大疑慮，因直至目前為止還不知有任何較大型的專案採用 D 語言開發。相較於 Ruby 也沒有像 RoR 那樣的殺手級應用出現。

最受歡迎+最好的：

ECMAScript/JavaScript/ActionScript：JavaScript 與 ActionScript 都朝 ECMAScript 標準靠攏。本來 JavaScript 是被某些人唾棄的一無是處，以為它只會在瀏覽器上作作表面功夫的語言，但一朝 Ajax 的應用得到普遍的喜愛，JavaScript 的行情也就跟著水漲船高。但如果只是這樣，對於 ECMAScipt 最新標準的推廣倒不見得有多大助益。特別是後來 ActionScript 也遵循 ECMAScript 標準，而且號稱 ActionScript 3.0 是非常遵循，這就好玩了。因為 ActionScript 是應用在 Flex/Flash player 中，而瀏覽器中主要執行的指令語言是 JavaScript， 而這兩者都是當代 Thin Client/RIA 的主流，因此我們可以說 ECMAScript Family 幾乎已成為 Universal Client Lauguage。

再者，認為 JavaScript 只會在瀏覽器上作作表面功夫其實並非事實。早期 Netscape Enterprise Server 及 BroadVision One-to-One Server，在 JSP 尚未出現前，伺服器上執行的指令語言就是 JavaScript。而前文提到現在是 VM 當道的年代，現在 ActionScript 的 engine 也已成為一個 VM，叫 AVM，且已貢獻給 Mozilla，成立 Tamarin 專案，將來若用於 Firefox 中，網頁內的 JavaScript 跑起來說不定會跟飛的一樣。

若是真有人拿 AVM 來寫伺服器，說不定會光復 JavaScript 在 Server 端的失土哦 (好吧! 天方夜譚)! 說真的，AVM Server 版若成(例如成為 Apache 的一個 module)，要威脅 Java 或 .NET 既有地位是比較困難，因為這兩個平台既有應用多、進化動力也強；但對其他 Server 端的 Scripting Language 絕對是個威脅。想想看，若你能在 Server 端及 Client 端同時使用 ECMAScript，那使用 Ruby 或 PHP 的誘因是否會漸漸變弱呢！而 Ruby 會紅，並不是語言本身之美所致，而是出了一個 Ruby on Rails Framework，而 framework 裡面的 concepts 是很容易 porting 到別的語言或平台中的。

其他：

看了以上個人挑選出來的清單，看啊看的，現在還是程序導向和物件導向語言的天下。難道沒有其他不一樣思考面向的東西嗎? 有的，而且我們也還滿常用，像是 SQL，或是各式 Markup Language 了(雖然不是程式語言)。還有那些用在工程、模擬、統計分析、人工智慧上的，你沒有那個環境或從事相關職業，是幾乎無從著手的語言，而這些當然就不算在推薦之內。

結語：

一項語言要被廣為接受，在過去，我一直以為大廠的支援是個必要因素，但 PHP(XOOPs, Nuke...) 及 Ruby(RoR) 這種透過 Community 及 Killer Application 來帶動風潮的成功案例，似乎也印證了 "世界是平的" 的論點，在這個網路世代，不只大企業，小企業及個人一樣有機會。Killer Apps 與 Success Stories，可能比大廠背書更有價值。

而對於你的選擇，我想，如果要做個尋常的程式開發人員，我會建議你 ECMAScript Family 一定要學，那 Java 或 .NET 再選一種。若你是個不尋常 (開發特殊應用的軟體) 的程式設計師，通常也就沒什麼好選了，因為應用的型式就決定了我們的選擇。

想起一段令人感傷的住事

記得在國小一年級時，班上有個年約 16 歲的同學。這麼大的年紀才唸小學，在以前經濟尚不發達的年代並不算特別。然而，他倒不是因經濟問題才延遲就學，而是因為學習上的理解力不佳。他可能可以勉強知道 1 + 1 = 2，但問他 3 + 4 等於多少，就已經超越他的能力了。事實上，他已唸了好幾次小學一年級了。

由於年紀的及學習能力的因素，他常成為學校同學的笑柄。年代久遠，我已不記得我是要別的同學別取笑他，還是跟著別的同學一起欺負他。這樣從開學後一直過了一兩個月，突然有一個星期一他沒到學校。我想起，上個星期六放學時我似乎是跟他一起走路回家的，有一種不好的念頭出現在我的腦子中。

放學後，我到了那個我之前常去的小公園，我知道他家就在附近。我想問問他家人他去哪裡了，怎麼沒上學。還沒到他家，卻看到，他已經掛在相思樹上，上吊死了…

我有另一個同學，他的哥哥因為高燒而智力受損，也就是一般認定的白痴。那種言語不清，看起來髒髒的，好像一段日子沒洗澡的樣子，大家都認得出來這樣的人。從他智力受損後，別人當然也會取笑他，大人小孩都欺負他，但他似乎不能區別那是不是欺負，他一直過得很快樂，真的是笑罵由人，從小到現在，快 40 歲了!

這段年代久遠的記憶，多年來不曾在出現在我的腦海中。我甚至可能是選擇去故意遺忘它--我沒再去過那個鄉下的小公園。在那之後，的成長過程中，我也的確一直沒想起這事。讓我想起這事的原因，可能是因為某些情境觸發了我。我偶爾會聽到有人在教育小朋友時，說出：「你怎麼可以笨成這樣… 你為什麼不去死一死好了…」。

這段回憶提醒我，惡語傷人六月寒。即使是身邊的家人、朋友，也可能因一句不小心的剌激而走上絕路。而萬一傷人的話語成真，背負著的，可是一輩子的歉咎與不捨。

iGoogle 與 Google Reader 裡的 RSS 訂閱

之前看到有人在「訐譙(ㄐ｜ㄝˊ ㄑ｜ㄠˊ)」Google 把預設的 RSS 訂閱導到 iGoogle 去，有人說是版本有差，有人說是已改了回來。我的 firefox 則是到現在還是這個樣：只會導到 iGoogle 去。

雖然我也是 iGoogle 的愛用者，但是想放到 Google Reader 裡去細細品嚐的資訊，真的跟想放在 iGoogle 上的資訊不太一樣。強迫用戶只能接受 Google 的指定，未必合理。不過若是做個瀨尿牛丸，真正的把 iGoogle 跟 Google Reader 訂閱做進一步整合，也是可能的解法。

我的想法是，既然放在 iGoogle 上的 google bookmark 會在 google bookmark manager 內被自動置入 homepage folder，那何不如法泡製，將加入 iGoogle 個人化首頁的 feed，也自動放在 Google Reader 內的 homepage folder 中。如果用戶已在 iGoogle 內加入分頁標籤，那更可用頁籤名稱作為 Google Reader 內的 folder 名稱。

另外，在 iGoogle 內閱讀 RSS 文章時，如果也可以選擇將文章開啟在 Google Reader 中，那種感覺也是挺不賴的!

「留著」哲學

以前對於留在身邊的東西，總有一種去蕪存菁的怪癖。 我不喜歡沒有用的東西，我不喜歡用不到的東西。 凡是東西用不到了，總是想要將它移除，丟掉。 留著沒有用的東西，就是浪費空間。 而這年頭，會跟我們有所牽扯的東西，卻又不可勝數。 在網路上寫日誌、評論，會留下你在各地的思想點滴。 換了一家公司上班，就多了至少一份經歷，也至少多了一個銀行戶頭。 有些東西做了之後是無法拭去的，像是學歷，工作。 有些東西卻是可以加以刪除，像是那些因為換了工作後，久久未曾再動用的戶頭。 前一陣子心血來潮，想要將那些久未動用的戶頭清一清。 但其實對一個上班族而言，這麼簡單的動作卻未必容易。 大抵上，銀行會跟你說：抱歉哦！要到原開戶行才可以結清。 你還記得開戶行在哪嗎？ 就算記得，你確定結清所得的款項會大於花了時間跟金錢跑到那兒的代價嗎？ 更重要的是，說不定下次因為某些因素，可能還要重新啟用那銀行的戶頭呢！ 所以我想：留著吧，也許以後會用得著。 當下，我只要先把那些零頭，轉到別的戶頭去就行了。 等到有一天我退休了，在畢業之前那段美麗的、短暫的、悠閒的時光中， 再來結清吧。

奇妙有趣的設計塔圖

「設計塔圖」是一種神奇的「創造性思考技法」，依照「設計塔圖」思考技巧所建構出來的思想產物，將同時具有連續性與關連性。如果將任一處的連接線切斷的話，那麼整個系統就將遭到破壞。「設計塔圖」對於聯想力及系統化思考，極為有益。

我們以「何謂備忘錄」這個主題，來說明「設計塔圖」的應用方式。

備忘錄具有聯想、資訊、留言三種功能，因此就把這些功能當成三角形的頂點記下，到此已完成基本骨架。

然而，為了使備忘錄促進聯想，就必須把所想到的事項立刻記下來。也就是說，書寫工具必須和備忘用紙同時攜帶在身上。於是在「聯想」之下，就立刻出現「攜帶」這個字眼。

其次，必須要能妥善的「保存」備忘錄，才能使它的「資訊」架值得以彰顯，但若要使資訊更有價值，更有助於聯想，就得好好「整理」備忘內容。

就另一項功能「留言」而言，它與其他兩項功能最大的差異在，它必須不斷的意識到「他人」的存在。這不是為自己而作的備忘錄，而是為他人而做的。在備忘錄的內容被接收之後，這份備忘錄也就可以「消滅」了。

而就交付者的立場來說，要儘量網羅5W2H的內容。如此一來，就算備忘錄離開自己的手上，內容也不會遭到誤解。

另一方面，就接收留言者的立場來說，也可妥善應用備忘錄，將其內容「內在化」，加以了解及吸收，以提昇自己的構想。

與備忘錄有關的「設計塔圖」完成了。普通的發想法通常只是針對特定的主題作各種聯想，因此常呈片段而零亂的狀況。 而「設計塔圖」，卻能將這些零亂的聯想系統化。

有了這一張圖，不但可顯示要點，亦能將之擴大成文章，一魚多吃。但在過程中，卻好像只是進行了一場排列關鍵字的遊戲而已。

※ 給採用 RSS 閱讀軟體的讀者：有些 RSS 閱讀軟體並不能正常顯示內嵌物件，請移駕本文原始網頁，才能看到 slide show 講解的「設計塔圖」。謝謝!!

管理寓言：男人愛當顧問

在彭懷真所著的《時間好經營》中，讀到這樣一個管理寓言：

甲君養了隻愛叫春的公貓，每晚嚎叫吵得鄰人無法入睡。在群情激憤下，甲君不得已將公貓送去獸醫處使其不能貓道。幾天過後鄰人仍見那公貓夜夜外出 “辦事”。鄰人不解而問之，甲君便說：牠現在到處去給別人當顧問。

自從聽到這個比喻之後，我就對顧問這個身份感到過敏 (偏偏我的 title 便是顧問)。從上面的故事來看，似乎在諷刺顧問是只剩一張嘴，不能幹正事的人。不過，我在大陸的網站上看到另一個版本，而有不同的解釋：

社區裏，有只公貓，花心，夜夜出去，找母貓鬼混。 後招各家公貓投訴，女主人一狠心，把這只花心貓喀嚓了。 花心貓被喀嚓了後，仍然夜夜出去，回來後竟然更得意。女主人大奇。 花心貓得意地說：“您把我喀嚓之後，我是不行啦，那些公貓也安靜了幾天，不過他們現在都高價請我去做consultant。”

該站作者解說如下：

• 各家公貓投訴，說明這只貓很有魅力和能力。暗喻在公司裏面能力非常強的sales，但是這個sales很自狂，未處理好同事之間的利益關係，遭同事到老闆那裏投訴。
• 女主人把這只貓喀嚓了。暗喻老闆是昏君，賢能招妒無善終。
• 公貓後來被大家聘consultant.暗喻公貓的實戰能力還是大家公認的，做consultant是無奈之舉。

不過我覺得這樣的解釋也有些牽強。有實力的人，何以只能無奈的做consultant。真正有實力的話，不但能在旁指導，甚且可以自己入場打場好球。有道是心寬天地寬，何必自嘲受昏君閹割啊！

台北市圖書館的貼心服務

大家都知道圖書館可以借書，但若談到預約借書的功能，可能就比較少人知道或使用了。而把預約借書功能發揮到極致的，我想台北市立圖書館算是其中的佼佼者。 預約書籍很簡單，首先，你要辦妥借書證。然後登入台北市立圖書館網站 (密 碼預設是你的生日)，搜尋感興趣的書籍。找到書籍後，便可按下畫面上的預約連結進行預約。也許有些書籍只在其他館藏中才找的到，沒關係，台北市圖書館讓你 可以跨館預借，並讓你自由指定所要取書的分館。大概一段時間後 (約一個禮拜)，圖書館會幫你把書備妥，送到指定的分館，並發出 email 跟電話通知你在三天內取書--完全不收分文。email 格式長相像下面這樣：

MR. XXX 臺端所預約之以下圖書已到館,請至圖書館辦理借閱, 收到本館通知逾3日未取則（送回原典藏館）上架供其他讀者 閱, 謝謝 ! 請注意︰此郵件是系統自動傳送，請勿直接回覆此郵件，若 需要請直接與(取書館)聯絡。 1 XXXXX/ AAAA ; BBB, CCC譯 AAAA call number:000.0 0000 copy:1 2 YYYY: YYYYYYY/ DDDD. EEEEE著 ; FFF譯 DDDD call number:111.1 1111 copy:1

如果你想，甚至可以要求圖書館將書透過貨運送到你家，而你只要出資支付貨運費即可。 Anyway，這是一項相當體貼便民的服務。不過我也擔心，若是使用這服務的人多了起來，是不是會造成圖書館的作業成本太高…考慮到這點，還是把借回來的書努力的 K 完再說吧。 ※ 2007/9/1 另一點通知：台北市圖書館用悠遊卡也可以借書了喔! 詳情見此。