程序人生之杂扯篇

　　确实，做为已撸了快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 等语言技术。技术人员么，固步自封最好不要，即使流行的东西不必定是对的，跟上时代，拓宽眼界总不会错。