怪怪 | Nothing, Everything

没看到什么呀，就有两个招生广告。

2. 目标对我来说似乎也没有威慑力了，毫无紧迫感。

想要有紧迫感吗？想想人生短暂就可以了。

你是不是想在有生之年实现你的目标，达成你的一些想法？

那么想想你还有多长的时间？这个基本上是不能预测的，能的话就是往小了说是算命，往大了说就是预言了。这些都被定为了迷信，所以呢，不可信，就是说，你还是不知道你到底能活到多大的年纪。

那么可以用“时间有限”来形容，这个对于每个人都适合吧，对于我也是。

记得那篇文章里说过，bill 就是因为在大学的时候，他的一个好朋友（也是程序员）在一次怕雪山的时候遭遇雪崩，不幸遇难。由此感受到人生的短暂，所以才更加的努力。他现在的成就，有一部分原因就是由于当初有很强烈的紧迫感吧。

我要在四年内把我的想做的都做出来。

朋友，
文章不往首页上放了呢？
我们好像是从《抽象无处不在》开始认识的吧。
其实我一般是只看文章不看人的。
只有文章比较有特点，我才会注意作者。

@bmrxntfj
我说的是“热衷于言语” :)

语法糖， 就如你所说，不能以机器为标准， 不过我的想法是，在这里应该更虚一点， 连范式都不要考虑， 范式也是为了表达。 主要是目的是什么， 达成这种目的需要什么元素。

之所以对象是语法糖， 就在于实际上person.Speak()实际上就是Speak(person)，而通过接口隐藏实现去改变行为， 实际上就是选择一个不同的过程： QueryAMethodAndExecute(person, speak的标识)。

这种看法并不是以机器指令为依据， 而是以表达这个目的为依据。 最基本的，过程及其标识不是语法糖。 当要求和目的变多的时候， 情况就会变复杂。

我过去说的问题， 就在于比如上面例子里的“speak的标识”，流行语言中太过简陋， 它不应是语法糖级别的东西， 却被轻易对待甚至干脆忽视了。所以呢， 大言不惭的说， Anders虽然很明确的指出对象是语法糖， 恐怕还是没意识到对于表达来说，什么*不是*语法糖； 其它语言大师也有类似的模糊点。

这个我个人认为仍然要从本体论（哲学）、集合论（数学）上寻求答案，而不是总是基于现存流行语言的形态改良。

相对于“语法糖”， 还有一个词叫做“语法盐”，指的是一些不好的特征，让一件事变得更难做。 实际上我们可以简单的认为， oo的流行， 就好比炒菜， 结构化编程的盐多了或者其它佐料不够， 简单的想想就决定加糖，而没有从“这道菜到底需要什么佐料”去出发， 终于造成了“坏的变成了相对好的”； 类似一招鲜， 吃遍天的做法， 不是在解决任何问题时都是稳妥的。

主流不主流的就不好说了， 因为语言作为一个工具， 并非是有足够强的表达能力就马上成功， 但事物总是会往好的方向上发展， 无论快慢。 即便像你说的， 以oo为主线， 最后扩展到某一天， 正好做对了路子， 很可能就会发现， 这里面最不重要的特性， 就是oo了；因为oo的各种特性， 并没有弥补本来不充分的元素， 同时新加入的又难说是必要的...

本来不想针对oo来说了， 不过既然老兄又提到这个话题， 就再把我的想法表达一下，不见得可靠哦 :)

“对于语言的热衷”，多半会出现副作用，认为这个语言会成为主流，而没有考虑一些其他的因素，看了D，就会感觉，D会成为主流。但是不要忘了，那家伙在一个人搞，能搞过ms吗？再说ms也不示弱，现在前沿的语言ms都有涉猎，F#，DSL.在wiki里还看到了一种fuxi（国人开发）的语言，看起来跟D还相似。
弄来弄去，就感觉很浮躁。现在看起来光用那种都不行了，多范式语言是语言发展的方向。应该是于oo为主线，在这个基础上扩展其它范式中优秀的东西。

我觉得应该把oo把个精光，出去语言为它添加的那些东西。这个是我的困惑。

