《软件随想录》的随想

      这是一本很有趣的书，让我经常在公车上傻笑，不枉推荐人的强力推荐+免费送货上门。
      学到一些东西，比如要装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匈牙利命名法毫不奇怪。
      第二，关于异常。他对异常有偏见并且举的例子也很烂。我也不浪费时间分析了。