怪怪 | Nothing, Everything

原帖

 

回帖整理的目的是经常性的提醒自己那些已经想明白但做不好的，并在那些还比较模糊的问题上记录思想的轨迹的改变。

 

 

@辰

其实这样的话我也说过，不过现在反思，但是我不是站在多个名字的LZ这个角度。

 

毕竟， 前件为假，后件为真，命题为真。

问题是： 你这位大牛老师，n年后， 他相对别人也就属于早生几年的人了（前件），会不会有拿他的名字命名的用屁股想出来的算法？（后件）

前件为真， 后件为假， 那么命题就一定是假的了。

 

至于经验的传承，还是有很大必要的， 把泡沫过滤掉就好了。

@YITIAN Studio 还是 @千冰念 ？
几层意思， 都清楚啦？ :)

先解决生存问题， 然后处理好自己的欲望问题，最终，找到自己喜欢的就是最重要的。

其实中间这个过程才是大多数人都痛苦的， 两个选择：

1. 实现。 实现就要评估两方面， 结果和成本， 比如也许没有一个漂亮姑娘就寝食难安。

2. 打消。 打消是因为也许你发现其实你并不需要，比如BMW能给你的一切也许VW就够了。

     摘要: 无论未来会怎么样， 我坚信一点， 新的革命所带来的改变，要比瓦特发明蒸汽机到现在的一切改变加起来的总和还要多； 而且， 在我们有生之年， 就会看到它。问题就像是巴顿说的，那时候， 你、我， 还有我们现在折腾的一些所谓的“技术”， 我们在哪里？  阅读全文

呵呵， 谁知道我指的是什么？

 

总结： 这一年居然又是过度的一年： 了解和思考了一些对做事、 做软件真正核心的东西， 而且逐渐的可以开始用这些“虚”的东西， 来对照“实”的问题； 遗憾的是， 这些东西除了偶尔作为反潮流的后盾， 对我来说还远远不能用于实践。

 

这可以认为是它们的深度广度远超目前流行一些大框架（不是指Framework这种具体层次的）内的尝试， 也可以认为是我的能力还不足以把核心概念真正的化为己用； 可以认为是实现一套完整的东西工作量太大， 也可以认为是我太菜所以承担不起。

 

但是这一个过程， 是我万万没有想到的。 我怎么会走到今天这个样子？ 这条路还要走多远？ 我的选择正确吗？ 这些问题似乎总也不能摆脱，古人说30而立，以前去中关村，少则叫人家大姐， 多则叫大叔， 现在很多老板年纪比我还小了， 真是....

 

时间不多了。

 

说点别的。 这些天手机坏了，背灯不亮。 先去的西单Nokia客服， 直接说我LCD坏了； 因为觉得他们胡诌， 就去了维修摊子： 第一个， 修了两个星期， 把电路修断了一根， 毛病没解决； 第二个， 修了一星期， 屏蔽罩又少了一个。 最后送到中关村的一个Nokia客服，1个小时背灯就亮了，真是挺高兴的。

 

可是，断了的那根线路没修好， 就继续放在他那。 昨天他们快下班时，说好了， 我就急匆匆的赶过去， 发现屏幕多了些水印， 他们跟我说几天自己就好， 当时他们一堆人等着下班走人， 不好意思， 就交了钱。 后来仔细一看， 修好的那个断线的线路的摁键， 一摁， 就会串到若干个键上， 屏幕似乎也不是小问题。

 

今天再去， 不承认了， 非说像我这种问题（疑似进水， 我没承认过， 因为我似乎是因为充电器短路才弄坏了的）， 有水印很正常。 串线的问题， 也告诉我基本修不好，只能凑合用。 呃， 我的感受是， 再次体会了弱势群体的滋味。回来看了看手机线路图， 明白了， 他们飞线接电路时， 肯定把那根线给接地线上了， 这就造成， 表面上好了， 实际上根本走的不是原来的线路， 而是乱窜的信号误打误撞， 同时传到了两块控制电路的若干个角。他们还跟我说串线不是大问题， 确定是如何串线的确实不是大问题， 往地线上一接， 这事情可就说不好了。

 

说的再远点。 我混进几个手机维修论坛看了看， 也浏览了几个卖收费手机资料的网站， 我就一个操， 国外热心人放的资料， 全成稀罕东西了。 维修人员们粗心手糙也就算了， 获取信息和学习的能力也真是成问题。 也许就像别人说的， 电子产品， 属于那种坏了就要准备扔的， 交给维修人员， 无论是不是客服， 是好是更坏绝对都会变成一个概率问题。 不过， 仍然有一些经验可以说。

 

了解了一下， Nokia的客服分为1、2、3、4四个级别， Nokia规定，1、2级， 没有资格修核心部件出现问题的手机， 也绝对不许动电烙铁， 至少对于在保修的手机， 如果被1、2级给动了， 以后就别想保了。 对于不保修的， 很显然， Nokia不让他们动， 就是不放心， 千万不要贪图便宜个1/3，或者地理位置方便， 就轻易的把机子交给小的客服， 你给了他们， 动不动那是他们说了算的，多修一个多拿一份钱， Nokia也不可能把所有这些客服都管住， 事实上我认为它根本就不打算管。我不知道国内怎么分级， 但那种小型承包商承包的， 管它是几级也不能信。

 

至于大客服， 信口胡诌， 说实在的咱们也没办法， 可以换一家同样规模的再检测一下再说， 不过现在检测也开始收费了。 如果都胡诌， 那也最好就按他们胡诌的来， 能修好就得。 当然， 要是价格太贵， 我看就只当废朔料一块就好了。

 

最终， 我买了一个万用表， 一套改锥， 准备有空自己动手， 丰衣足食了， 毕竟咱也是干IT的。电烙铁没买， 因为我手太笨，如果需要处理BGA的焊接，又完全不可能准备工具； 这个活看看附近有没有手细的，同样属于弱势群体的维修工（NB的我是不敢指望了）， 让他们代劳吧。 妈的这都赖我自己， 不搞应用搞研究， 弄得手头紧， 不得不考虑修一下算了， 结果反而弄的窝窝囊囊。 如果过两天自己坏了， 或者让我折腾坏了， 最终还得买， 几百块的维修费就成了浪费不说， 更关键的是我宝贵的时间和心情。

 

再说一个怪事。 买了两条1G内存， 芯片不一样， 家里还有4条512， 两条现代， 两条三星。 换成1Gx2， 512Mx2，如果是两条相同品牌的512，居然过不了自检， 反而是一条533的现代， 一条667的三星， 配合这俩不同芯片的金士顿， 一点问题也没有， 真是彻底折服了。

 

最近流年不利， 我得小心点， 别再碰见什么乱七八糟的情况了。

 

Update:

突然发现，似乎我的音箱也要完蛋？ 我到底是怎么了....

 

http://vse.guangztr.edu.cn/radioschool/bga-cjx.htm

Update:

有一件事忘了写了，本来去中关村那天一冲动， 想买N78或者6220c的港行版， 正好原来在网上查到两个商家， 号称绝对是真的， 我就去看了； 差点买之前， 我女朋友建议到一个刚认识的卖配件的哥们那里上网再查一下，结论如下：

 

中关村绝对（意思是101%）没有卖真港行的，但是他们现在确实越做越真了。 比如过去说HKC的标， 假的中间缺少两个横线， 现在大的HKC假标签已经有了。 比如我看的第二家， 网上说的“Nokia Care”的标是应该有皱褶的， 他们也有了， 而且印刷相当强悍， 比真的做工还好； 港行的发票，过去网上说是针打的，他们现在也换针打了。

 

至于哪儿还不够细心， 这个我就不想多说了， 早说一天， 他们早改进一天。 建议大家看看淘宝上的香港人联诚阿井那里， 虽然我最后打消了买手机的念头，但是如果再买港行手机，已经认准他了；据说购买后香港那边商店活动赠送的礼品都不会少的。 如果在村里买， 就买亚太版的或者后港的， 确认配件是真的就可以了。 至于我说的这两家， 初步判断， 他们的配件应该是真的， 但是价格比亚太或后港贵300左右。

 