"delegate并没有把C#变成强大的函数式语言，恐怕在于类型系统的配合度还不够" ms可以想D那样做。

“语法糖”可不可以认为是一种简化的写法，但是它有一个范式的上下文，如果用机器码的标准，那所有的都是语法糖，如果把这个上下文限定在oo中，应该就能看出来了。

实践，说得对。

@丁学
这么早...

分得清楚分不清楚，我是这么看的： 以谁为标准。 有一个自己的理解是好事， 如果这些定义能被更广泛的接受， 那就是价值观输出了。不过说实话， 我不应该感兴趣后者。

障碍当然不是语法糖， 但认清出哪些元素是必要的或非必要的是很重要的一点。 当然，跟你说的后面这些内容相比， 又是小事情了。 妈的， 人就是一个以自己为敌的生物。

对于“语法糖”这样的概念，我认为没有必要去深究，哪些是哪些不是，如果界定……你能想象一堆没有标准没有定义的东西能够被分得清清楚楚吗？
在你的设计与实现中，语法糖并不会成为障碍，障碍应该来自于其他方面，甚至有可能只来源于你自身，比如是否有长时间的精力集中，是否能一直保持清醒等等

看得很郁闷……

同意……

老兄的东西就是天马行空，摸不着脑袋。

不过我每次到你这里都学到不少东西。

君子之交淡如水。
再次插入前10，这次比上次前进一位，哈哈。

俺认为像Joel此类人或许太关注他所在的软工领域了，而忽视了其他方面。

同意文中观点，检查和测试不一样，检查顶多也就是测试的冰山一角。

抛开 C# 的静态类型检查，因为它那运行时类型检测和可怜的类型推导(这还只是C# 3.0才有的功能)，来谈下相对更厉害的C++。

要想做到编译时测试，非常困难。静态编译型语言编译之后会完全丢失其类型信息，当然像 C# 这样的有VM的除外。编译器只能在词法分析阶段检测到类型，如果无类型，它该如何示警？如果无法检测，开发人员的痛苦要加倍了，呵呵。

C++的模板元编程倒有点编译时测试的味道。但是如果没有强类型，那么类型推导会十分困难，如果没有没有类型推导，几乎就没有什么大用处。

更重要的是，逻辑上的错误在编译时该如何测试？更何况，即使测试也不能完全消灭Bug。

此外，强类型带来的好处还有性能上的巨大提升。俺在使用D做模板元编程时，真是深有体会。

俺认为，有所取舍比追求完美更划算。追求完美的代价太高，所以任何软工都是各方取舍的结果。要是听信 Joel 胡侃，会着魔嘀。哈哈。

PS:怪怪兄的文章很有意思。但俺每次都没耐心仔细阅读，有时候思维跳跃的厉害，导致俺这个笨人思维连贯不起来。而且力求逻辑完美，这就好像代码中太多的条件判断淹没了核心算法，让阅读代码的人吃力。

@guaiguai
其实我以前也是这么想的。当时的评论也没有那么刻意。嗯，猜测真的会伤害感情，说明了就不会有那种误会，o(∩_∩)o... 咱都别猜了。
我是你这的常客。我现在基本都很少看首页。而是选了几个我比较感兴趣的。

@怪怪
小结一下下，有不对的地方请指正：
无论粒度是小（例如单元测试）还是大（例如功能测试）；无论是在编码前、编码中还是编码后；无论是机器检查还是人肉检查；无论是叫检查还是测试^_^，测试的目的都是确保程序的正确性。测试手段的好坏不外乎效果和成本两个指标。单就（时间）成本来说，
时间成本=发现Bug所花的时间+定位Bug并修正的时间
所以，
prove it确实是最高境界，这和疾病重在预防差不多。
编译器检查，发现Bug的时间就是编译时间（这个可长可短，不过应该比眼球检查和编写测试代码要快），由于目前编译器只能检查一些低级错误，所以定位和修正bug应该也很快。
单元测试，发现Bug的时间就是编写测试代码的时间。由于单元测试是一小步一小步走的，所以定位Bug并修正的时间的时间会比较短，这也是TDD的最大好处。
功能测试和系统测试，发现Bug的时间可长可短，关键看测试人员的水平和运气（据说有些操作系统的Bug过了几十年才被发现），定位和修正Bug的时间要比较长，而且很容易出现改了一个Bug出现十个Bug的情形。

