《软件随想录》的随想

      这是一本很有趣的书，让我经常在公车上傻笑，不枉推荐人的强力推荐+免费送货上门。
      学到一些东西，比如要装B应该找些比设计模式复杂的东西。他选择的是递归函数论。以前有句古话：五十步笑百步。在现代社会可以改成八十步笑五十步兼笑百步。他在书中一边抨击java、设计模式太简单，不能体现智力差别；一边说动态数理逻辑不够实用，不能用来实现真正有用的东西，所以他不读计算机科学的研究生。嗯。他觉得合适的点是递归函数论，我一直以小人之心腹诽那是因为他正好学过而且学得不错。怎么办呢？我们学校没教过递归函数论。不过我学过自动机与可计算理论，而且学得很好，成绩高达95大分。以后不跟人说设计模式了，言必及自动机。设计模式？ too naive，让我们来聊聊可计算理论吧。
      很多观点我同意他的，或者说我只能同意他的，因为我没开过公司卖过软件，项目管理也很山寨。但此书有两个观点我是严重不同意的。
      第一，关于匈牙利命名法。他说那是合理的，是大家误会了匈牙利命名法的本意。也许匈牙利命名法的本意的确是标志kind而不是傻乎乎的type。但类比一下，现在大家都默认臭指代不好的气味，虽然在太古时代臭的意思是中性词：味道，但是现在会有人说这股臭真好闻吗？所以带type匈牙利命名法被打倒了就别翻黄历想翻案。在变量名中带kind还是有一定道理的。尤其是要表述的意思太长的时候，width和height比 wFoo和hFoo孰优孰劣一目了然。但如果要表示的是点的数目, pixelCntInWidth 就略显啰嗦了，pcWidth和pcHeight将更简明。规则的适应需要时间，但适应后应该可以提高编程效率——如果软件很多地方需要用到“pixel 数”这个概念的话。上面这个例子也说明kind和 type的区别，如果是带type的匈牙利命名法，iWidth和iHeight？或者iPixelCntInWidth和 iPixelCntInHeight？这个变量是啥类型只要鼠标移过去不就清楚了吗？除了折腾程序员几乎毫无用处。所以当年程序员暴动反抗傻不隆冬的带type匈牙利命名法毫不奇怪。
      第二，关于异常。他对异常有偏见并且举的例子也很烂。我也不浪费时间分析了。