关键在于， 如果冲着全国联保去的， 我们就无法保证假Nokia Care和假发票客服永远不会仔细验证。 在Baidu上查询中关村保证百分之一百港行的，一共出来的就那两家在大型IT网站上的商家页面，弄这么真的北京没几家，也不容易（可惜做事的素质低点，行百里而半九十）， 具体名字我就不点了。

 

希望这些信息对大家有用。

原帖

 

Borland C++ 3.2? 只用过3.1， 还装过4.0和4.5，但没成功： 最初我家机器的4M内存有一位是坏的， 4.0以上的版本不能正常运行。

我最怀念的VB版本则是3.0~ 另外，自从Visual Studio出了1.5以后， 基本就没再碰过Borland的东西了～

虽然年纪可能比老兄小，我从那个时代过来，到今天也已经十几年了， 也不过是个初学者。 和老兄也许有所不同的是， 我当过一阵子张嘴某某方法论、 闭嘴框架式解决方案的人。

但是有一点我是很清楚的， 真正走过来、 回顾过去， 就发现， 95年之后东西， 与其说是给程序员准备的， 不如说给工程人员而且可能更多的是给*不合格*的工程人员准备的：

这是为了提高他们的效率，防止他们作出不恰当的事情。 真正的程序员的需求， 就不是大中小型商业组织和出版商最关心的事情了；当然这也是因为，好的程序员总能快速的自给自足。

变的其实不是真正的技术， 而是基于那些技术构造的工具； 而工具玩家当然也自有其乐趣。 最苦的就是两边不靠或都靠的人了，过去他们是第一代被争取的对象， 现在却被遗弃了。

我至今还记得， 十几年前的毛毛细雨中，一个人骑自行车十多公里去中关村带着特有异味的胡同中买盘的情形。 之所以每次都去其中一家， 很大程度上还因为那儿有一个漂亮的小姐姐....

现在那片平房先是被海龙、接着被一系列大楼占领了，而我唯一喜欢过的市场，海淀黄庄的中关村电子配套市场也不在了。

时代真是变了...

 

 

个人总结及多余的话：

 

近年来，对我最大的一个影响应该是加入博客园了。 我在这里学到了很多，这不代表我想说什么恭维的话； 恰恰相反， 在博客园，我真正得到的、思考的、加强的， 恰恰是我的一切不认同。 而我之所以偶尔被骂， 也不过是因为， 我自己也不过仅仅是一个不那么合格的工程人员， 却试图给自己带上*真正的*的程序员的帽子，还要不合时宜的传播自己未必正确的价值观。

 

想想我刚来的时候， 一副“理智使用面向对象”的丑恶脸孔， 到后来因为不轻信的个性，对一些国外方法论开始初步质疑； 到今天， 我脑子里开始有一些模模糊糊但真实的概念。 一言以蔽之， Strustroup、Anders，这些是真正的程序员， 而Fowler和其他一些明星则是好的工程人员； 前者的工程能力我无法了解； 但如果管后者叫程序员， 毫不客气的说， 是对程序员的侮辱。

 

这是我第一次如此极端的表达一直吞吞吐吐的观点。 又有几个真正的程序员会不了解， 比如对于类似“用测试也可以充分保证正确性”这样的可笑言论， 在30年前就被迪杰斯特拉轻描淡写的一番话，科学的、根本性的枪毙了。诚然，真正的程序员也必须向当前有限的手段妥协，而求助于工程上的解决之道； 但是他绝不会通过强调工程、人文的考虑， 在谬误上建立自己的阵地。

 

这看起来我还在执着于人与对错， 其实它表达的是，如何就我们面对的这些信息进行一个相对正交、且有一定严谨性的分类； 它同时还能指导我， 从不同种类的师傅那里，可以学到什么， 又应该小心什么。虽然我现在脑子中的部分结论还是支持我过去的一些臆测， 但其意义已经有所不同了。这个成长过程，固然和我浪费了大量时间取证有关，但起点却是从质疑引发的讨论。

 

从现在开始， 我希望这一切和我无关。  我个人必须、也绝对有能力去施行很多工程上的做法， 同时， 我也不会轻易的被蒙蔽双眼；和其它一些方法论支持者、反对者相比， 我也可以确信自己是经过更多的调查与反思的； 总而言之， 知道何时、采取什么样的策略是相对有益的， 以及初步学会探测风险所在，这足够了。 再继续下去，只能是深入论证， 那实际上是缺乏建设性的。

 

当然， 否定一个极端不代表走向另一个极端。 我个人一直对纯算法的练习持相当大的抵触情绪， 我自己很少进行这种训练，并认为那是不切实际的。 大多数算法都是为了解决实际问题而诞生的； 但无论是针对这些算法的练习， 还是发散练习，如果占据了太多的视线， 对于“掌握算法背后的思想”这一目的来说，恐怕是边际递减的； 最终不但不能算法大成， 甚至可能走向反面。

 

在博客园， 我就各种问题跟不同的朋友争论过多次， 也和一些其它兄弟待过同一个战壕， 这对我是一个非常难得的经历。可最终我却发现， 也许就像上次“纸毛巾”同志说的， 我和大多数人， 也许很大程度上都不是一个路子的。所以无论我对别人， 别人对我， 赞同也好反对也好，恐怕在根本上都是鸡同鸭讲； 这个结论让我有些失落， 恐怕也会让一些把我当朋友的人失望。

 

一个正确的态度是什么呢？ 我是来学习的。 很早我就说过， 曾经不屑于“深入XX”、“XX技巧”这些对手册二次消化的知识的我， 最终明白了， 如果没有这些资料的支持， 我个人也不可能在选择另一条路的同时， 可以快速的掌握任何一种工具的使用； 这实际上全是兄弟们的无私奉献。 而更广泛的， 对于一些我质疑的东西， 哪怕真是垃圾的，不用就是了， 又何必抱有抵触情绪呢？

总要有人把这些拿出来说， 我才能去判断好坏， 筛选出其中有利用价值的方法。 过去Allen Lee说，我的冲动来自于“权威”尤其是“伪权威”对独立思考的扼制， 不过从另一个方面来说， 别人认可流行文化不代表人家没有反抗的能力； 毕竟是另一条路上的人， 他们又能怎样呢？即使是对真相的漠视也自有其道理， 目的不同造成了选择的不同； 从人生的角度来说， 谁受了蛊惑还不一定呢。

 

也许我以后还会跳出去说些什么， 不过至少这一阶段， 已经结束了； 或者说我希望它结束。 该收收心了。

来源： 驱动之家

 

不知道是否有朋友观看过卡耐基梅隆大学的计算机科学、人机交互及设计教授兰迪·弗雷德里克·波许（Randy Frederick Pausch）著名的“最后一课”演讲并也为之感动，兰迪·波许教授已经于7月25日因胰腺癌在家中去世，终年47岁，在生命中的最后时刻妻子和三个孩子 始终陪伴在他身边。

 

2006年9月，兰迪·波许被诊断患有胰腺癌，尽管进行了手术和化疗，他还是在2007年8月被告知癌细胞已经转移至肝臟及脾脏，至多可以再生活6个月。

 

美国很多高校在资深教授退休前都会为他们安排讲授一堂面向全校学生的“最后一课”，表达学校师生对其的崇敬和感激，让教授为自己的教学生涯划上一个 完美的句号。卡内基梅隆大学将其命名为“旅程（Journey）”，希望演讲者能和听众一起分享自己的个人或学术旅程。波许虽然还没有准备退休，但是鉴于 他的病情，他在2007年9月18日做了题为：“真正实现你的童年梦想”的最后一课演讲。

 

在演讲中，兰迪·波许教授告诉观众永远不要放弃梦想，当面对困难时他说“但请记住，阻挡你的障碍必定有其原因！这道墙并不是为了阻止我们，这道墙让我们有机会展现自己有多想达到这目标。这道墙是为了阻止那些不够渴望的人，它们是为了阻挡那些不够热爱的人而存在。”

 

以下是这段演讲的Google视频：video.google.com/videoplay，更清晰的带中文字幕的视频文件可以在：www.verycd.com/topics/267576/下载。

 

 

 

http://space.itpub.net/14674535/

 

这个系列的文章深入浅出，表达能力不是一般的强。

 