综上，如果所有Bug都能预防或者被编译器检查出来，那就最好不过了。如果做不到，用单元测试是个不错的选择，可惜单元测试的覆盖率又达不到100%，所以最后的功能测试和系统测试还是少不了（不过留到这个阶段的bug越少越好）。

由此，可以看出单元测试确实填补了编译器检查和功能测试之间的空白，是个相当好的idea。但是在单元测试覆盖率不理想的现状下，要把编译器检查去掉，似乎有增加测试成本的可能（除非能把Bug都Prove了，如何做到这点是个值得琢磨的课题）。

互联网上接触人更容易， 所以交朋友也更难。

更精确的说是交到一个知心朋友更难，就像你从学校毕业后能找到一个真正的知心朋友一样，太难了，呵呵，不过似乎也没这个必要。

@小猪凯
对， 除了少数意外，这是开始的时候必须的。 不过在现实生活里容易的多， 说不准第一面就发现两人都喜欢喝花酒什么的， 这也是你说的共同语言。

可是在互联网上， 想一下子找出共同语言， 还是不太容易， 这是关键问题。 这倒是从侧面说明， 至少一部分人， 上网的目的还是相当明确的。

@怪怪
我是觉得想成为朋友至少要在某一个方面能找到共同语言,也就是在某方面能较为平等地对话.

@1-2-3
你说的情况5， 或者情况4的反面， 就落入了Knuth说的， 搞不清楚干了某事会取得什么效果的时候， 那测试是必然的。不过4要是一个外科手术式团队，就很难走向反面。

1和3是可以做到的， 而且不测试不代表不断言； 而且也不必太绝对， 习惯于不测试的人， 关键反而在于应该知道什么时候必须选用测试了，这有时会包括对目标复杂性和执行者能力的准确判断。

2呢， 就比较复杂了， 在这块我部分赞成迭代的做法， 毕竟迭代也是70～80年代就开始了的。 具体情况具体分析， 有些东西， 叫做原型比叫做测试更合适。

我倒不是对测试有什么意见， 只是总隐隐感觉， 有更好的方法（但我的感觉可能是错误的）； 当前可以使用的手段， 比如我说的不同表达方式配合检查方式可以覆盖的， 至少从正确性来讲， 就不需要测试参与了。

净室确实要基于眼球， 但是最高境界我认为还是Knuth说的， prove it； 可惜估计全世界真敢拍胸脯的没几个了。另外， 据McConnell援引的调查报告里， 都说明了无论哪种测试， 相比机器检查和人肉检查， 效果有限的多。

@bmrxntfj
不要理解的太冷酷， 这没啥好处； 关键是， 谁都想和牛人交流， 可牛人自己又不能变成交朋友机器。 不过有一种人， 能逐渐的跟很多人交到朋友， 而且靠这些朋友成就自己的事业； 他们除了交朋友， 就啥也不会啦。

这就是交朋友的牛人和高手， 说实话， 比干技术难....

@Marklee
@小猪凯
也不是， 看咱们现实生活里的朋友。 朋友发展到最后， 根本就不会再是你需要他什么， 他需要你什么， 能相互陪伴， 就非常好了。

互联网上接触人更容易， 所以交朋友也更难。真正搭上线， 再不同的人好歹都有一些共同点， 找到共同点， 发展成没有任何相互需要， 也只是时间问题。

--引用--------------------------------------------------
Marklee: 说的直白一点，就是你没啥利用价值的话，别人也不会跟你交朋友
--------------------------------------------------------
有句话是这么说的,跟臭棋篓子下棋,越下越臭. 狮子为什么要跟绵羊交朋友呢?朋友本来就应该是平等的关系,不然还叫朋友?

