汇编与IL：老赵给的视角非常不错，受用了。
不过关于CLR内幕，我这里有一个问题，这些细节，大多数人知道它干吗？
如果一个项目不under the hood不行了，我肯定滚去使用C/C++了...
我不是提什么反对意见，我是想知道具体场景。
关于算法：回复中支持算法的兄弟们说的都很不错。
实际上，这里头最关键的一点是我们先要明白，算法没多难，也许之后再明白，数学没多难（没做到）。
具体说到大多数从业人员，算法造诣确实不是必需的；不过没有算法你也要有其他的东西。
我们不可能解决所有问题，但很擅长解决某一类，就是我们的特色了。
说到底还是一个（决定自己）价值体现在哪里的问题；尤其是硬骨头，永远免不了。
说点自己的事情。
一个对象，你给他什么操作，很多时候确实很难决断。
很早就说过，简单的“主语.谓语”式OO根本搞不定复杂的问题：缺乏有指导作用的建模方法。
存在多种看待问题的视角是很自然的事情，关键在于我们根据怎样的原则在其中挑选。
一些经验：相对于其它原则，代之以层次去决定操作如何在对象间安排。
为什么？因为抽象之前就要回答：关心的是哪个层次。
为什么我又开始说对象呢？因为我降低了函数式的使用程度和深度。
我要开始反思和总结过去一年的函数式热了。
初步体会，关键不在于函数式不能干什么，而在于某一个风格对我们的导向。
当你把一个函数的自变量和因变量其本身设计的足够合适，就会发现纯函数式风格的糖豆未免太少了些。
糖豆不应仅只是方便，也意味着一个更好的说明意图的方式。
切掉高阶函数等从非函数式看是糖豆的东西，在函数式风格上的挖掘又带给我们什么呢？
风潮本身给毫无顾忌的状态使用刹了车，提醒我们习惯之外的合理做法。【1】
我们应该时刻衡量一个状态的产生有无必要性，在空间和时间上有什么影响，尤其是沿什么路径传播的。
空间主要是指状态在数据结构之间，而时间在这里指的却是项目的成长期。
从这个角度来看，函数式的重新兴起是有意义的。
非函数式风格的难题在于交错的状态，反过来函数式风格的关键在于如何安排好数据结构之间的关系。
搭配？其实不是一件非常必要的事情。糖豆级的使用也说不上什么搭配。
一个合理的风格选择的衡量标准，恐怕是可读性。
如果自己读自己的程序，看起来不像一个傻瓜写的，那么也许切换些风格是不错的选择。
毕竟，在KISS面前，没有任何借口。
update：
注释【1】：
说点和大家相关的，回忆起以前的贫血模型、静态方法的讨论，不得不承认，在很多情况下这是增一分则多的方案。
我过去使用的方法是退化模型，就是我认为简单的结构是通过更复杂的退化得来的会比较舒服。
但这样在前期似乎不必要的工作量大了一些，相反“进化”在后期又可能痛苦。
上文说“习惯之外”，但这个“架构”恰恰在很多人习惯之内；只是有人总担心它太简单，然后担心又成为了习惯。
说这些不代表我支持某种风格的开发过程；只是这个问题，关乎于学习和实践，值得玩味。
update again：
由此想到，果然多范式运用再加上动态语言（最近用的python）也无法找到我想要的那种感觉。粘合和进化还是两码事情。
只可惜我不能以目前的生存状态一直持续下去，这样在语言设计上的学习、尝试，只能一推再推，不爽。