我的感受呢？ 如我这样关注这些话题已经有一段时间的人来说，主要是找不到新意和铺垫稍多； 但即使是这样， 我仍然得到了一次难得的重新捋一遍记忆和思路的机会；同时，在表达能力上的差距也给我上了一课： 不仅仅是写文章， 我们思考时， 第一个接受表达的对象就是我们自己。

 

强烈的表达一下我的推荐， 多的就不说了。

 

update:

Microsoft Visual Studio China Middle School Power Toy 1.0

 

 这个东西似乎给中学水平的人启蒙不错，现在的小孩真幸福。

除了对我现在做的事情有直接作用的书，外加一本数学玩物，一本YY读物，还有三本算法： 这个选择主要是因为《算法导论》，说实话， 无聊到一定地步了； 我想看的是大脑的活动， 而不是使用手册，手册虽然是必需品，但是读书讲究的不是这些。

 

书名

[41119]  P2P网络技术原理与C++开发案例

[38253]  编程语言:原理与范型(第2版)

[26775]  算法引论：一种创造性方法

[34357]  算法设计

[967596]  ACM图灵奖-计算机发展史的缩影(1966-2006)(第三版)

[18133]  深入理解计算机系统（修订版）

[178655]  怎样解题:数学思维的新方法

[9508]  如何求解问题——现代启发式方法

 

简要说明：

 

41119可以肯定是一本没什么太大价值的书， 作为一个纵观的了解， 省得费劲查些最简单的东西了；或者说， 查之前也会对过去的发展形势有个了解。

 

38253是脑袋的推荐， 我个人认为它对我的意义是速成： 了解该了解的， 防止在已经最成熟的问题上自己走弯路，或者干脆做了民科的工作。 这本书脑袋说翻译的极差， 已经退掉了。 另外，选则替代品的过程中，注意到了《程序设计语言原理(原书第8版) 》和《程序设计语言理论基础》，前者和脑袋38253有比较大的交集，作为所谓的“经典”，也很全面； 但是考虑到我自己的具体需求， 还是收了后者，可惜是本老书，新的进展不知从哪里可以看到。

 

26775的作者似乎现在是Google的首席算法师， 实际上这书我本来不打算买， 不过也不多这么一本啦。看在后面有些并行算法的份上，外加号称归纳证明和设计实现并进，看看有无新意吧。

 

34357在有些人的心里和《算法导论》齐名， 据说有一些启发式的作用， 又不是《算法导论》所擅长的枯燥罗列； 那就买一本试试咯，万一真能让我把一些东西读进心里去，那就真是大收获了。

 

967596没有什么说的， 纯属追星， 在此之外，则是用来培养自己的感觉， 感觉有时候是相当重要的； 本来想一起收的还有一本《来自圣经的证明》，不过考虑到数学和英文的复杂性一交叉， 我就玩完了， 算了吧。

 

18133估计意思不大。 但是看目录是一本非常全面的书， 对我辈软件人员， 该了解的东西， 找一本类似的书放在手边，没事瞎翻翻， 还是必要的； 既不过， 又不会不及： 更艰深的虽然不是说一定没有必要， 但要考虑到自己平时会不会打开。

 

178655既然那么多人说不错， 只当玩一玩吧。 其实不客气地说，个人认为大多数玩这些的软件人员都误入歧途了；不过我不会，我天生对数学具有高强的自我防御免疫系统 :P。

 

9508从目录上看，又是一个不是从具体算法如何做的层次关注这个方面的书； 希望作者的功力真能够对我这种白痴级读者作出一个好的引导。

 

最后多说两句。

 

我不认为这些书有什么了不起，任何一个想干30年技术而且能吃饱饭的，甚至想真正能从技术角度做好管理工作的，都应该看这些书， 而且一定能看懂。 Gates是一个“应该”的例子，M$的初期发展过程中，他作为技术决策者和管理者，虽然已经不再亲历亲为，可他不但知道一个软件该怎么做，而且知道实现一个功能，其难度和代价如何。

 

我自己是一个“能行”例子， 我曾经认为自己是计算机科学核心领域上的窝囊废， 最多搞搞工程和应用；但最终还是启蒙了，开始能看懂一些原来觉得是天书似的的东西了。我相信上面的书对我来说肯定还有很多“天书”成份， 但是我同样相信这些只是入门的浅薄学问，总是可以逐渐掌握。可能有人问了， 等你入门了， 啥时候才能有造诣啊？

 

我的一个体会是， 一旦跨过一道坎， 那简直就是天空任鸟飞， 海阔凭鱼跃； 等到真的修行看个人的时候，就不会有什么太大障碍了：一切唯实践尔。至于造诣，它虽然和天份不同， 但仍然是一个人自己得天独厚的东西；往往在我们完全没有接触过将会有造诣的领域之前，这个领域的造诣就具有了，所以根本不必担心：

 

关键是你是否挖掘了它。

过去两到三个月，一些总结是有的， 但很难说有很大进步，这是不得不意识到的。

 

从状态上来说：

1. 基本放弃了自我管理。

 

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

 

3. 不能说毫无意义， 但确实一点也不充实。

 

从技术上来说：

 

1. 除了少数想法算一些整理， 没有悟到更多东西。

 

2. 一些地方反而过于热衷于言语， 而放弃了本质。

 

比如关于面向对象和其它范式的语言； 最早我就明白Anders说的“对象说到底不也是语法糖吗？”、“delegate就是函数式的全部了”， 但是实际上在这方面的思考并没有新的进展， 也包括对泛型、模板、元编程的体会上，还差那么一点点。

 

而对于“语法糖”这个概念， 不要光停留在表面理解， 类似于面向对象的非本质性， 对我个人来说，已经无需再讨论。相反，delegate并没有把C#变成强大的函数式语言，恐怕在于类型系统的配合度还不够，所以delegate在C#中就很容易表现的像个语法糖。作为具体的议题，后者是一个还存在模糊的地方，而我缺乏深思。

 

关键在于， 哪些东西不是语法糖； 这个地方我没有好好的把握住。 抓住这一点， 在设计和实现时就不会被迷花了眼， 在语言的学习和设想上， 也能更加的击中要害。 再重复一遍，哪些东西不是语法糖？界限在哪里？

 

实际的产品开发，也要重新进入轨道。最近缺乏实践的带动， 而在此之前， 对Web框架的理解，对各种编程范式的理解， 从经验上来说，都是被实践带动的。所以重新回到根本，即便对于高一层次的研究， 也是必要的了。

基础资料：

 

用来增加背景知识的资料：

 Why Gnutella Can't Scale. No, Really. 

（待更新）

 

可能需要了解的资料：

 

非结构化：

“Mobile Agent based Method”，这个想法初步感觉有点爽，和我的想法有相似性，找点文章来看。

 

“Cache Method”的当前样例中， 有啥有新意的细节可以挖掘没有？

 

结构化：

（待更新）

 

实用资料：

 (待更新，这部分恐怕比较难找，可能还是得看代码。)

 

初步的想法， 实际上P2P网络的问题， 可以集中于两点：

 

1. 检索。

 

2. 有效。

 

关于1， 结构化的方法， 一般都是将内容与某一节点做一个映射， 信息提供者向这个节点汇报， 而信息查询者从这个节点获取。 同时， 这个节点的存在和同一，是通过“我们处于同一世界（物理上、时间刻度上）”这一事实来保证的。 除了实现细节的各种调整与优化之外，是不是真的没有改进的余地了？或者说，除了上述事实， 还有什么其它可利用的条件呢？

 

关于2， 分布式计算看似高端，其实反而可以含糊，因为只要不涉及远端计算机提供信息， 尚可以本地计算， 最终对一个可分解的计算来说， 仅仅是计算时间的问题； 信息传输要求稍微高一点，因为只要损失超过一定程度， 整个信息就是无用的； 而连续性播放则是比较难，但目前可以通过特殊处理解决。当这几者混合应用时， 问题可能会变得更加复杂一些： 多个部分的不同安排，可能导致可靠性在时间上的变化。

交朋友这个事情是这样的， 咱们自己确实得努力， 否则有点水平的就不会倾向于和咱们建立关系。 不是别人骄傲， 而是如果交一大堆朋友， 用于交流的时间又有限， 到时候反而不知如何处理，得罪哪一个也行不是。