@怪怪
实在无法想象完全没有测试也能得到相当高的正确率。不知道“净室开发”具体要怎么做。不知道有没有审核代码的人呀？如果有检查代码的步骤，这也是一种测试，叫“眼球测试”，吼吼。当然按照老怪物的说法，检查代码是先知先觉，应该算作“检查”；后知后觉的才叫“测试”。就好象我拔出枪来对准某人，他要是在我扣动扳机前就吓死了，那我顶多算误伤；他要是在我扣动扳机后被打死了，那我就是谋杀。呵呵，开个玩笑轻松下。

如果真有这样的项目，那它至少要满足5个条件：
1. 程序员从来不犯编译器检查不出的低级错误，例如：“string s = null;s.ToString();”或者“int[] i = new int[] {}; int j = i[0];”。或者，做“眼球测试”的人足够认真，足够聪明，足够耐心。
2. 程序员对业务和详细设计书理解得非常透彻，绝对没有一点马虎的地方。
3. 程序员的编程能力非常强，只要得到明确的要求，就可以写出优质无错的算法。
4. 这个项目只有一个程序员；或者程序员之间没有任何协助和依赖；或者程序员之间的交流非常顺畅，绝对没有误会的时候。
5. 程序不依赖任何第三方框架、库、控件和运行环境；或者它依赖的任何第三方的东西都是0 Bug的，并且程序员对这些第三方的东西了若指掌，没有一点误会的地方。

说的直白一点，就是你没啥利用价值的话，别人也不会跟你交朋友

@guaiguai
明白

@bmrxntfj
这个问题， 我为你写了一个文章， 见这里：

http://www.cnblogs.com/guaiguai/archive/2008/07/18/1246033.html

其实我觉得这个大家应该讨论一下， 不过鉴于最近我比较不招人待见， 就不污染首页了。

@jjx
我比较烦的一点是， 他们说的并非完全没有道理， 这样反而看起来费劲， 对的错的全都得自己挑...

@狼Robot
呃...

@deerchao
如果最终达到1-2-3形容的那个做法， 确实是这样...

@1-2-3
是地， 另一个完全相反做法， 是在Template C++里面的， 甚至通过表达， 把物理量用静态的方式约束、 使用编译器检查。

我个人的习惯和你正好相反， 只有靠别的方法确实还不如来一次单元测试性价比高的时候，我才用逐渐偏向测试驱动。

这个问题前段时间有个文章， 说80年代的“净室开发”完全没有测试， 也能得到相当高的正确率。 当然TDD在软工方面的其它优点先撇开不谈。

@guaiguai
deerchao 也好这个。推荐下。
很羡慕你能交上laodai这样的朋友。

我没看过本文提到的这几位大牛的文章。从本文来理解似乎是：“静态检查是鸡肋，单元测试是银弹。只要把银弹用彻底了，鸡肋就可以不要。”是这个意思不？其实我非常喜欢TDD，它确实是个可以极大提高效率和正确性的漂亮的子弹，只是目前它的射程还不够远，将来啥时候能射得远一些也还是未知数。

关键是测试覆盖率的问题。如果覆盖率达到100%，那么自然可以在测试逻辑的同时顺便也把语法错误和类型错误顺便测试了。现状是难以编写有关UI和数据库访问相关的单元测试，而对于信息系统来说这两块占开发时间的大半。

单元测试的优点是可以一小步一小步地前进，这样就节省了大量定位错误的时间，同时因为对刚刚编写的代码还有印象，改起来也快。所以我在编写一些工具类的时候非常喜欢用TDD的方法。

附言：希望将来可以有更容易编写单元测试的方法。越早发现Bug效率越高。

那不等于用我们的人工去抢编译器的工作?

继续看不懂.

@李战
只要有额外的耗费， 就坚决不支持， 打到帝国主义 :P

我是能量最小化原则的忠实fans～

@ J
谢啦， 等下编辑一下。

对于高手而言,可以采取任何的方法,都无所谓



对于低手而言,就只有一种方法,也就是目前流行的方法



对于这些所谓的大牛的过分吹鼓, 我已经非常反感

@戏水
我个人目前的想法，都存在， 但情况是完全不同的。

