Re: 学会透过现象看本质，即使现象有时候挺诡异
编程随想
最近看到一个汽车对冰淇淋过敏的小故事，转述如下：
某汽车公司收到投诉信，用户抱怨说他每晚都从家里开车去商店买冰淇淋。如果买的是香草冰淇淋，则回家时汽车就无法发动；如果买其它口味的冰淇淋，则汽车可以正常发动。天天如此。该用户怀疑这汽车是否对香草冰淇淋过敏。
汽车公司的头头觉得这太过诡异，不过还是派了一个工程师去该用户家调查原因。第一天，工程师和用户一起去买冰淇淋。在店里，工程师要求买香草口味，结果 出来后，汽车果然不能发动。此后几天，工程师每次都和用户一起去买，每次都由工程师临时决定买什么口味。果不其然，凡是买了香草口味，汽车就无法发动；反 之则可以。（由于是工程师临时决定购买的类型，可以排除用户搞恶作剧的可能）
这个工程师是一个理性的人，也不信神，当然不会相信汽车过敏这一说。但是他觉得有更深层的原因在起作用。此后，他每天晚上和该用户一起去买冰淇淋，每 次他都详细记录往返的时间、途中踩油门和刹车次数、使用的汽油型号等各种信息。许多天后，他终于发现规律：凡是买香草口味的，在商店里面花的时间少（因为 这个口味受欢迎，摆放的货架靠门口）。
于是问题就转化为：停车的时间短导致汽车不能正常发动。然后，工程师就轻易找到了原因（当停车时间太短，发动机依然很热而无法驱散气阻）。
这个故事给我们几个启发：
1、不要拒绝接受貌似很诡异、很离奇、很不可能的现象。我手下的很多程序员都曾经抱怨测试提交的某个bug太怪异，对这些bug不予承认。你想一想自己是否也有类似情况？
2、要善于从一些细节发现规律，从而查出问题的根源。如果你是这个工程师，你能否通过细致的观察而发现其中的规律？
----------------
编程随想的blog
http://program-think.blogspot.com
补充一下：
本文的原始地址
http://program-think.blogspot.com/2009/02/from-surface-to-essence.html
那个小故事的原始地址
http://www.plant-maintenance.com/articles/pontiac.shtml
----------------
编程随想 Blog
http://program-think.blogspot.com
编程随想
pongba
某汽车公司收到投诉信，用户抱怨说他每晚都从家里开车去商店买冰淇淋。如果买的是香草冰淇淋，则回家时汽车就无法发动；如果买其它口味的冰淇淋，则汽车可以正常发动。天天如此。该用户怀疑这汽车是否对香草冰淇淋过敏。
汽车公司的头头觉得这太过诡异，不过还是派了一个工程师去该用户家调查原因。第一天，工程师和用户一起去买冰淇淋。在店里，工程师要求买香草口味，结果 出来后，汽车果然不能发动。此后几天，工程师每次都和用户一起去买，每次都由工程师临时决定买什么口味。果不其然，凡是买了香草口味，汽车就无法发动；反 之则可以。（由于是工程师临时决定购买的类型，可以排除用户搞恶作剧的可能）
这个工程师是一个理性的人，也不信神，当然不会相信汽车过敏这一说。但是他觉得有更深层的原因在起作用。此后，他每天晚上和该用户一起去买冰淇淋，每 次他都详细记录往返的时间、途中踩油门和刹车次数、使用的汽油型号等各种信息。许多天后，他终于发现规律：凡是买香草口味的，在商店里面花的时间少（因为 这个口味受欢迎，摆放的货架靠门口）。
于是问题就转化为：停车的时间短导致汽车不能正常发动。然后，工程师就轻易找到了原因（当停车时间太短，发动机依然很热而无法驱散气阻）。
--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba
chaosong fu
王宁
这个经验在工作中十分有价值。当用户、市场或其他非工程师提出问题或想法时，切勿武断的否定。想清楚哪些是假设/解释/猜想（汽车对香草冰激凌过敏），哪些是事实或者观察（汽车熄火可能与冰激凌有关），如何验证这些观察，以及如何基于（错误的）观察提出新的想法。事实上，很多好的想法都是具有不同专业背景的人共同提出来的。这需要大家互相尊重对方的想法，同时存疑。
另一个启发是，陈述对于解决问题是有帮助的。比如说，写Email、文档或者注释的时候，应该尽量把事实（数据、定理、引用）和推断（猜想、假设）分开写明。比如说，"我家汽车对香草冰激凌过敏"这样的说法就混淆了事实和推断。相比之下，原文中用户的陈述就很清楚，大家可以读一读，比较一下。
"This is the second time I have written you, and I don't blame youfor not answering me, because I kind of sounded crazy, but it is a fact that we have a tradition in our family of ice cream for dessert after dinner each night. But the kind of ice cream varies so, every night, after we've eaten, the whole family votes on which kind of ice cream we should have and I drive down to the store to get it. It's also a fact that I recently purchased a new Pontiac and since then my trips to the store have created a problem. You see, every time I buy vanilla ice cream, when I start back from the store my car won't start. If I get any other kind of ice cream, the car starts just fine. I want you to know I'm serious about this question, no matter how silly it sounds: 'What is there about a Pontiac that makes it not start when I get vanilla ice cream, and easy to start whenever I get any other kind?'"
很多时候，我们都是因为轻易接受了别人看似正确的结论，没有分清基本的事实和推断，而耽误了很多时间。例子很多，相信大家也常常碰到，不废话了。
Kenny Yuan
sagasw
这也算是一个bug，任何一个bug都不会是灵异事件，一定是有什么问题发生，缩小范围，减小重现的条件，简化到一个不能再简化的模型，自然就容易找到问题了。
MIK
与你相似,我越来越讨厌自以为是的人了.
On 2月2日, 下午6时01分, Kenny Yuan <yuankain...@gmail.com> wrote:
> 越来越讨厌伊索寓言式的故事了
Kenny Yuan
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL: http://blog.csdn.net/yuankaining/
pi1ot
真正消耗我们宝贵的人肉CPU运算时间的其实是那些琐碎的，随机的，低层级的，纯粹随代码量而来的日常BUG，比如笔误。
On 2月3日, 上午10时20分, sagasw <sag...@gmail.com> wrote:
> 我一直坚持的一个观点，就是程序员必须具有福尔摩斯一样敏锐的想像力、观察力，另外要像福尔摩斯一样大量收集资料、学习相关领域。
>
> 这也算是一个bug，任何一个bug都不会是灵异事件，一定是有什么问题发生，缩小范围，减小重现的条件，简化到一个不能再简化的模型，自然就容易找到问题了。
>
> 2009/2/2 编程随想 <program.th...@gmail.com>
>
> > 最近看到一个*汽车对冰淇淋过敏*的小故事，转述如下：
>
> > 某汽车公司收到投诉信，用户抱怨说他每晚都从家里开车去商店买冰淇淋。如果买的是香草冰淇淋，则回家时汽车就无法发动；如果买其它口味的冰淇淋，则汽车可以正常 发动。天天如此。该用户怀疑这汽车是否对香草冰淇淋过敏。
> > 汽车公司的头头觉得这太过诡异，不过还是派了一个工程师去该用户家调查原因。第一天，工程师和用户一起去买冰淇淋。在店里，工程师要求买香草口味，结果
> > 出来后，汽车果然不能发动。此后几天，工程师每次都和用户一起去买，每次都由工程师临时决定买什么口味。果不其然，凡是买了香草口味，汽车就无法发动；反
> > 之则可以。（由于是工程师临时决定购买的类型，可以排除用户搞恶作剧的可能）
> > 这个工程师是一个理性的人，也不信神，当然不会相信汽车过敏这一说。但是他觉得有更深层的原因在起作用。此后，他每天晚上和该用户一起去买冰淇淋，每
> > 次他都详细记录往返的时间、途中踩油门和刹车次数、使用的汽油型号等各种信息。许多天后，他终于发现规律：凡是买香草口味的，在商店里面花的时间少（因为
> > 这个口味受欢迎，摆放的货架靠门口）。
> > 于是问题就转化为：停车的时间短导致汽车不能正常发动。然后，工程师就轻易找到了原因（当停车时间太短，发动机依然很热而无法驱散气阻）。
>
> > 这个故事给我们几个启发：
> > 1、*不要拒绝接受貌似很诡异、很离奇、很不可能的现象*
> > 。我手下的很多程序员都曾经抱怨测试提交的某个bug太怪异，对这些bug不予承认。你想一想自己是否也有类似情况？
> > 2、*要善于从一些细节发现规律，从而查出问题的根源*。如果你是这个工程师，你能否通过细致的观察而发现其中的规律？
>
> > ----------------
> > 编程随想的blog
> >http://program-think.blogspot.com
pongba
我也相信寓言故事本身价值是很小的，我们中国的学生从小看了N多的寓言，但结果全都忘掉，啥也没学到。比如小时候估计每个人都听过的"白头翁"的故事：因为什么都想学，什么都学不精，所以白了头也没学到啥东西。另外还有很多禅宗的寓言更是晦涩。
我想最重要的原因是寓言本身设定了故事发生的情境，这个情境阻碍了我们将其中的道理推广到其他陌生但本质一致的情境中去。比如白头翁的故事的情境就是一只小鸟，可我们并不是一只小鸟。另一个原因就是生活中的情境几乎总是很复杂的，几乎总是有更高优先级的规则来驱使我们的行为，譬如我们固然知道要专一学习一样东西，但是平时看到某个牛人提到某样知识我们却不知道，很少有人会忍住模仿的冲动吧？
话虽如此，寓言本身并没有任何问题，问题在于我们是不是充分地进行了思考，寓言里面的道理是真正切切的，即便寓言本身是虚构的，问题就在于我们是否能够提取出这个道理的本质，是否能够将它记住并在需要的场景下从脑海中提取出来，后者才是真正困难的事情，也是（我认为）很多人之所以看了故事却不长记性的原因。
我相信寓言本身并没有错，因为所有道理都是要从具体事件当中观察提取抽象出来的，并且在说理的时候我们时时必须借助于故事（实际的或杜撰的）来令人印象深刻，人的认知系统的本质决定了如此。
P.S. 一个有趣的故事：
一个贫穷的农夫向上帝祈祷赐予他财富。上帝果然听到了，对他说：我可以赐予你财富，但是无论我给你多少，都会给予你的邻居们双倍。
结果，农夫说，我想要我的庄稼毁掉一半。
rockeet
原来是不管是调试，还是printf，都增加了两个函数调用的间隔时间，而bug只有在间隔时间短的时候才出现
On 2月3日, 下午12时55分, Kenny Yuan <yuankain...@gmail.com> wrote:
> 同意一下下
> 海森堡型的BUG最讨厌（without reproducing steps）
> 而可重复出现的BUG，多数很快就能够找到原因
>
> 2009/2/3 pi1ot <pilot...@gmail.com>
pongba
海森堡型的BUG，这个比喻很恰当，曾有过一个bug，当调试，甚或增加一个printf来打印可以数据时，bug就奇妙地消失了。折腾了好多次，发现
原来是不管是调试，还是printf，都增加了两个函数调用的间隔时间，而bug只有在间隔时间短的时候才出现
这么说的话，难道不应该是海森堡bug更容易捕捉吗？普通bug是要大海捞针，而海森堡bug意味着我们加入的调试手段改变了程序的行为，那么只要从调试手段引入了哪些变化上找就行啦（至少我们知道where to look吧）。
真正麻烦的是随机bug而不是海森堡bug吧，随机bug的典型例子就是多线程bug。
Jeffrey Zhao
public int GetRandom()
{
Random random = new Random(DateTime.Now.Millisecond);
return random.Next();
}
int[] array = new int[10];
for (int i = 0; i < array.Length; i++) {
array[i] = GetRandom();
}
问我，为什么单步调试时是好的，直接执行数组里就都变成一样的了呢？
Jeffrey Zhao
--------------------------------------------------
From: "rockeet" <roc...@gmail.com>
Sent: Tuesday, February 03, 2009 2:02 PM
To: "TopLanguage" <pon...@googlegroups.com>
Subject: [TopLanguage] Re: 学会透过现象看本质，即使现象有时候挺诡异
居振梁
测试的准确性还可能受其他不相干进程数量的影响。
我想到了这个，有人问我：
public int GetRandom()
{
Random random = new Random(DateTime.Now.Millisecond);
return random.Next();
}
int[] array = new int[10];
for (int i = 0; i < array.Length; i++) {
array[i] = GetRandom();
}
问我，为什么单步调试时是好的，直接执行数组里就都变成一样的了呢？
--
御剑乘风来，除魔天地间
有酒乐逍遥，无酒我亦颠
一饮尽江河，再饮吞日月
千杯醉不倒，唯我酒剑仙
Tiny fool
你的问题是，你应该初始化一次Random对象，然后每次取Next。而你的做法是每次都初始化一次Random，而因为现代计算机太快了，所以DateTime.Now.Millisecond在你的多次调用中是一样的。所以，种子一样，自然生成的随机数也一样。
但是这个Bug很有欺骗性，不仔细看就造成我看错了。我一开始怀疑是因为这个函数没有任何的参数，所以编译器就把对这个函数的10次调用优化成一次了，所以到处去找Java的volatile修饰符的用法，强制编译器每次都运行这个函数。但是我突然想，万一我错了呢，于是在return random.Next();前面加了一个printf来测试，发现每次函数都运行了，但是结果还是都一样。
你的程序改为
Random random = new Random(System.currentTimeMillis());
public int GetRandom()
{
return random.nextInt();
}
就会万事Ok的。
--
--------------
Gmail: tiny...@gmail.com
Gtalk: tiny...@gmail.com
Msn: tiny...@hotmail.com
Phone: 13520711089
银杏技术咨询公司
http://www.yinxingtech.com/
Tinyfool的开发日记
http://www.tinydust.net/prog/diary/diary.htm
TV的Google观察
http://www.tinydust.net/tinygoogle/
rockeet
很多蝉，都会间歇性地大灭绝（灭绝大部分，但不是完全灭绝），其最显著的效果就是天敌被饿死的更多，从而自己有喘息的机会。
On 2月3日, 下午1时51分, pongba <pon...@gmail.com> wrote:
> 2009/2/3 Kenny Yuan <yuankain...@gmail.com>
>
> > 伊索寓言
>
> 我也相信寓言故事本身价值是很小的，我们中国的学生从小看了N多的寓言，但结果全都忘掉，啥也没学到。比如小时候估计每个人都听过的"白头翁"的故事：因为什么-都想学，什么都学不精，所以白了头也没学到啥东西。另外还有很多禅宗的寓言更是晦涩。
>
> 我想最重要的原因是寓言本身设定了故事发生的情境，这个情境阻碍了我们将其中的道理推广到其他陌生但本质一致的情境中去。比如白头翁的故事的情境就是一只小鸟，-可我们并不是一只小鸟。另一个原因就是生活中的情境几乎总是很复杂的，几乎总是有更高优先级的规则来驱使我们的行为，譬如我们固然知道要专一学习一样东西，但是-平时看到某个牛人提到某样知识我们却不知道，很少有人会忍住模仿的冲动吧？
>
> 话虽如此，寓言本身并没有任何问题，问题在于我们是不是充分地进行了思考，寓言里面的道理是真正切切的，即便寓言本身是虚构的，问题就在于我们是否能够提取出这-个道理的本质，是否能够将它记住并在需要的场景下从脑海中提取出来，后者才是真正困难的事情，也是（我认为）很多人之所以看了故事却不长记性的原因。
>
> 我相信寓言本身并没有错，因为所有道理都是要从具体事件当中观察提取抽象出来的，并且在说理的时候我们时时必须借助于故事（实际的或杜撰的）来令人印象深刻，人-的认知系统的本质决定了如此。
jinhu wang
2009/2/3 Jeffrey Zhao <je...@live.com>:
pongba
Tiny fool
pongba
一点没错，这其实是我们的大脑还没有跟上时代:) 另一个我个人认为很不错的例子就是，我们常常会在意周围的人对自己怎么看，这种社会心理在远古社会，大家一般以一小撮一小撮相对稳定的团体集聚的时候是有意义的，因为小群体内部利益往往相关性较大，因此得到社会认同的潜在价值很大；然而现代工业社会，特别是城市里面，人员流动性极大，密集度和规模都远远不是远古社会可比的，当你走在大街上，99%的人都属于那些老死不相干的人，在意这些人的看法一点意义也没有。
pi1ot
On 2月3日, 下午2时07分, pongba <pon...@gmail.com> wrote:
> 2009/2/3 rockeet <rock...@gmail.com>
>
> > 海森堡型的BUG，这个比喻很恰当，曾有过一个bug，当调试，甚或增加一个printf来打印可以数据时，bug就奇妙地消失了。折腾了好多次，发现
> > 原来是不管是调试，还是printf，都增加了两个函数调用的间隔时间，而bug只有在间隔时间短的时候才出现
>
> 这么说的话，难道不应该是海森堡bug更容易捕捉吗？普通bug是要大海捞针，而海森堡bug意味着我们加入的调试手段改变了程序的行为，那么只要从调试手段引 入了哪些变化上找就行啦（至少我们知道where
Tiny fool
表面上看起来这种干扰很麻烦，其实反而告诉我们更多的细节。例如前面的例子，单步没有问题，执行有问题。那么最直观你知道单步和直接执行的差别是什么？时间，呵呵。
pongba
表面上看起来这种干扰很麻烦，其实反而告诉我们更多的细节。例如前面的例子，单步没有问题，执行有问题。那么最直观你知道单步和直接执行的差别是什么？时间，呵呵。
你把我的意思更好地表达了:D
Kenny Yuan
但我说的伊索寓言是真正的伊索寓言，不是人们印象中的那个伊索寓言。其实伊索寓言里面只有少量精华，多数故事都很牵强附会，我读过在网上搜来的伊索寓言全集（可能不是真正最全的，似乎几百K？？），其中能让人信服的寓言故事少之又少，多数都和那种典型的宗教故事一样缺乏合理性。例子我就不举了（暂时也背不出来），我相信想求证的人会去搜索的。
与此同类的东西还有一本《本草纲目》，鸡屎白，大便，尿，黑驴肉，死人枕席，猪肉，雄鸡……都是药材，比如治疗口腔溃疡是用"鸡屎白一升绞汁服"。我相信这样的事实和许多人的道听途说来的印象很不一致、相当地不一致。（感兴趣的同学也可以去搜一下本草纲目的全文）
Kenny Yuan
MIK
与您作为一个成年人有关,其实您所说的"让人信服"的概念对于不同年龄的人来说有不同的意义.
给我的感觉就是您对不合自己理念的东西缺乏包容的心态,或者说执著于某一个方向看问题.
On 2月3日, 上午12时04分, Kenny Yuan <yuankain...@gmail.com> wrote:
> 其实你说的是好寓言，好故事。在这个前提下，我也赞同你的说法。
> 但我说的伊索寓言是真正的伊索寓言，不是人们印象中的那个伊索寓言。其实伊索寓言里面只有少量精华，多数故事都很牵强附会，我读过在网上搜来的伊索寓言全集（可能不是真正最全的，似乎几百K？？），其中能让人信服的寓言故事少之又少，多数都和那种典型的宗教故事一样缺乏合理性。例子我就不举了（暂时也背不出来），我相信想求证的人会去搜索的。
> 与此同类的东西还有一本《本草纲目》，鸡屎白，大便，尿，黑驴肉，死人枕席，猪肉，雄鸡……都是药材，比如治疗口腔溃疡是用"鸡屎白一升绞汁服"。我相信这样的事实和许多人的道听途说来的印象很不一致、相当地不一致。（感兴趣的同学也可以去搜一下本草纲目的全文）
>
> 2009/2/3 pongba <pon...@gmail.com>
>
>
>
>
>
> > 2009/2/3 Kenny Yuan <yuankain...@gmail.com>
Kenny Yuan
友情提示：如果你不喜欢看到不喜欢的文字，可以给gmail设置过滤器。
li li
Li Xunhao
海森堡BUG可能会出现了量子计算机上。
恩，这是我的理解，大家请指正。
2009/2/3 pi1ot <pilo...@gmail.com>:
--
Xunhao Li
Department of Computing Science
University of Alberta
Edmonton, Alberta, Canada
wing fire
问题不是如此简单。
是什么导致工程师有这样的出发点呢？换作上古的萨满巫师，会有这个出发点吗？
另外，在一个真正的问题面前，我们不总是能像这个工程师这样坚定自己的眼光。另外，解决问题的过程也可能是无比困难的，如果尽您一生不能解决，又将如何？
我们轻易地确定汽车过敏，鸡屎白一升是荒谬的。那么夸克呢？粒子汤呢？还有古老的以太呢？会冠以荒谬一词吗？让我假设另一个结局：香草冰激凌散发的香精在高温下和润滑油发生催化反应导致过于粘稠而不能启动。
看透本质的能力不是学到的，是经历了之后领悟的。我们所看到的本质，也未必是问题的根本。仁者见仁，智者见智。看到的都是本质，这个本质却各不相同。
我想说的是，把这几个小故事里的智慧用来对付现实问题，不现实。
---------------------------------------
绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
焚符破玺，而民朴鄙；掊斗折衡，而民不争；
殚残天下之圣法，而民始可与论议。
这里我想插一句，电子计算机没有海森堡这样的BUG，有的话也是人为产生的错误，因为计算机是建立在确定性图灵机上的。
海森堡BUG可能会出现了量子计算机上。
恩，这是我的理解，大家请指正。
Jeffrey Zhao
sagasw
Jeffrey Zhao
MIK
出直接的BUG场景其实可以以便捷的方式来重现，但是本身我们寻找到这样一个直接的场景所耗费的时间和其他的成本也许远远高过冰激凌。
也就是除非你直接联想到，否则我还是更认同重现场景的分析，更有助于联想。这里是发动机的问题，如果说正好买冰激凌的地方有一口高温下水道由此导致的温
度偏差引起BUG，恐怕就不是开开车去别的地方跑就可以重现的。
On 2月4日, 下午1时56分, "Jeffrey Zhao" <je...@live.com> wrote:
> 但是既然相信它和冰激淋无关，为什么非要按照冰激淋的步骤来呢？香草冰激淋只是个充分条件，我可以轻易证明它不是必要条件，这个对于改bug很有帮助阿。然后最后再来检验（或是证明）用户的问题被解决掉了，不就可以了吗？
>
> 这就好比我的项目的例子，我的系统会有测试人员汇报bug，也会有不懂技术的编辑发现问题然后汇报----有的时候也会有类似冰激淋和汽车的这种非常"可笑"的现象，我不觉得技术人员应该直接使用这种可笑的步骤来重现问题。
>
> 故事里的工程师对可笑的步骤进行采样和分析问题，只能说明他严谨，不能说明这是个好办法----试想他统计了那么多数据，不也说明要求顾客买了n多次冰激淋吗？
>
> Jeffrey Zhao
>
> From: sagasw
> Sent: Wednesday, February 04, 2009 1:46 PM
> To: pon...@googlegroups.com
> Subject: [TopLanguage] Re: 学会透过现象看本质，即使现象有时候挺诡异
>
> 估计是没有改过bug的吧，
> 既然是重现问题，就要按照原来的步骤走，要不然，怎么能证明你解决的问题是用户发现的问题呢？
>
> 2009/2/4 Jeffrey Zhao <je...@live.com>
>
> 其实我觉得这个故事，为什么非要把香草冰激淋和汽车故障联系起来。如果我是工程师，就不会非要用户去买香草冰激淋阿。我可能随便开几圈，停下，然后在短时间内启动发现失灵了，或者就在失灵时直接去发现汽车无法启动的机械原因。
> 现在好，还是发现机械原因，附加一个：购买香草冰激淋所花时间短----但是这又有什么用。
>
> Jeffrey Zhao
>
> From: wing fire
> Sent: Wednesday, February 04, 2009 1:18 PM
> To: pon...@googlegroups.com
> Subject: [TopLanguage] Re: 学会透过现象看本质，即使现象有时候挺诡异
>
> >这个工程师是一个理性的人，也不信神，
> >当然不会相信汽车过敏这一说。但是他觉得有更深层的原因在起作用
>
> 问题不是如此简单。
>
> 是什么导致工程师有这样的出发点呢？换作上古的萨满巫师，会有这个出发点吗？
>
> 另外，在一个真正的问题面前，我们不总是能像这个工程师这样坚定自己的眼光。另外，解决问题的过程也可能是无比困难的，如果尽您一生不能解决，又将如何？
>
> 我们轻易地确定汽车过敏，鸡屎白一升是荒谬的。那么夸克呢？粒子汤呢？还有古老的以太呢？会冠以荒谬一词吗？让我假设另一个结局：香草冰激凌散发的香精在高温下和润滑油发生催化反应导致过于粘稠而不能启动。
>
> 看透本质的能力不是学到的，是经历了之后领悟的。我们所看到的本质，也未必是问题的根本。仁者见仁，智者见智。看到的都是本质，这个本质却各不相同。
>
> 我想说的是，把这几个小故事里的智慧用来对付现实问题，不现实。
>
> ---------------------------------------
> 绝圣弃知，大盗乃止；擿玉毁珠，小盗不起；
> 焚符破玺，而民朴鄙；掊斗折衡，而民不争；
> 殚残天下之圣法，而民始可与论议。
>
> 2009/2/4 Li Xunhao <dante.hay...@gmail.com>
>
> 这里我想插一句，电子计算机没有海森堡这样的BUG，有的话也是人为产生的错误，因为计算机是建立在确定性图灵机上的。
> 海森堡BUG可能会出现了量子计算机上。
> 恩，这是我的理解，大家请指正。
>
> 2009/2/3 pi1ot <pilot...@gmail.com>:
Jeffrey Zhao
Jeffrey Zhao
--------------------------------------------------
From: "MIK" <china...@gmail.com>
Sent: Wednesday, February 04, 2009 2:48 PM
To: "TopLanguage" <pon...@googlegroups.com>
MIK
这个我可能跟你的想法有些不同,我更倾向于重现场景,往往来说"尝试的各种其他方式都无法重现问题"这个过程可能代价更为高昂,重现场景给我们提供的线
索往往更多而且更直接.从庞大的系统来说,从较大的系统本身或者说从某个模块本身来说会影响到其行为的因素会更多,这种联想可能会导致更大的耗费.而从
较小的系统来说影响因子更少,可能您说的方式会更有效.
还是要根据实际的情形来判定,您说对么?
On 2月3日, 下午11时06分, "Jeffrey Zhao" <je...@live.com> wrote:
> 我并不是说因为"认准了冰激淋和汽车无关"所以"肯定不应该按照这种可笑的方法来发现问题"，当尝试的各种其他方式都无法重现问题时自然就回到最直接的重现方式上面去了，否则也是种"认死理"。但是我一定不接受故事里的方法，认准了冰激淋而解决问题。而恰好这个故事是一个反面教材，因为如果从一开始就不从冰激淋入手，那么可能早就解决问题了。
>
> Jeffrey Zhao
>
> --------------------------------------------------
> From: "MIK" <chinamix...@gmail.com>
Jeffrey Zhao
Jeffrey Zhao
--------------------------------------------------
From: "MIK" <china...@gmail.com>
Sent: Wednesday, February 04, 2009 3:23 PM
MIK
On 2月3日, 下午11时32分, "Jeffrey Zhao" <je...@live.com> wrote:
> "根据实际情况来判定"，这简直是一定的，呵呵。
>
> Jeffrey Zhao
>
> --------------------------------------------------
Kenny Yuan
坏的例子引导很多人陷入"仁 vs 智"之争
所以，请允许我再讨厌一次这个例子
P.S. 在6年前我混汽车论坛时，看到过有人讲过这个故事，当时就有几派吵得不可开交，同样是"仁 vs 智"之争
莫华枫
--
反者道之动，弱者道之用
m...@seaskysh.com
longsh...@gmail.com
http://blog.csdn.net/longshanks/
Hook
希望” 莫华枫”老兄将邮件客户端的设置调整一下
每次回帖子都直接跟在引文后，引文和回文混在一起了，阅读很困难。
From: pon...@googlegroups.com
[mailto:pon...@googlegroups.com] On Behalf Of 莫华枫
Sent: Wednesday, February 04, 2009 4:56 PM
To: pon...@googlegroups.com
Subject: [TopLanguage] Re: 学会透过现象看本质，即使现象有时候挺诡异
2009/2/4 Kenny Yuan <yuank...@gmail.com>
Sun Weitao
>
> 希望” 莫华枫”老兄将邮件客户端的设置调整一下
>
> 每次回帖子都直接跟在引文后，引文和回文混在一起了，阅读很困难。
>
因为从后往前读违反阅读习惯。
为什么很难读？
因为这样很难读。
为什么回帖子要放在引文后？
jrckkyy
最近看到一个汽车对冰淇淋过敏的小故事，转述如下：
某汽车公司收到投诉信，用户抱怨说他每晚都从家里开车去商店买冰淇淋。如果买的是香草冰淇淋，则回家时汽车就无法发动；如果买其它口味的冰淇淋，则汽车可以正常发动。天天如此。该用户怀疑这汽车是否对香草冰淇淋过敏。
汽车公司的头头觉得这太过诡异，不过还是派了一个工程师去该用户家调查原因。第一天，工程师和用户一起去买冰淇淋。在店里，工程师要求买香草口味，结果出来后，汽车果然不能发动。此后几天，工程师每次都和用户一起去买，每次都由工程师临时决定买什么口味。果不其然，凡是买了香草口味，汽车就无法发动；反之则可以。（由于是工程师临时决定购买的类型，可以排除用户搞恶作剧的可能）
这个工程师是一个理性的人，也不信神，当然不会相信汽车过敏这一说。但是他觉得有更深层的原因在起作用。此后，他每天晚上和该用户一起去买冰淇淋，每次他都详细记录往返的时间、途中踩油门和刹车次数、使用的汽油型号等各种信息。许多天后，他终于发现规律：凡是买香草口味的，在商店里面花的时间少（因为这个口味受欢迎，摆放的货架靠门口）。
于是问题就转化为：停车的时间短导致汽车不能正常发动。然后，工程师就轻易找到了原因（当停车时间太短，发动机依然很热而无法驱散气阻）。
这个故事给我们几个启发：
1、不要拒绝接受貌似很诡异、很离奇、很不可能的现象。我手下的很多程序员都曾经抱怨测试提交的某个bug太怪异，对这些bug不予承认。你想一想自己是否也有类似情况？
2、要善于从一些细节发现规律，从而查出问题的根源。如果你是这个工程师，你能否通过细致的观察而发现其中的规律？
----------------
编程随想的blog
http://program-think.blogspot.com
kuku
Jawley
2009/2/4 Kenny Yuan <yuank...@gmail.com>
- Show quoted text -
这种故事不是用来吵的，是用来悟的。如果一个人能够从中得到什么启示，那么就是有用的。否则，就不用去理它。
graham
post引起的争议，其实这两种习惯各有各的好处。一般都是入境随俗比较好，英文组中绝大多数是bottom post，中文则top
post居多。
2009/2/4 string <x.tos...@gmail.com>:
> LS，你应该要把你要写的东西放在前面才对。
> 下面才是引用的内容
>
> 2009/2/4 莫华枫 <longsh...@gmail.com>
>>
>>
>> 2009/2/4 Hook <hoo...@gmail.com>
zhusupe
> 希望” 莫华枫”老兄将邮件客户端的设置调整一下
>
> 每次回帖子都直接跟在引文后，引文和回文混在一起了，阅读很困难。
>
你的这种引文格式也很让人郁闷，标准的应该是加'>'的。这样邮件客户端就可以把引文和正文识别为不同的颜色，方便阅读。
Hook
2009/2/4 zhusupe <zhudo...@gmail.com>:
roc lee
>
> 说起来又是bottom post和top
> post引起的争议，其实这两种习惯各有各的好处。一般都是入境随俗比较好，英文组中绝大多数是bottom post，中文则top
> post居多。
Gmail 和 google group 默认的是 top post。但是我支持 bottom post。
大段的讨论 bottom post 看起来很舒服。回复放到上面很难让人知道哪句
话是对应哪个问题，以及这个问题的来龙去脉是什么、在这个问题上发生过
什么样的争论。因为不能把所有的相关邮件都一下子显示出来，所以参与讨
论的人在回复的时候保留必要的详细的引文。而且邮件很可能顺序错乱，对
比较热的话题，没有引文看起来就全乱了。对应的回复内容应该在引文的下
方 —— 至少符合我的阅读习惯 :)
简端的讨论 top post 看起来可能更舒服一点儿 —— 问题一目了然、邮件顺
序不混乱的话，引文反倒影响阅读。灌水式聊天大多数时候也适合top post，
不需要关心回复对应什么问题，只要回复的内容本身有意思就行了。要是有
针对性的进行讨论，我还是喜欢 bottom post + 必要引文。
似乎完全跑题了... 呵呵
sige pluto
我感觉可再现的bug，不难找，难搞的是那种来去无踪，时有时无的bug。最近项目里，有个很简单的ftp获取文件的模块，在两台机子上同时实施，一台
完全正常，一台有时好，有时就会磕磕巴巴，看log文件，取一个文件老是取2次才能取到文件。但有时候就会很好。网络环境互换，获取时间段调整，都没
用。在测试机上也一切OK。单纯只执行Ftp模块，也不行。不知道各位有什么建议么？Log文件奇怪的一点是，开始1分钟左右，是OK的，后面就要每个
文件去2次，第一次失败，取第二次成功。
edwin
大段的讨论 bottom post 看起来很舒服。回复放到上面很难让人知道哪句
话是对应哪个问题，以及这个问题的来龙去脉是什么、在这个问题上发生过
什么样的争论。因为不能把所有的相关邮件都一下子显示出来，所以参与讨
论的人在回复的时候保留必要的详细的引文。而且邮件很可能顺序错乱，对
比较热的话题，没有引文看起来就全乱了。对应的回复内容应该在引文的下
方 —— 至少符合我的阅读习惯 :)
简端的讨论 top post 看起来可能更舒服一点儿 —— 问题一目了然、邮件顺
序不混乱的话，引文反倒影响阅读。灌水式聊天大多数时候也适合top post，
不需要关心回复对应什么问题，只要回复的内容本身有意思就行了。要是有
针对性的进行讨论，我还是喜欢 bottom post + 必要引文。
似乎完全跑题了... 呵呵
跑题了，不过既然说到TP和BP的问题，那么我还想继续跑一下.
TP和BP都有各自的理由和优劣，难说哪个好哪个坏.
但是最重要的一点，无论是TP还是BP，发言者都需要组织和删除无关的引文.
否则无论用什么都是阅读者的痛苦.
想象一下如果所有人都引用了前一个发言的全文.
莫华枫
初七上班一早，我的同事就告诉我他的一个同学出车祸死了，而且很离奇。
此人年初一和朋友在南京路玩，6点多晚饭喝了小半瓶黄酒。然后逛了一会儿马路，9点多就回家了。10点多到家，和老婆一起看电视。不久，老婆带着孩子睡觉去了，留着他一个人看电视。到了半夜2点多，警察打来电话，说她家老公出车祸了。
车祸现场很骇人，是在上高架的匝道口上。匝道前面是个红绿灯，主车道在高架下。上高架需要穿过红绿灯，做一个S型转弯（也就是幅度比较大的变道，在上海高架底下开过车的应该清楚是怎么回事），然后进入匝道。按交警的说法，是他的车在匝道口的左侧擦了一下，然后冲到右侧的护栏，最后连番带滚地横着撞向隔离墩。残骸散了一地，车顶也掀掉，人当场死亡。
说诡异，因为车祸发生在12：30，在他老婆去睡觉直到出事的这段时间里，谁也不知道发生了什么。他为什么又开车出去？出去干什么？按交警的分析，事故主要原因是速度太快。（根据我开车的经验，没个100公里也不会撞成这样）。他为什么要开这么快呢？
我的感觉，如果只是一个普通原因的话，很有可能还是酒精。尽管他在出事之前5个小时喝的酒，喝的也不多，而且此人酒量也不小，但是我们还是不能小看酒精的力量。黄酒是出了名的后劲足。我以前的一个老师在东北呆过，喝白酒都没醉过，但让黄酒喝趴下了。经常过了一天酒劲还没过。而且，开车，特别是在高速的时候，容不得半点差池。有时反应慢上零点几秒，就能要人命。再加上是晚上，视线不好，反应慢。人的酒量也取决于身体状况和所吃的东西。
Kenny Yuan
我天朝的隔离墩是装水泥的（或者砂石，或者拆房子拆出来的建材废料）
--
Kenny Yuan
C++, UI, LISP, MMA, Psychology and Automobile.
BLOG: CS巴别塔(Computer Science Babel)
URL: http://blog.csdn.net/yuankaining/
Kenny Yuan
先说说什么是气阻（气锁）
对于发动机来说，气阴这个词是说进气道内的空气阻力。气阻过大时会影响混合气进入燃烧室，这时就形成了气锁。
不同温度下空气的体积是不同的，特别对于进气道这个温度变化范围很大的地方。正常的发动机温度是90度，但那是指发动机水套内的平均温度。经过滤清器的空气温度很低，所以很多车都将排气歧管和进气歧管设计在一起，形成一个热交换器（也有用水套的水进行加热的，在小循环温度足够时就可以加热了），用排气歧内的废气来加热混合气，混合器的温度上升，有利于气油的雾化，但同时也会造成空气的膨胀，导致氧气减少，造成不完全燃烧，甚至无法燃烧。说到进气歧管，附带说一下可变进气歧管。进气歧管越长，低速扭矩越大（因为气体分子的粘滞性），但是在高速时，长长的进气歧管却很难及时供给混合气，这时要求有较短的进气歧管。所以，现代发动机中才会有可变歧管的设计。为什么要说到进气歧管的问题呢？因为进气歧管的问题也是气阻造成的。（注意这里没有说可变正时/升程的进气门/排气门，俺比较讨厌本田作秀的VTEC）
以上一段说的不适用于直喷机，因为直喷机没有可燃混合气。
气阻（气锁）不一定是在进气道里形成的，油箱也会造成气阻。油箱基本是密闭的。油箱设计有通气道，在两种情况下会打开，一是大量汽油已被送向发动机，油箱内的压力减小，导致一个负压，进而影响低压油路内的气油流动，如果负压过大，就会造成气锁，使低压油路内的气油无法流动。所以，在油箱内压力小于一定数值时通气孔打开放入空气，补充气压。第二种情况是汽车受热，汽油在油箱内挥发，产生大量油蒸气，造成油箱内压力过大，此时要打开通气孔将汽油蒸气排入空气中。（所以，不要将你的车放在太阳下暴晒，气油会蒸发，最终跑光光的~~）
为什么高温启动会碰到气锁问题呢？理由简单得出奇，因为发动机经常是为了低温启动设计的。在极低的温度下启动是非常困难的，因为汽油蒸气在低温下很难形成，影响燃烧。所以在现代发动机的进气道内都设有陶瓷电阻用来预热混合气。这种电阻很有意思，在低温下它有一定阻值，会发热，但温度升高到几百度的时候其电阻值会变成无穷大，此时电路断路，不再加热进气道内的混合气。
既然发动机更多地设计成"偏向于低温启动"，那在高温的时候出现气阻影响启动也就是有可能发生的事情了。实际上，气阻是发动机设计的关键中的关键，压榨引擎的功率就是靠的是加大进气量，加大喷油量（这两项加起来也就是提高压缩比了），稀燃或不均匀喷油（它有一个名头巨响的缩写：FSI），减小进气阻力（如：正时/升程可变，可变进气歧管），减小排气阻力（如：正时/升程可变以减少排气门漏气），提高进气的温度，提高进气的压力（SUPERCHARGE或TURBO）……
（请数数在上面列举的条目中有多少次涉及了气阻问题）
说了这么多，你想到什么了没有？——气阻是这么基本、这么重要的东西，连我一介票友都能大喷特喷出这么多来，难道发动机的设计者竟然犯下了如何严重的错误？虽然Pontiac从来没出过让人称赞的好车，但它也是很普及的车型（在美国的租车行里很常见），会有这么严重的设计失误么？这个问题我没有答案，TX们可以自行判断。
在我看来，如果是因为气阻致使发动机无法在热机启动，应该属于个例，是需要维修的故障，这样的故障在维修工那里通过简单的check list就能重现，对于无法启动的故障，维修工是很熟悉的，比如查油路，查缸压，查喷油嘴，进进气道，查节气门开度（如果是化油器的还要查阻风门等），查冷车启动，查热车启动……哪怕是在维修水平极其低下的中国，4S店的半大小工也特别熟悉这一套东西。
几年前，这个故事在某汽车论坛出现过，当时也有人怀疑这个明显不对劲的故事出自《读者》一类的刊物，在网上没有能够查个所以然，所以当时拜托了两个汽车媒体的哥们儿找机会问问通用的HQ工程师，04年车展时我跟通用的HQ工程师聊天的时候还想起来这回事，特地问了问，结果得到的答案都是说不知道真假。
pongba
今天比较有闲，所以我来解析一下这个故事中技术问题
先说说什么是气阻（气锁）
对于发动机来说，气阴这个词是说进气道内的空气阻力。气阻过大时会影响混合气进入燃烧室，这时就形成了气锁。
--
刘未鹏(pongba)
Blog|C++的罗浮宫
http://blog.csdn.net/pongba
TopLanguage
http://groups.google.com/group/pongba