过去我玩Q3， 如果我在服务器里打的表现不错， 很多就要加我； 开始我是不会拒绝的， 但是QQ上人多到一定地步， 我开始没法弄； 最后即使我加了别人， 也不代表我会和他说话， 因为我必须隐身而且装的跟真的不在似的， 否则就别干别的了。但是我也有类似于全国前三那样的朋友， 为什么呢？ 虽然我打不过他， 但是我有一些特色， 再练习中能够帮助他们提高。 这个开始我也不懂， 后来其中一人写文章和聊天时提到，我是他提高的三个阶段的最后一块踏脚石， 比如我的身法非常好，我才逐渐明白。

交朋友还有一些其他学问， 比如有一些人， 他即使不认识你， 你也可以把他当朋友。 比如对于我来说，这些人就是像Martin Fowler这一批。 当你把他们当作对话的对象， 你自然会提升的很快。 基本上， 在自己感兴趣的领域， 挑这么几个朋友， 所有你感兴趣的话题， 你都可以和他交流一阵子，Email吗？ 不是， 就是很简单的他写过什么文章， 说过什么我怎么想； 我有什么看法，在同样的问题上， 他又怎么看。 在水平还比较初级的时候， 这种交流可以持续很长时间而且够用；真正的朋友能起的作用不也就是这些吗？

但是不要把那些真正高山仰止的人物当朋友， 因为说实在的， 没到一个级别， 根本无法做出这种交流。如果硬要上， 这样完全单方面的信息流， 会整个的毁了我们， 最后让我们彻底成为他的手下败将： 没有自己的想法， 只知道重复。 当然， 也许Fowler是我的朋友， 但还不是你的。 也许Anders已经是你的朋友了， 但还不是我的。 这完全取决于一个人和“目标朋友”的相对差距； 对这种人， 我们要承认他们是你我绝对意义上的老师， 但永远不要忘记一句话， 吾爱吾师， 但吾更爱真理。 总有一天， 老师变成了朋友， 虽然这不代表我们到了他那个级别， 但也有所小成了。

配合上面的“虚交”， 得到一些提高以后， 获得一些真正有联系的朋友， 也就是很快的事情。 因为人家会发现， 对他感兴趣的领域， 哪怕你还不是太够格， 但是也有一些自己的理解。 这样这些真朋友， 会愿意传授给我们他们的东西， 以期我们进步的更快一些， 也能回报给他们一些信息； 甚至我们暂时还不能给出回报也是有益的： 当他给你开讲的时候， 他也就获得了一次整理自己思路的机会。 但是， 绝对没人会愿意给一个完全不入门的人讲上好几个小时， 除非他打算去学校当个老师。

记住，最好的朋友是实力比我们高出一截， 但不至于太离谱的； 这包括真朋友和YY出来的朋友。前者一般是在一个数量级以内的，否则有联系方式也没用；后者的水平可以和你差距一个半数量级， 但不能更多了。在这之外， 交水平比自己低的朋友也是有益的， 标准基本上就是把上面的反过来； 但这一般是下意识就能做出的判断， 就不多说了。

     摘要: 这是Joel的观点， 据说， Bob大叔也是这个观点。 他们认为编译器的检查， 实际上就是编译期的测试。 而且他俩， 据说都达到了“测试成瘾”的境界。这就是说，他们抛弃过去对检查、尤其是静态检查的信仰。

Joel本人也曾一天到晚的思考， 是不是有一个最佳的方法，可以尽量少的付出代价， 尽量多的得到不同做法的优点； 不过他、Fowler、Robert Martin， 似乎已经都放弃了， 他们放弃的对吗？  阅读全文

想了想， 还真不知道拿什么题目起头。 这样， 从以前的文章开始好了。

为什么OO是有本质缺陷的？

这篇文章中的疑问首先有这么一点： 静态语言中，我们如何能在改变一个系统内部接口的时候（注意， 不是对外发布的， 所以没有不能更改的问题）， 只更改一处就解决问题？ 比如最简单的， 一个类， 有Name属性， 是string的， 它对应某一个数据文件里的类似于表中一列的信息。 改变数据文件的结构，新添加了一个叫做Description的记录信息， 一个内部实体也增加了这个属性，我如何做到不修改从数据文件中读取， 和写入数据文件的代码呢？

毕竟， 这两个属性对这个数据文件的读写， 是没有什么差别的。举一个对比的例子， 在C++中， 我可以这样：

使用时，我们这样使用：


事实上， 这是使用fusion，稍微更改一下形式， 就可以变成这样： a_person.p<name>, a_person.p<age>。如果碰见变化， 修改一下typedef即可。 而我操作person的代码，只要其本身的逻辑没有变化，就可以做到一字不改； 因为我可以通过获取map中所包含的类型定义携带的信息， 直接写一个统一化的过程， 进行所有操作。 而如果使用OO， 第一个可以想象的就是， 每一个倒腾数据的逻辑， 无论是从哪儿到哪儿， 我都得加上对该属性的操作。

这个最大的好处是，只要在本质上是相同的过程， 我们只用写一遍。 另一个好处是， 我们同时具有静态语言的全部优势： 比如没有定义和包含description的时候， 无论你是at_key<description>，还是a_person.p<description>，根本就不会通过， 这样在非常大量的这种工作， 比起Dictionary和动态语言， 我们就可以避免大量的失误。

我想， 这个问题不能简单的用“很少有人用”来回答，因为它是结果。 首先它是方便的，而且方法名、属性名这种给人使用的死标记没有的缺陷它也没有。  那么我认为，没人用更多的仅仅是因为， C++和另外那些支持这种非OO范式的静态语言，其它地方太烂，是首先否定了语言上的选择， 所以也就没人在实体上使用这种设计和实现的方式。

当然使用Dictionary就痛快多了， 不过强类型带来的保障没了，这是不是缺陷呢？还可以使用反射完成相同的功能， 然后付出性能， 在我看来，这个性能就是缺陷的证明； 比如： 数据源是数据库， 那么有的ORM就用反射完成类似的工作， 但ORM的存在，反而证明了需求的存在。而且在ORM覆盖范围以外的数据复制和转移呢？ 性能问题， 我们可以通过Emit来解决， 但Emit不是适合于所有使用情景； 而且， 我们就必须编写和调试大量的Emit代码， 额外的设施的使用和多付出的工作量， 也是缺陷的证明之一。

毕竟， 这些信息本来就是运行前已知的， 而且他们是有规律的， 也就是可以通过某种形式在运行前处理的， 同时可以通过合理表达自动化的。某人嘴里的“孟老头”对这个事情有他自己的理解， 现在就看某人的啦： 这是不是OO的缺陷？

     摘要: 现在我们所有人， 包括dudu、编委会成员、 出版社提供参考意见的同仁、 广大园子里的朋友， 首先要确定的一件事就是， 这些书应该是什么形式的？ 也许甚至不同的分册不同的形式， 一切从实际出发。

除此之外，再无其它和人相关的冲突和矛盾。 再有人就这次具体事件， 针对某一个人或者牵扯进来的其它主体， 那就是找抽了。  阅读全文

     摘要: 写程序、做设计是一个边学边干的活计，有一个著名的调侃， 就是如果程序员盖的房子， 你敢住吗？

广泛的掌握面向对象的手法， 但不要因为自己学了什么就给自己下套子， 那和屁股决定脑袋差不多。 学的这些东西是备用的， 大环境让我们必然能够用得上。 与此同时， 根据需求出发， 当自己有强烈的感觉， 某个学习过的东西， 能够解决当下的问题时， 再去试着应用。有的剑， 出鞘越少越好。

散文一篇， 不喜勿进。  阅读全文

已经不知道多少次掉进这个坑了....，一段时间不用就忘， 每次都得耽误半个小时。 这一方面说明， 这个功能的文档配合的不够好； 另一方面，真应了那句话，好记星不如烂笔头。

这就是： 资源文件， 如果放到目录里， 编译以后会被加上目录名....，这其实是必然的： 否则不同目录的同名文件如何处理？写到这，又推翻记性或者笔头的用处了。 因为这个事情太简单， 我反而没有琢磨这么基本的一个道理， 导致不能够在“哟？怎么回事”以后马上判断出是什么情况。不过这事也难说，也许我已经按这个思路想过， 不过还是没记住。 所以还是应该有做笔记的习惯。