可检查不可测试， 代表拥有所有条件，但测试代价可能无限高。

可测试不可检查， 代表存在未知条件。

另外， 检查和测试， 是一个实用性问题， 不是一个原则性问题。 其实我说的这些并非不实用的东西， 只是领域不同...

老子、和佛法的一部分思想， 必然导致回家种白菜的结果； 其实我个人坚信老庄的哲学， 不过我是XX分裂者， 在实际行动上采用的是西方那一套。

这一切都是为了发展动态语言而寻找的理论基础，俺支持“强测试”观点。

纠正一下，“Strong Typing vs. Strong Testing“是Bruce Eckel的文章。
http://www.mindview.net/WebLog/log-0025?PHPSESSID=f98dbda90e07f5dadde94eabd8583f32

《Joel谈优秀软件开发方法》只是周思博编者。对一些他认为好的文章做了个汇编，顺路评论一下而已。

看老怪的文章 常常看到类 Bob ， Knuth ，Fowler、Robert Martin 等牛的名字^_^

有如下疑问，请善知识们赐教
1 是否存在可检查而不可测试的
2 是否存在可测试而不可检查的

如果以上二者存在，那么是不是说 ，检查和测试并不是问题的根本性问题

小弟才疏学浅，也可能是受了点佛法思想的影响，我总觉的吧，本来世界上没什么大不了的，可人们总想这想那，于是为了解决这那的问题 就有了各种方法论，方法论层出不穷新问题新困难也层出不穷，犹如六道轮回，转个不停。有人告诫我们要拿得起放得下，可在软件设计开发这个没有yd的小盒内，我们拿什么放什么呢？也许回家种白菜才是解决问题的好方法

ps：貌似人生病的时候喜欢啰嗦。

@金色海洋（jyk）
啊？ 我变了？

@丁学
我这怎么不是技术文章啊...

@U2U
是内容没意思， 还是我写的不好呢？

文章看的好辛苦。。。

如果是技术文章，我凑合着能翻译，译不好，但至于能译
你这种，嘿嘿，等着大罗神仙降世吧

居然是怪怪的文章，一开始没看出来。

@deerchao
这个， 不好下论断吧..

C++该死在那些几角旮旯和没有垃圾回收...

最近cssplay的排名下去了， 我想需要考虑一个问题是欧美网民的情况是不是发生变化了？

我相信这样一个站， 应该不会作弊。

@装配脑袋
天天要求我严格化...，5555

而且我觉得你这个是个套， 强类型， 如果要求精确的下定义， 似乎还根本没有， 但一般好像， 认为如果一个操作对应着且仅对应着一个特定的类型，就认为这个语言是强类型的。

@装配脑袋
另外， 孟岩那天跟我说， 没几个人会愿意对着T写代码， 真的是这样吗？ 我怎么体会不到呢...，不过他对各种程序员应该是有广泛接触的。

@bmrxntfj
呵呵，我能力有限，还无法做到深入浅出， 就像脑袋说的， 这些东西自己试一试， 也许会比我说明白。 面向对象碰到静态强类型， 这缺陷是必然的， 而引入其它的范式是可以配合解决的， 这就是我拿出来说的意义， 而不是一味的鞭笞和哗众取宠。

占了一种好处， 就占不了另一种，这种看法也不是处处成立的。 首先具体到眼前的问题上， 很多人是有实践的。 其次， 这种说法， 其前提条件是很模糊的。 如果一个事情是10分，现在只做到3分， 那还不到说这个取舍的时候。 同时， 还是要看系统是封闭的，还是开放的。

@装配脑袋
你说的对， C++/CLI那种VM外加代码生成， 接口的兼容性就没了。 而且还有另一个方面： C++ Template式的源代码库， 比起动态库， 虽然写程序时灵活了， 在同一个平台上，和DLL相比却缺乏了运行时的灵活性。 所以我在使劲儿想， 到底怎么办好。

Ruby的问题， 就像你几年前跟别人说的， 我现在还认为， 运行前就知道的事情，还是写代码时和编译期就给做了好； 交给运行时， 然后正确性依赖于测试， 这个....

