程序人生之雜扯篇

　　確實，做爲已擼了快10年代碼的「老」碼農，按一些人的觀點及理念，應多談多扯一些高級點的東西，譬如架構譬如項目管理什麼的——我也想，只是限於（目前的）我的能力及眼界，自覺確實還遠未入流說這些。
　　因此很明顯，我應「接地氣」地儘可能實事求是些，扯一些（本身）在編程經歷中的心得，和反思吧。
　　本文將圍繞程序設計語言這一爭議話題展開泛扯。很明顯，扯及的這些語言或多或少我都學過寫過用過，或曾經用過，即使只是拿來寫過很小的程序等。

　　就從 Delphi 開始扯吧，也許它是個人程序初戀。
　　彷佛如今知道甚至聽過 Delphi 的程序員已相對而言不是不少了，在很多人眼裏，這是個基本上會慢慢消亡的「老古董」了。雖然我並不認同相似觀點，但不能否認的是，Delphi 確實已，也會更加小衆，除非有新的適宜它的廣闊領域或巨大機遇，否它幾乎很難東山再起了——更悲劇的是，目前看來，可能很難有這樣的領域或機遇了——想一想 Delphi 1&2 是怎麼火起來的，拋開其當時確實牛叉的技術，Win16/32 的流行普及纔是帶動這類開發工具/語言發展的主要因素。
　　雖然 Delphi 已支持開發 iOS、Android 及 Mac 應用甚至（聽說）即將支持開發 Linux 服務器程序，按牌面講簡直就是跨平臺開發的莫大利器，但事實上，產品質量往往不及甚至遠不及預期，太急功近利的產品發佈尿性，嚴重的內部動盪及沒有可依靠的大腿等因素綜合在一塊兒，直接致使 Delphi 陷入惡性循環，並且彷佛愈演愈烈——如斯情景，Delphi 能不慢慢泯然衆人才真是奇蹟！
　　04 或 05 年還在讀大學的時候，有一段時間我常常窩在宿舍，看着《JAVA核心技術》，照着各種 Demo 用 JCreator 擺弄着一些 Java Applet 小程序（譬如嵌在網頁裏的打飛機小遊戲），以爲 Java 好厲害，我要學好它之後靠它吃飯呢。
　　——並且還記得，在選擇學習 C# 仍是 Java 的時候我猶豫了好幾天，最終仍是選了自學 Java（緣由實在記不清了，可能和 James Gosling 有大鬍子有關？:)），雖然 C# 是 Anders Hejlsberg 設計的。
　　但大學期間的我，喜歡沒事跑校圖書館，除了看古龍金庸等武俠，還有計算機類書目。因而很天然地，有一天我偶然看到了那本很厚的《Delphi5開發人員指南》，而很俗套卻確實是事實的是，我被其前言裏的「真正的程序員用 C，聰明的程序員用 Delphi」這句給「蠱惑」了，接下來很明顯，我花了很多時間瞭解了 Delphi 的前世此生，而後顯而易見的，從圖書館借了幾本 Delphi 相關的書籍，並由此學習了一點皮毛，進而爲以後的工做學習打了點基礎。
　　那個時候，我還不懂得感覺 Delphi 自己設計理念的優秀及超前，不懂得欣賞 VCL & RTL 實現之美，不懂得學習領會 Delphi 實用的語言語法特性等，基本上只是感受 Delphi 好強大，寫東西好方便——譬如搞界面，實在比在 Java 裏要本身手動一行行編碼方便太多了。而 Delphi 6/7 也在我當時的渣渣筆記本（NEC 的二手本子，彷佛只有 128MB RAM，CPU 型號實在不記得了）上跑得挺歡快，但 JBuilder 卻幾乎無法使用，這可能也是我後來沒怎麼繼續學習使用 Java 的重要因素吧...
　　09 初，經由 savetime 提攜有幸進入盛大遊戲，開始用 Delphi 開發遊戲（是的，就是《傳奇》），也有幸結識了像 savetime、範哥 等大牛，及 Colin、Ryan 等諸多牛人，本身也慢慢對 Delphi 的使用及理解有一些質的提高——我很懷念那個時候和幾個對技術較沉迷的同事一塊兒探討研究的時光，這樣的經歷對自身提升幫助很大，惋惜這樣的日子過短了。
　　還記得那時，Colin 用 VC++ 寫了個 2D 繪製引擎，我也不甘示弱用 Delphi 擼了個，而後相互比拼繪製速度，甚至好像有一次個人引擎速度不正常地大大快於 Colin 的版本，惹得不光 Colin 質疑連我本身都以爲有問題，後來查代碼才發現本身的 batch rendering 搞得太狠，彷佛將圖片繪製順序給無視了...
　　而那時跟 Ryan 等一塊兒蛋疼折騰 80x86 彙編優化以使 Delphi 生成的機器碼速度能媲美 VC++ 等的記憶，也彷佛還很清晰——是的，DCC32/64 生成的代碼質量相對而言明顯過於落後時代了！即使有 FastMM、FastCode 等三方庫，但這根本不足以彌補 Delphi 欠下的技術鴻溝——看看 C++ 及 JIT 等編譯器的長足進步吧！
　　很明顯，只是由於核心人才的持續甚至大量流失，才使得 Delphi 被拋下太遠，心有餘卻無力追越它者的身影。這實在是個悲傷的故事。
　　沒什麼強人坐鎮，相反卻動盪不斷折騰不停失血不止，且員工水平良莠不齊等等等等，我真心沒法對 Delphi 的將來抱有多少樂觀見解——即使它彷佛抱對了 LLVM 的大腿，也正確地趟進了跨平臺的潮流。