顺便说点其它的。 Tag和Category这两个东西， 按理说本质差不多， 但这是一个朝三暮四的故事。 关键是你鼓励用户怎么做。

很多人认为Tag是随意的、即兴的，所以是私人的。 其实正好相反。 Tag其形式鼓励用户随便填写几个相关的短词，结果正是因为这样， 反而造成了不同的人写下的词可能是共同的， 于是这就变成了一个社区的、公开的、交流的、 把人和人、内容和内容相关到一起的公众的东西。仔细观察互联网用户，就会发现， 那些更加懂得如何*在互联网上*交流的同志， 会更多的用Tag，而且用的很准； 而比较嫩或者比较老的网民， 就会瞎写或者不写； 但即使瞎写， 也能增进和其它内容制造源的联系。

而Category鼓励用户仔细的去设置分类， 所以反而会突出人的个性。 比如同样对旅游这一件事，对A意味着很多内容， 对B也意味着很多内容， 哪怕这些内容大部分是重叠的， 仍然会因为不同的部分， 产生不同的Category表示方式， 结果这就成了两个分类。 而整个社区如果设置了分类，也仅仅是从网站出发，属于网站的个性为网站本身服务。假设一个网站有三种分类方式： 个人Category、全站Category、Tag， 这看起来完美， 但是会让用户最后哪个都不填， 因为太麻烦了。

当然， 真正实现Category和Tag的时候， 可以让它们产生极大的不同， 但即便是设计者， 实际上也是以“如何给用户一个导向”为导向的。 如果Tag本身能够组织， 形成图， 其实是一个非常有意义的事情， 不仅仅是相关性， 而是各种可能的关系都可以形成组织。 Category本身也可以极其强大， 而不仅仅是树状的模式。

实际上，一般的设计者区分两者的手段， 就是根据预期的导向，让其中之一在某些方面较弱， 而另一个在其它的方面较弱。 如果两个都强大到极端， 那么可以肯定功能是相似的。 但真正想清楚这些问题， 就会发现没有必要通过故意的功能性差异化去在系统内部作出区分。

只是在这个“两个都达到最强”的状态（或者可能是干脆基于一套内部模型的状态），反而要加倍注意用户导向的问题，这个时候可以通过界面、提示、交互方式等表面的东西来做出区分。 否则用户将会觉得迷惑和繁琐， 以至于放弃这些功能， 这对社区的组织者和内容发布者，都是一个损失。

还有点其它的本来想写， 不过还是别浪费时间了。 STOP。

有空了解一下OWL，看看是不是能给我的一些想法新的启发。初步的看， 似乎有点掺杂着一些不纯洁的概念。不过，Ontology的概念还是很明确的：

引用

本體論譯自英文ontology，又譯存在論或是論，它是形上學的一個基本分支，英語詞ontology是來源於希臘語單詞ον（存在）和λ?γο?（學問）的組合。ontology主要探討存在的本身，即一切現實事物的基本特徵。

有的哲學家，如柏拉圖學派認為：任何一個名詞都對應著一個實際存在；另外一些哲學家則主張有一些名詞並不代表存在的實體，而只代表一種集合的概念，包括事 物或事件，也有抽象的，由人類思維產生的事物。例如「社團」就代表一群具有同一性質的人組成的集合；「幾何」就代表一種特殊知識的集合等。

ontology就是「研究到底哪些名詞代表真實的存在實體，哪些名詞只是代表一種概念」。所以ontology成為某些哲學分支的基礎。近年來，人工智 慧及資訊技術相關領域的學者也開始將本體論的觀念用在知識表達上，即藉由本體論中的基本元素：概念及概念間的關連，作為描述真實世界的知識模型。針對此一趨勢，W3C組織也開始定義了許多Ontology的相關語言，如RDF、DAML+OIL、OWL等。

为了统一性， 如果实现一门用于描述的语言， 可以忽略一个名词都对应一个实际存在这一分支， 而是加入一层， 认为每一个名词都对应满足一组条件的集合。 这样就和面向对象彻底分道扬镳了： 类也好什么也好， 只是一个方便我们组织和使用的别名， 没有更多的意义； 而每一个实体都是被用各种特征织起来的。 同时，面向对象中接口这样的鸡肋概念也可以去除， 而只检测一个实体是否满足条件。 这样， 静态语言的检查可以得以保留， 同时还可以延伸出自动推导等更高级的组织方式。

这也是我目前和脑袋的分歧所在， 脑袋更看重可行性， 认为借助CLR和保证与CLR上其它语言的兼容是必要的做法； 鉴于底层模型和其它语言接口要求的限制，这样就没有办法实现类似于C++模板的功能。 而我虽然更菜一些， 但是反而更“不切实际”，希望在这上面有所突破。 到底应该如何选择呢？ 有没有变通的做法呢？

---

另外，早期和我有交流的， 还有我那失败团队里的家伙们应该知道，其实我的Web框架本身、框架想要支持的产品和当初我设计的商业模式， 基本上和后来从FaceBook开始的这一大堆平台战略相类似。 现在说啥都没劲了。 我需要考虑的一个问题是，到底是因为我进度慢， 还是这个事情， 小团队根本做不了？ 说实话， 我不太相信后者； 我自己的分析是我的自我管理能力和执行力还需要锻炼， 对集中式应用缺乏应有的信念、对如何进入市场心存疑虑。

另一个具体的延误是，在Web框架到产品这一层， 对界面组装的灵活性和行为划分的严格性要求太高，而我一直没找到让我心满意足的设定，导致一直迟疑不决。从DNN到Weebly到现在的这帮家伙，人家更 NB的组织都知道先弄个能转的东西放出去再说， 我是不是太机械和2B了？ 这个地方我很确定不是因为自己的技术无法支撑， 所以应该集中反思产品策略问题，“黄金圣斗士不会被同一招数击中两次”， 我想我需要谨慎的思考。当然，也不能一概否定： 如果不是这种性格， 我也不可能不断的获得很多思考和提高； 所以主要是，在哪儿较真， 较多少真的问题。

---

我到底是不是一个真正的技术人？

我想成为一个顶尖的技术人， 但：

1.这个想法， 是真实的吗？

2.我相当的能说废话， 一个说废话的人， 其性格适合做一个技术人吗？

3.我没有专精， 而是每一个接触的方面， 都达到比第一流差的那个水平， 这是一个好事还是坏事？

希望跟我有接触的朋友们， 帮我观察一下， 并提出建议， 越难听越好。

     摘要: 作为技术人员， 我要把这本非技术的书， 放到SICP之前；作为德鲁克的崇拜者，我要把这本书放在《卓有成效的管理者》之前来；作为佛洛伊德、荣格的初步接触者，我要把这本书放在《梦的解析》、《现代灵魂的自我拯救》之前；作为巴尔扎克、陀思妥耶夫斯基的忠实读者， 我要把这本书放在他俩的一切作品之前；我甚至会把这本书放到老庄之前： 是的，这只是一本相当业余的小书，不乏一些不求甚解的成分，甚至也稍嫌肤浅且有点八卦； 但凡是围绕人的著作，没有一本对于一个像我这样的平凡人而言， 更加有实用价值了。 作为一篇全是八卦的博客， 我认为我有责任作为这本小书的枪手，把它推到首页，只希望其它人也能分享这份喜悦。 也许它并非完全和技术圈子是无关的： 很多兄弟对从业的感受和迷惑， 说不准能从这本书中找到答案。 这本书的名字叫做《遇见未知的自己》。  阅读全文

http://en.wikipedia.org/wiki/Comparison_of_BitTorrent_software

http://en.wikipedia.org/wiki/Comparison_of_eDonkey_software

最近的一些感受。

首先，deerchao说的是对的， Community Server 2008要比2.1强太多了， 当然， 对于我来说还是不够好； 不过， 既然我自己没有能力拿出一个若干万行、并且好多人都在用的产品， 我就别他妈的JJWW了。 这件事的一个想法是： 有谁愿意提炼和修改Community Server 2008的，我愿意参与，我的想法是：

1.继续精简和重构。
2.改进对中文的支持。
3.重新开源之。

为了目标1和3，一些代码不妨重写。 这样的产品， 难说什么专利， 只要重构的程度跨过某一水平线， 版权不是什么问题。

