至於你想用什麼程式語言來寫，毫無限制，這一點我完全沒有要求。關鍵是你得完成這個程式，並且使之能順利工作。
任何一個大專案在開發過程中，需求說明總是會有所變化。我可以保證不會胡亂提一些會混淆你工作方向的要求。例如，你能新增一個擁有Photoshop所有功能的影象編輯器，甚至是增強版的嗎？你能實現韓語和波蘭語之間的自動轉換嗎？如果網路尚在載入中，介面上能不能出來一頭可以操縱著到處轉悠的3D立體模糊狀的羊駝？這些要求我統統不會提。但是我可以預見以下這些情況的發生：
- 需要處理的資料比你預期的大5倍。
- 因為還需要在一些基於ARM的自定義硬體上執行，所以必須得是可移植的。
- 由於英特爾釋出了20核心晶片，所以程式碼需要擴充套件到相應級別的處理能力水平。
但是遺憾的是，我發現谷歌不想買我的部落格了，所以我只能銷掉這個一億美元的報價。唉……真心無奈。
但是，假設這個報價是真的呢？你敢就此任務為你喜歡的程式語言賭上一億美元嗎？這將如何影響你對程式語言的判斷標準呢？下面是我的觀點：
類庫的重要性遠遠超過核心程式語言的功能特徵。
儘管Cayenne有許多相關的型別（很酷），但是它有建立Flash檔案的功能和本地化外觀的互動介面嗎？D語言有富文字的轉化類庫嗎？如何通過fpt從Mercury中獲取檔案？你真的想自己純手工編寫一個SVG解碼器嗎？
成熟和可靠的工具，甚至比類庫更重要。
有沒有人曾用Dolphin Smalltalk，或Chicken Scheme，或Wallaby Haskell等等試圖解決過某個類似的問題？有沒有人曾用某種程式語言試著解決此規模下的所有問題？你是否知道編譯器碰到大型程式其速度不會成倍降低？
分析器又能否處理這些大型程式？你知道怎麼追查一個小小的變化是如何影響函式編寫，從而導致記憶體出現離奇峰值的嗎？
有沒有核心開發人員使用Windows版本工具，或者這工具被認為是二流平臺？某個大型專案中的本地編譯能否會嚴重影響大部分程式碼而導致全域性性速度減慢（例如，90年代中期將Erlang轉換為C語言就會發生這種情況）？
你的決定比你自己想象的更為依賴語言實施者。
一些基礎類教科書上面的問題和例項教程，我們執行的時候總是特別美好。但是漸漸地，你會發現自己非常依賴於編譯器，或者在系統執行時，會產生一些奇怪的情況，雖然這對於該程式語言建立的問題域毫無關係，但是會大大影響你下一個行為目標。
假設你有一個程式，可以操作一個大型的浮點值集合——浮點數量高達數以百計的兆位元組。然而有一天，你的物件羊駝程式OCaml記憶體溢位，死掉了。當然你是很聰明的，知道大多數時間應該封裝好程式中的浮點數量，等到需要的時候再取出來用。但是浮點陣列卻大多是不封裝的，所以你用在了大型資料結構中。但是這樣做記憶體依然不足。問題就在於“float”在羊駝程式中意味著“double”。C語言允許我們快速地從64位double型別切換為32位float型別，立馬能節省成百上千兆空間。但是不幸的是，羊駝程式OCaml的實施者從未考慮過這件事，所以你不得不自己去使用編譯器來做這個切換。ps，在這裡我不是說在指責OCaml，此浮點型別問題在很多程式語言中都有。
與此類似，但同樣難以解決的事情還有很多，例如，如果你發現在某一個資料集合中，垃圾收集器跨越了從“只有關注的時候才可見”到“幾秒鐘就能產生bug報告”的界限。話說，垃圾收集器已經經過了我們的精心優化，並且衍生多代，但是到現在最老的一代依然需要等待清理，等待它檢查過上G位元組的複雜結構並且做好備份之後，而與此同時，你就只能眼巴巴地等著。你能解決這個問題嗎？當然紙上談兵的那種就不要丟人現眼了。
這種有形的物質獎勵法，然而，實實在在地影響了我的行為方式。因為有這麼個一億美元的胡蘿蔔掛在我的面前，我非常願意獨自去研究各種涉及實際的問題。純粹的學術研究專案，其實是非常可笑的。我會用C語言寫好應用程式的關鍵部分，這樣一來，最後結果就又能回到我的掌控中，也就不至於之後突然發現語言系統設計者有關於標註、排列和垃圾收集器的選擇有悖於我的最終目標。 Python和Erlang在大型的商業專案中廣受歡迎，雖然它們也有各自不同的長處和短處，但是如果我需要支援一些非UNIX的嵌入式硬體，那麼恐怕這兩者都不足以勝任。
看到這裡你有何感想呢？話說如果，假設，真的有這麼多錢——一億美元——讓你改變完成任務的方法，轉而用一種可靠又快速的標準方式，何樂而不為呢？
來自：PHP100
相關閱讀
評論(1)