@只有博主才能看到
他要是清楚全部事实， 在恰当的时候评论，那么我是一点感觉也不会有的。 你要是仔细读了我的文章，就会知道事实跟他想的不一样， 所以他没有说明任何问题， 我也不完全是为了泄愤。 您这么说， 是在读我的文章之前， 对他和我， 在您内心中已经有一个选择了， 这很正常。 你想想dudu、 想想包建强、 想想编委会的其他人、想想顺着他话风继续下去的所有人。 还有整个事情的推进...

所有的你说的“旁观者”，所基于的假设是dudu、出版社、我们之间所谓的关系和矛盾； 可我们不同主体之间则根本没有发生任何事，只是编委会内部有点意见不同， 也缺乏一个商讨的过程， 结果这一点反而让出版社给抖落了出来（这说实话，有点可笑，也说明了我们做事的问题）。其实包包和出版社负责人的聊天记录中已经清楚的表明这一点了。

“现在是你们编委会和dudu之间的事，不希望“局外人”来掺和，那么这样可能你们永远解决不了问题。你们总是将问题纠结于谁付出了多少，谁不应该怎么样，什么情、义，太缺少理智。而现在精华集面临的是成为一本商业出版物这样现实的、需要“签合同”问题。 ”

这样的说法， 可能我写的太长， 你没仔细看， 我指的局外人是指不了解我们的组织结构、 发生了什么的人。 我也没强调谁付出了多少或者怎么怎么着， 我只是认为让“局外人”弄明白的最好方法， 是把我们编委会到底是干嘛的以及所有发生的事情说清楚。 签合同只是一个大的活动中一个有具体目的步骤， 我们也会解决好的。

人言可畏， 我过于激动， 你们可以认为我是被对问题做出的各种解释给吓着了。不过你说的对， 我澄清事实就完了， 不应该因为一时冲动， 就说出这些话。

说出去的话， 泼出去的水； 这就是我不成熟的一个证明， 留在这里吧。 我也给苏鹏兄弟道个谦。 毕竟，这些事情是先被我们团队内部的人抖落出去的， 而这个意外是因为对一些问题我们没能注意， 所以始作俑者不是别人。 我赖不着别人， 我现在冷静下来， 虽然无法挽回，仍然要对被我用语言伤害的同志说一声对不起。


@www.guyazi.com
“嘻嘻，我看其实就鸡毛那点事情”

是的，就是鸡毛那么点事情 :P

@横刀天笑
@clefoo
你们说的是， 至少我个人以后会谨慎的。

@xiaodi
版权问题是一定会处理好地。 另外， 虽然有个别人产生了奇怪的念头， 实际上整个编委会中所有其他人并不认为存在什么谁绕过谁的问题。

@*
这个问题已经水落石出啦， 而且也结束了， 这是最后一贴， 以后我不会再解释什么了。

看看首页都被污染成什么样了。。装清高的装清高，装另内的装另内。。大家都是男人，什么事解决不了，左一篇文章右一篇文章的，想看点好东西，也看不到。真是失望

p事也拿出来说，博客园真是不行了

其实有些事情都不需要拿到台面上来说，你们下线商量，尽量不要伤了和气该多好啊，希望大家都不要生气了，一起为社区兴旺而努力

呵呵，大家冷静点呀，看见的都是火星。
我相信我们中的很多人，能够坦然买对生死，却无法坦然面对不同意见。
妥协是必要的，特别是一个越来越民主的社会。或者说民主的本质就是妥协。
容忍别人也是必要的，在一个越来越自由和宽容的社会，以宽容的态度处理周围事情是更需要的。
嘻嘻，我看其实就鸡毛那点事情，，，，有人估计会骂我了。
大家争论，是因为在乎。
为什么会在乎，我个人的感觉就是这是一个比较成功的草根网站，调动了大家的主动性。
别人不了解，不理解，知情者可以公布的。透明也是社会发展的趋势。透明还有一个极大的好处，节约社会成本。
说远点，看看现在的西欧的国家体制，我觉得就是全球发展的方向。
我其实并不是知情者，但是我很同情包包和dudu。

扯远了，，