第二件事， 我为了试一个软件是否存在时间过期， 调整了系统时间， 重启前也忘了改回来； 结果Windows 2008让我激活， 在这里提醒一下那些像我一样靠240天评估期使用非盗版Windows的同志。

第三件事， 重装的时候， 忘记旧软件应该先装， 比如Sql Server 2005应该在Visual Studio 2008之前。 有时候一些最简单的事情也会犯错， 所以细心和把细心的结果形成习惯，还是必要的。另外， 了解了一下Installer安装组件和Hotfix的思路， 发现一些问题还真是难处理；初步感觉，其实我们自己设计真正的软件时，也可能会碰见类似的问题，看看能不能沉淀一下，变成可以触发的联想的知识和经验。

第四件事， 我决心调整重点， 把Web框架作为次要工作了，我现在就必须开始P2P的研究。 从06年年底开始到现在， 一直没进入真正的产品阶段， 我想这绝不光光是因为我懒， 而是存在深层次的问题。 分布式、非集中的网络，才是我的信仰；我是不是真的愿意做Web框架，还是因为从事过一些Web开发就习惯性的走到这个道路上，我没法去分析清楚。

但是我自认对Web开发的方方面面，有一些体会还是很准确的。我希望我的实验成果还能为别人发挥一些作用，所以我还会把它当作一个副业继续。也许这样，心态反而会变好，作为一个副业，效率比这1年半还高也不是不可能的事情。

关键是了解自己，管理自己，这才是重中之重。

Update:
多加一件事， ATI的程序员不是人。 就是因为有了这样的程序员， 一般群众对.NET的印象就越来越坏。

原帖，针对第四点：

看看客户所说的话， 能不能整理为一个自然语言的子集：与业务相关的小语言，并形式化。 实现过程可以三步走：

1. 对需要变化的业务规则建立统一的模型。

2. 使用解释器模式配合配置文件来表达小语言，应对变化。

3. 当2变得复杂和难于掌握， 考虑实现一门业务小语言， 难度较深。

纸上谈兵， 没机会实战过， 而且我估计这个成本对于承接项目的公司恐怕难于接受； 除非在市场上有多家公司需要这种东西， 这样算是预支成本吧。

对于一般技术人员， 可能认为难度在于实现小语言。 其实最难的一部分是如何将业务规则及其变化归纳为一个可接受的表达形式。

发现博客园对三国感兴趣的人很多，不过关注点似乎和我都有所不同。要是让我看，三国时期只有一个英雄那就是曹操，除此之外就只剩下层次高低不等的流氓及其团伙一干人等。说实话，曹操身上最大的一个弱点，或许就体现在“天下英雄唯使君与曹尔”这句话中了，这说明他的精神境界中还有一些和刘备一样低劣的东西，如果曹魏最终的衰亡真有曹操自己的因素的话，恐怕就在这里了。

有人说三国志中曹操传比别人长比别人详细， 是因为作者以魏为正统， 个人不以为然： 比较一下职业生涯中，在动作的大小和频率方面，刘孙与曹操之间存在的不可弥补的差距， 就可以知道刘备、诸葛亮等作为与日月争辉的星星，不过尔尔。 有兴趣的， 以对于孙刘而言是大动作的粒度， 对曹操阵营的动作做一个列表， 比较一下三者的长短， 再配合时间轴一看， 这些都一清二楚。 这个故事本来一点也不复杂， 只是后面那些只知道拿三国吃饭的学者们把它弄复杂了。

很多人关注三国，着眼于做人，比如曹操所谓的权谋， 这实际上只是旁枝末节。 曹操此人身上所蕴含的巨大而无可匹敌的能量，才是真正无法忽视的根源；即使他做事方法变一个样，结果也不会逆转。 曹魏的命运， 也许可称的上“天亡我， 非战之罪”。 这个问题我没有足够的知识与能力关注，只说两点： 曹虽然起家于官宦家庭， 但其势并不比陈胜吴广项羽刘邦更好；客观历史环境所导致，那个时代的创业者比任何一个其他时代需要做都要多，以他的寿命是无法完成的。

要说做人，我们真正要看到的是，曹操做事情的节奏；我们还不能忽视的是， 无论作为政治家、军事家、社会活动家、文学艺术家，曹操的杰出成就的总和，可以说在中国历史上是数一数二的。 就像数学家标榜的“人类心智的荣耀”，和所有那些取得成功的人所真正留下的宝贵财富别无二致的，他的一生展示了一个人可以达到的极限有多远。 有些人可能认为，像文学艺术这样的东西，和曹操的成功失败没有必然联系，但事实上，正是曹操的内涵决定了他是一个什么样的人。

那些只注意权谋、机巧的人，是不可能走上和刘邦、曹操这样的人一样的道路的。 简单地说，像他们这样的人，好比上了发条的机器，没有停止的时候；而且他们通过训练，可以让动力衰竭的速度，控制在一定的范围内。当一个人在一条道路上，相对时间相展开到绝对时间上比其它人多好几倍，他注定要比所有人强。 这才是历史给我们上的第一课，没有这一课，纯粹的认为（类似的）老毛之所以是大家的头儿，是通读了二十四史或有什么其他杰出才干，是毫无意义的。

孙武告诉我们说，以正合、以奇胜，这已充分说明了孰在前、孰在后。 把周遭的人和事情想的特别复杂，并且和历史对照，在我们有足够的“正”之前，未必是什么好事。作为我们文化历史中的重要组成部分，对刘关张和诸葛亮的褒扬，对曹操“奇”的一部分的过多关注，过去几百年来对我们的民族是贻害甚巨的；这种传统掩盖了最重要的东西：如果一个人没有掌握真正的内在因素，就沉迷和训练自己什么做人、领导的艺术，哪怕就是极端的小人也不能成为合格且成功的大坏蛋。

我们首先要注意的是那些不平凡的人身上积极向上和光辉的一面，他们告诉我们一个人通过自身的努力可以换来什么样的奇迹，这才是属于全人类的骄傲。虽然作为一个普通人，拿我们和BT相比似乎没有什么意义 -- 但我认为，这些才是每一个想改善自己，取得更大成就的人所要关心和学习的； 至少借由这种鼓励，我们可以去尝试突破自己， 这才是真正的榜样的力量。

很随机的不小心进入网上一个不知名的博客，其随笔里提到的，他似乎是个经济学的研究生什么的。

此人说道

我站在马克思的“生产力决定生产关系，生产关系制约生产力的发展”的观点上去解释组织的起源，而非交易费用节约的角度，交易费用节约只是组织的功能，拿功能来解释起源就犯了“功能主义”的错误。

嗯嗯，有意思。很显然我没必要去和他比他们领域内的知识和能力啦，不过还是有些额外的思考。

过去我也是信马克思的，而且，“生产力决定生产关系，生产关系制约生产力的发展"，这一简单基本的观点，我现在也在用。但是随着我自己的世界观的形成，我似乎开始有了变化。使用新的世界观，就不会简单的给不同的角度扣上各种大帽子。从交易费用节约的角度上看，真的是所谓的功能主义吗？即使是，功能主义背后所隐藏的东西，会不会比马克思的观点更朴素更基本呢？

有一个防雷的经验，就是说，如果在雷电击中你的那一刻，你抬起的是左脚，你比较不容易被电死。说实话，我是一个驽钝的人，想了好一会儿才明白为什么：电流想要流入地面，必须从右脚过去，这就有一定概率让电流避开心脏了。但我们不要忘记另一个事实，雷电是击穿空气打到你身上的，那为什么它不击穿你左脚和地面之间的空气呢？

这个道理非常简单，上过初中就学过，电流倾向于从电阻更小的地方通过；由于空气的电阻大大大与我们身体的电阻，它不会去选择击穿空气。我这些描述，细究的话，错误百出，而且很不严谨的拿电流当作了主语；但它在大体上是那么回事。这体现了一个非常基本的规律，就是能量最小耗费的原则；同样，作为更适合当主语的人，如果在获取的信息足够的情况下，我们也会执行最省事的一个方案。

我们可以考虑，如果人类和电流没有这种共同性，恐怕在物竞天择的自然界中，我们早就被淘汰了。所以我们可以认为这是宇宙本身的意思，它告诉电流那么做，也告诉我们该怎么做。我们并不需要高深的哲学和复杂的科学，只要愿意去多了解一些，就可以很不严谨的建立起一套正确概率还算不错的指导方针。