　　但即使它前景彷佛黯淡，也並不妨礙我對 Delphi 諸多特性及理念的推崇和讚揚，僅舉幾例以下。
　　1) language syntax：Delphi 語法嚴格嚴謹但卻不失靈活及強大，與之造成鮮明對比的必然是 C++，我的而言，Delphi 在工程實用性、代碼可維護性等方面明顯領先 C++ 太多（固然確定有不少人反對），相信對這二者都有過經歷的碼農或多或少能部分認同吧，「若是你認爲 C++ 還不算太複雜, 那麼請你解釋何謂 "protected abstract virtual base pure virtual private destructor"，你又會在什麼時候須要它呢？」，何其鮮明的學院派特性。我很認同 Golang 宣揚的一個理念：少便是多。不少人也知道一些大公司嚴格限制只容許使用 C++ 的一部分子集，這顯然能代表 C++ 在語言設計上的失敗。應該是我的能力問題吧，相較起閱讀 STL 的源碼，我更喜歡看 RTL & VCL 代碼，可能那種簡潔明瞭、幾乎樸實無華的東西更能吸引我。
　　2) Compilation speed：雖然 Delphi 語法確實相較而言簡單很多，雖然 dcc 只是 one-pass scan，且生成的代碼質量過於通常（這事實上更應歸咎因而開發人員的水平問題），但 dcc 那閃電般的編譯速度，即使到如今，也未見有哪一個編譯器能望其項背，至於 C++，呃，仍是不談了，譬如當牽扯到 template 等的時候...惋惜 dcc 自從 Anders Hejlsberg 離開後彷佛再無多少實質的突破，實在很是惋惜！
　　3) procedure of object：可能不少人沒意識到這是很是實用的語法糖或編譯器魔法，只是理所固然地照本宣科用着。其實我之前也並沒太以爲它的實用性，只是後來在編寫 ASC 的過程當中，想要在 C++ 裏模擬這種實現的時候卻只得求救於 C++11 的 function，那時仍是小小地敬佩了 Delphi 一把——是的，在 Delphi 裏使用這個特性是那麼的天然，以致於咱們都忽略了它的實際價值。
　　4) initialization & finalization：很明顯，package init 這個語法代表 Golang 在工程實用方面有實際地考量，這也是我當初以爲 Golang 偏實用的依據之一。想一想這倆特性的使用場景，及如何在 C++ 裏實現它們吧（C++Builder 除外）。
　　5) property：就我（目前）所知，除了 C#（畢竟和 Delphi 有着同一個爹），沒有哪一個語言對 getter & setter 的封裝能有 Delphi 這樣優雅。譬如 Python，抱歉，我真心以爲它的語法設計隨意成分高了些，即使它只是腳本語言，但在語法層面，可能它遠不夠譬如 Pascal 等規範嚴謹，更多的是約定和規定——固然這只是我我的很是淺顯的感覺，極可能頗有失偏頗。
　　6) RTL：Delphi 的方便及實用，在 RTL 的設計及豐富程度上可見一斑，IntToStr、Trim、TStream、TList、TStrings、TThread 等等等等，用的時候順手拈來，倍感愉悅，固然 STL 甚至 Boost 更強大得多，只是，我就是抱有偏見地以爲，Delphi 的 RTL 簡潔明瞭，使用便利（引用簡單，編譯快速）。
　　7) VCL：這個幾乎不需我多說什麼，至今也沒有什麼語言或工具在開發 GUI 層面哪怕只是接近 Delphi 的方便強大程度（也許 C# 能接近，但論起 RAD，明顯它不夠天然直接）。也許有人會舉例說 QT，甚至 duilib 等之類，但我相信，用過的天然懂。
　　8) Drag-and-drop：幾乎確定會有人說這種拖拉控件的作法好 low，而我也幾乎能夠確定，持這種見解的人，其水平及眼界可能還比較 low。將複雜的問題簡單化，提供易於操做的行爲，這是否是工程實踐上大道至簡的深入體現呢？
　　...等等等等。