马克思的观点在这里，其实恰恰不是原则，而是结果。我们把“组织”等同于某一种生产关系， 这种生产关系之所以产生，必须符合来自宇宙的指导，这些指导之一显然就包括能量最小耗费原则：我们可以想象，一些领域内活动（不止交易），在某一生产力和其它可能存在的条件下，一种生产关系会比另外一种生产关系更加节约，那么节约的那种生产关系就会屏雀中选。

我这样的说法，和单纯的交易费用节约又有很大不同，但是仍然可能是功能主义的：因为实际上是“节约”这一功能在前，生产关系的起源在后；是为了节约才有组织，而不是有了组织才节约；如果浪费是组织必然行使的功能，组织这种生产关系还能有起源吗？这也就是亚里士多德所说的目的因。另外，我对它的使用本身，就符合了能量最小耗费原则：针对我所需要掌握的程度，这种解释方式可以让我使用更少的能量去琢磨它。

马克思的总结中，还有一些其它因素，比如生产力，为什么生产力会发展呢？ 马克思怎么回答的我已经忘了，但我也有自己的答案，不过，那就是另外一个故事了。总而言之，“生产力决定生产关系”这样的结论背后，其实可以挖掘的东西很多，如果纯粹把它本身当作一个锤子，看什么都是钉子，就非常有问题了。

最后多说一句，我不是唯心主义者，仅仅是选择了这样描述。

     摘要: 也许这就是人类做事的解决之道： 既然我们的社会还不具有一大堆能够将现实世界的问题和真正艰深的科学理论联系起来的顶尖工程师，也没有出现一群真正的大师拿出对大多数问题解决方案的总结，而事情总是要做的， 那么不如一步一步的来， 让菜菜鸟们跟随菜鸟的优雅，采取次一等的做法总是要比什么都不做来的好得多。所谓山中无老虎， 猴子称大王， 就说明大王存在的必要性了。  阅读全文

说实话我有点疑惑， 不知道这样做对不对， 虽然那是我的真实想法。

这东西有趣。 设计产品的都去看看。

http://blog.seattlepi.nwsource.com/microsoft/archives/141821.asp

是一封披露的电子邮件， Gates讲述了在Microsoft.com下载Movie Maker的可怕经历， 以至于写了这个邮件敦促改进。 如果Gates都是这个感受， 那么我们设计产品时应该什么样呢？

     摘要: 工程人员绝对不要期望自己像研究人员一样生活和工作， 一旦达不到就抱怨。 要知道我们的工程时间， 和我们的生命都是有限的， 而一个工程人员有做不完的事情。如果不停的学习， 大多数时候不过是从一个表面到另一个表面的浪费时间， 所谓的“深入”，不过是个自我欺骗的屁话。   阅读全文

一些编译器理论的简单介绍，和现代Parser研究的新进展。

http://www.antlr.org/article/needlook.html

http://citeseer.comp.nus.edu.sg/440034.html

Tomita（GLR） Parser

Packrat parser (use TDPL)

http://java.sun.com/docs/books/jls/first_edition/html/19.doc.html

http://www.cs.berkeley.edu/~smcpeak/elkhound/

http://www.mollypages.org/page/grammar/index.mp

http://lambda.uta.edu/cse5317/notes/node20.html

http://pages.cpsc.ucalgary.ca/~robin/class/411/LR.1.html

http://en.wikipedia.org/wiki/Memoization

http://en.wikipedia.org/wiki/Comparison_of_parser_generators

http://en.wikipedia.org/wiki/Parsing_expression_grammar

---

> The author states that he wrote the GLR parser generator solely to
> handle C++ language spec [and someone lapped it up to handle Java].
>
> What exactly is it about OO languages that an LALR(1) parser cannot
> handle?

As the moderator noted, there is nothing about "OO" languages that
LALR(1) parsers cannot handle, but C++ itself is problematic. There
are LALR(1) and LL grammars for Java.

One of the problems with C++, is that expressions and declarations can
look exactly the same (technically, any language containing those the
or of the two productions is ambiguous) and C++ gets around that by
saying, if it looks like a declaration, it is a declaration (forcing
the "or" to be resolved in a particular declaration (and resolving the
ambiguity). However, that resolution is not expressed gramatically,
and one can not take two random context free rules and difference them
and expect the result to be a context free language, which is what the
C++ ambiguity resolution requires one to do.

In contrast, GLR grammars are not required to be unambiguous. Any
ambiguity is resolved by producing a resulting parse-forest that
represents all the potential mabiguous choices and requiring a later
"semantic" pass to choose which parse tree in the forst is the desired
one. Thus, with a GLR parser, one can disambiguate the C++ problem by
selecting the parse tree that treats all the ambiguous expression/
declaration sub-trees as declarations.

The only problem with GLR as a technology is that are no "warnings"
from the grammar processing tool that the language is ambiguous.
Well, there are warnings that the language is not LR (or LALR) or
whatever technology the GLR parser uses as a base. However, some of
those grammars will actually not be ambiguous and some of the will be
ambiguous. However, in any case, once your GLR generator has given a
warning, one either must prove that the language actually isn't
ambiguous or write your semantic phase assuming that the language is
ambiguous and disambiguate the resulting forest.

It is worth mentioning that there are other ways of handling ambiguous
grammars. In particular, one can use predicates to resolve
ambiguities. Predicates allow one to take the difference of two
productions in a controlled manner. In particular, it is possible to
write a syntactic rules that says, try to parse this as a declaration
and if it isn't parse it as an expression. The difference between the
predicated and the GLR solution is that predicated grammars are still
deterministic. There are no hidden ambiguities in a predicated
grammar. If your predicated parser generator gives you an error, you
still have an unresolved ambiguity and if it doesn't the resulting
parser will always construct a parse tree (and not a forest).

I would be remiss if I also did not point out backtracking parsers,
which are another solution to the problem. In fact, all the
implementations of predicated parsers that I know of, use some form of
backtracking in their implementation. General backtrakcing parsers
share the characteristic with GLR parsers that they can parse
ambiguous grammars. Backtracking parsers generally also produce a
parse tree (although in theory they could also produce a forest).
Backtracking parsers have their own deficits though. Many
backtracking parsers will loop forever on some ambiguous grammars.
(Predicated backtraking parsers do not generally have this problem,
although they do not make the same linear time guarantees that pure LL
and LR parsers do(see note)--of course, any parser generator that can
handle a significant class of ambiguous must be inherently non-linear
for some grammars, and GLR parsers have a cubic worst case, same as
Earley parsers.) In addition, most backtracking parsers resolve
ambiguities by selecting one parse tree out of the forest to return.
This is generally done by the order of the rules in the grammar (which
determines the order the rules are tried in in ambiguous cases). If
one looks closely, this is very similar to using predicates
"implicitly" in the grammar. The key difference being that the tool
inserts the predicates rather than the user and does so without
warning and usually without the run-time termination guarantees.

I would like to mention that it is possible to build a predicated
parser using GLR technology, although I don't know of anyone
attempting to do so right now. From thought-experiments I have done
considering whether to implement such a tool, it seems like there
would be some advantages to building such a tool.

Again, I do not want to imply that these are the only techniques for
dealing with ambiguity. For example, Ralph Boland is pursing some
generalization of LR technology that I gather will handle a wider
class of languages and I don't think his technique is any of the
above.

Note: Bryan Ford recently published a paper on a "predicated" parsing
technique that made extensive use of memoization and lazy evaluation
to achieve (if I recall correctly) a linear time guarantee. His
technique shares a characterisitic with general backtracking parsers
in that the order of rules determines what is matched and the the
entire tree is disambiguated that way. He uses an "ordered" or clause
to implement this.

Hope this helps,
-Chris

---

Chris Clark said (in part):

> It is worth mentioning that there are other ways of handling ambiguous
> grammars. In particular, one can use predicates to resolve
> ambiguities. Predicates allow one to take the difference of two
> productions in a controlled manner. In particular, it is possible to
> write a syntactic rules that says, try to parse this as a declaration
> and if it isn't parse it as an expression. The difference between the
> predicated and the GLR solution is that predicated grammars are still
> deterministic. There are no hidden ambiguities in a predicated
> grammar. If your predicated parser generator gives you an error, you
> still have an unresolved ambiguity and if it doesn't the resulting
> parser will always construct a parse tree (and not a forest)

I agree with Chris about the use of predicates.

Interestingly, the use of predicates alone can some Type 1 power to a
grammar.

For instance:

L1 = {a^n b^n c+} // clearly a type 2 language
L2 = {a+ b^n c^n} // clearly a type 2 language

L1 intersect L2 = {a^n b^n c^n} // a type 1 language

Current research in the area of this class of grammars can be found here:

http://www.cs.queensu.ca/home/okhotin/

See the section on "Boolean grammars." Intersection can get quite a bit of
power out of a formalism.

My most recent paper deals with several difficult to parse languages of the
classical sort, including the particularly nasty to parse:

L = {a^m b^n c^mn}

The only grammar I've seen expressed for that one in classical form is in
Type 0 due to a length increasing production:

  (1) <S> ::= <H><S> | <H><B>
  (2) <B> ::= <B><B> | <C>
  (3) <H><B> ::= <A><X><N><B>
  (4) <N><B> ::= <B><N>
  (5) <B><M> ::= <M><B>
  (6) <N><C> ::= <M>c
  (7) <N>c ::= <M>cc
  (8) <X><M><B><B> ::= <B><X><N><B>
  (9) <X><B><M>c ::= <B>c
(10) <H><A> ::= <A><H>
(11) <A> ::= a
(12) <B> ::= b

Because production (9) is length increasing, the grammar is in Type 0 form,
even though the language itself is Type 1. I'd like to see that grammar
normalized to a Type 1 -- but haven't been able to find one.

The longest derivation I've been able to do with that by hand is aabcc,
which is:

(11) aabcc --> <A>abcc
(11) <A>abcc --> <A><A>bcc
(12) <A><A>bcc --> <A><A><B>cc
  (9) <A><A><B>cc --> <A><A><X><B><M>cc
  (7) <A><A><X><B><M>cc --> <A><A><X><B><N>c
  (4) <A><A><X><B><N>c --> <A><A><X><N><B>c
  (3) <A><A><X><N><B>c --> <A><H><B>c
  (9) <A><H><B>c --> <A><H><X><B><M>c
  (6) <A><H><X><B><M>c --> <A><H><X><B><N><C>
  (4) <A><H><X><B><N><C> --> <A><H><X><N><B><B>
  (2) <A><H><X><N><B><B> --> <A><H><X><N><B>
(10) <A><H><X><N><B> --> <H><A><X><N><B>
  (3) <H><A><X><N><B> --> <H><H><B>
  (1) <H><H><B> --> <H><S>
  (1) <H><S> --> <S>

I started on aaabbcccccc -- but got lost in the shuffle. :-(

If anyone wants to try a purely "predicate" approach to the above
language -- I'd love to see it. (Or if anyone would care to post the
derivation of aaabbcccccc, I'd really love to see that, too.)

The $-grammar I wrote for that one accepts strings in O(n^2.3), and has 6
productions and 2 of those are predicates, but also makes use of 2
phi-expressions, which implies a total of 4 predicates (since there is an
implied predicate with every phi-expression) and at least 2 name-indexed
tries.

Also of note is that I allow for a-expressions in predicates, which allows
for substrings that have been parsed to be concatenated to form entirely new
input that is then passed to the predicates. (The $-grammar for a^m b^n c^mn
uses this.) This is similar to what is known as "length-increasing".

Anyway, a few nights ago, I was asking myself about this formation in C++:

class Foo
{
int inline_function(int x)
{
return __y * x; // __y is used before being seen
}

int __y;
}; // this class is legal

class Bar
{
int inline_function(int x)
{
return __y * x; // __y is an undeclared variable
}
}; // this class is not legal because __y never gets declared

$-calculus was able to handle this ... without any code, accepting Foo and
rejecting Bar -- using all of the above mentioned techniques.

Although the resulting $-grammar uses more than 1 explicit predicate, it
does make use of phi-expressions, and these have implied predicates -- so I
was not able to do it without extensive overall use of predication.

Anyway -- I wrote it up and am looking for somewhere that is looking for a
3.5 page paper on such things. Any thoughts?

[BTW -- Chris -- direct email to you bounces from my account. Is that a spam
guard?]

     摘要: 方法级的AOP的一种办法， 利用了新的Expression， 比起生成动态代理类那是清凉多了， 使用起来也灵活， 就是表达方式有点丑 :P

这是跟老赵还有脑袋讨论的成果， 感兴趣的可以进来讨论一下。 感谢老赵和他的文章的帮助， 同时也更深刻的感到如果语言的表达方式能提供足够的支撑多好， 大家一起催脑袋干活 :P  阅读全文

     摘要: 绝对有另你不适的内容， 不想反胃勿进； 基本上是一篇可以定性为“反人类罪”的发泄。  阅读全文

     摘要: 先把一些相关的内容， 想到的目录记录一下。 这些标题是散乱的， 甚至不是一个层次的， 仅仅做一个备忘的笔记。

顺便说一句， 这个系列不是忽悠大家去用某一门“表达方式更丰富”的语言， 或者给出什么解决方案。 对于大多数程序员， 身处环境和项目当中， 更换语言是不现实的。 更何况说实在的， 现在还没有一门语言能够完美的达到我想要的效果或标准； 即使那些能够做到的语言， 我们可以采取的表达方式也是极其丑陋的。 并且， 在这系列文章的讨论所涉及的一些工作，如对语言本身的改进， 也不是大多数程序员任务。

但是我们仍然可以因为一些深入讨论， 知道问题的症结所在； 从而在能避开的时候避开， 在不能避开的时候， 不会殚精竭虑的去寻求不切实际的解决办法。 同时， 在这个系列中， 我们也可以找出一些外围辅助的方式处理好其中一些问题， 暂时不能治本， 指标也好。 更多的， 我们可以通过讨论，把现今那些浮躁的解决方案先放到一边，努力的去试着看清未来10年一些可能发展的方向。如果10年之后， 你我还在做技术， 即使没有预测准， 这样的尝试也不能说是无意义的。
  阅读全文

再更新两个地址：
http://programmersatwork.wordpress.com/john-warnock/
http://programmersatwork.wordpress.com/bill-gates-1986/

更新一个地址： http://www.infoq.com/articles/dsl-on-the-clr

地址： http://www.codersatwork.com/names.html?order=popularity

最后这个是个大牛列表 :)

问题：

具体点拿一堆图片的管理来说， 大多数系统， 都是有一个Picture表， 一个Category表， 一个链接表， 链接表就这两个字段： PictureID, CategoryID。

比如任何一个相册， 用户可能给一张图片一个分类， 但是也可能没给这张图片分类，这些没有分类的图片， 在咱们实现的时候， 是让他们属于“没有分类的图片（或默认分类）”这样一个分类呢？还是就让他们什么也不属于： 凡是用户没有指定分类的， 根本不在链接表内出现。

对应于数据库， 对于用户没有选择分类的情况，这两种做法区别在于在链接表内， 会不会有 {PictureID = 1 CategoryID = 默认分类ID值} 这样一行。

有默认分类的优势在于当用户查询“所有没有分类的图片（或默认分类的图片）”的时候，一句"Where CategoryID=默认分类ID"搞定了， 而且可以统一处理“没有分类，分类1， 分类2....”之间的区别。 劣势却仅仅是我的链接表里比不设立默认分类， 多出很多行。

我的想法是， 是否可以把设立默认分类当成一个最佳实践，无论建立什么系统时， 只要在实质上是一个分类的问题， 都可以采取这种实现； 因为这个问题普通到不再受其他条件的影响。 问题在于有没有不适合的反例，比如有默认分类在某种情况下更糟糕， 我想问的就是这个。

这个问题虽然简单， 不过从我第一次接触到现在7、8年来， 一直没有着急做出判断， 也是不敢轻易判断。 因为我无法判断从事情的本质来讲， 没有分类是不是就是一种分类； 这个问题和0到底是不是规划到自然数有点像； 所以对于我来说，这个问题的答案， 对我认识事物也许会造成连带的影响。

那么如果不说这些虚的， 光从实际出发， 设定一个叫做“没有分类”的分类来简化问题， 是否有存在着不适用的反例呢？