　　還在盛大時，曾有位 C++ 背景濃厚的同事（以前就任於金山從事 WPS 開發）應需須要開發一款圖庫編輯器，我建議他直接就用 Delphi 吧，只是後來各類緣由他選用了 VC++，並使用了 QT，固然工具是作出來了，只是耗時久了些，我開玩笑說我若是用 Delphi 也許只需 二、3 天甚至更短就能擼一個不比你這差的出來，他說那是你厲害云云，我否定，並直言其實這主要是 VCL & RTL 的功勞，我只是某種程度上會用合適的工具來快速高效地實現需求而已。
　　順便說下，WPS 爲什麼棄 Delphi 而選用了 QT，緣由只有一個：那時金山內部會 Delphi 的技術人員走得只剩下一個了（並且彷佛仍是珠海本地人），更要命的是在珠海很難招到合適的 Delphi 程序，無奈，只好轉用了 QT。這事 Colin 比較瞭解:)
　　在上一家公司時，有位同事曾堅持要用 C++ 來寫各種輔助工具，包括但不限於各種編輯器等，但在個人分析及建議下，他仍是聽取了意見，將某些很差實現或重要的功能封裝成 dll，其它的則以 C# 來完成。如斯作法，模塊化等是一方面，工期也縮短很多。
　　扯這些，只是想代表一個觀點：要用合適的工具作合適的事。
　　譬如作 Win32/64 上的普通應用開發，一般狀況下可能選用 C# 或 Delphi 更合適些，C++ 固然也能夠，只是明顯它不夠方便快速（並且某種程度上技術要求也高一些）。雖然 Delphi 如今用得不那麼廣，但它幾十年的沉澱及積累，倒是莫大的技術寶庫。僅對於我我的而言，業餘若是須要，仍是會拿它來寫寫東西——除了感情成分及一點積累的因素外，方便、快速確實是主要緣由。
　　曾有段時間，我對 Python 有些興趣，也想拿它寫寫小工具之類，不能否認，Python 的三方庫實在太強大了！可能吧，Python 的流行，語言因素倒不過重要，豐富、強大的三方庫纔是吸引人的主要緣由。即插即用，幾乎不用在乎繁文縟節，只需關注要實現的功能，委實很方便，即使相對而言它的執行效率差不少，多線程實現也很不夠好（GIL 鎖）——畢竟大部分狀況下，效率並不是最核心的因素，快速實現原型才最重要。但後來我仍是改用 Delphi 寫小工具，主要緣由只是，我但願最後生成的最好只是個可執行程序，無需任何額外的依賴或部署。因而腳本語言不合適了，C#/Java 也不知足要求，剩下的無非也就 C++、Delphi 及 Golang 等了，很明顯，這種場合下 Delphi 毫無疑問會勝出。

　　僅我我的喜愛，譬如程序語言，我鐘意的特色及特性以下。
　　1) 原生
　　2) 語法簡單，語言設計以實用爲導向
　　3) 編譯迅速，執行快速
　　4) 標準庫豐富多樣
　　5) 有各式各樣強大的三方擴展庫
　　6) 有着易用的 IDE
　　因而很明顯，符合要求的只有 Delphi 和 Golang，而 Golang 顯然更適合服務器端開發等領域（固然拿來作 Web 開發也彷佛 OK），goroutine 和 channel 實在是很是廉價卻又很是簡潔高效的併發利器，這樣的特性對於服務器端開發來講很是有用且重要，很大程度上簡化了服務器端的多線程相關邏輯實現，在語言核心層面支持並行和分佈式，併發模型簡潔高效，簡直是天生的後端開發牛刀（更可喜的是其 GC 也有着持續巨大的進步）。

　　是的，基於 Win32/64 的應用開發市場彷佛已在慢慢萎縮，這也必定程度致使像對 C++ 等人員的需求明顯減小。時代在變遷，如今早已不是幾十年前惟 Windows 一家獨大的時代了。多種平臺或生態，各種語言或技術，大大分流或甚至，歸類了程序員（「全棧」？可能比大熊貓還稀有吧）。可能不少程序員在入行時會猶豫，這麼多的技術這麼多的行業，該如何選擇。
　　可本文沒法回答這樣的問題。
　　僅於我我的而言，靠着勉強算「多年」的鬆垮的學習及工做經歷經驗，譬如各種程序語言（包括不限於 Asm、C/C++、C#、Delphi、Golang、Java、JavaScript、Lua、PHP 及 Python 等），我幾乎都能在幾天甚至幾小時內快速上手。某種程度上，語言自己確實不是很重要（喜歡追根究底鑽研底層實現的除外），正如 範哥 曾在微信裏說的：編程這件事，誰也沒勇氣自稱爲專家，學得越多，懂的越少，作程序的，更重要的是跳出框框，不要被語言語法束縛，要有本身的一套解決問題的思想和辦法。
　　但即使如此，我估計也會在須要或感興趣的時候，研究些算法，嘗試些新實現或新框架，學習或使用譬如 JavaScript 等語言技術。技術人員麼，固步自封最好不要，即使流行的東西不必定是對的，跟上時代，拓寬眼界總不會錯。