怪怪 | Nothing, Everything

@uda1341 到位。 进度如何了？

[url=http://blog.sina.com.cn/s/blog_948c17610100wgnm.html]godaddy优惠码[/url]

相关言论： 1、语言只应该涉及到逻辑，不对应任何具体的运算机器。 2、应该有一个独立的，对硬件和运算架构的逻辑描述语言 3、现有的编译器只是在内部隐含了对硬件的要求，没有独立表达为知识。 4、硬件不仅可以包括各种CPU架构，还应该可以包括FPGA 5、最大胆的期望，通过对X86架构的描述和对FPGA的描述，可以把一个操作系统的二进制版本转换到FPGA计算架构上运行。

@七心葵 首先我接受批评、原来高中写作文的时候还有老师管着，现在撒了欢了呵呵。 不过这和我的文章立足于讨论而不是价值观输出有一定关系，在辩论的上下文中存在一些假想的或真实存在的辩论对象，我会估摸他们的说辞并在他们说出口前予以反驳。 对于写文章来说这是很不好的习惯，尤其是如果读者不在当时的上下文里。 另外你说的我说出口又扭扭捏捏，确实太世故了一点。说实话我已经把自己的真实身份与网络身份刻意隔开了，原本没这个必要（连孟岩这些有名有姓的都敢随时张嘴胡扯呢呵呵）。 即便考虑是我可能出错，等着别人来反驳就好了，装腔作势毫无意思。主要是一开始选择了这样的做法，最终成了惯性。 就这篇文章作为例子来说，如果改成我自己的思考结论的陈述，基本上1/5的篇幅甚至更少就够了。现在回过头看，自己也得反应半天，总体来说无论对错，它都变得毫无价值。 谢谢提醒。 可惜我在近一两年之内恐怕写不出真正有价值的东西了 : (。最终决定自己尝试走一条不同的路，这个过程看起来会很长（甚至基础软件先驱们已经走过的也得重新去走），中间结论的价值不大估计也没什么人会关心。

看过怪怪的一些文章，应该是知识面很广的人，对怪怪的技术思路也是很赞同的，不盲从于某种技术，不崇尚过度抽象，不局限于一个开发范式。 但是怪怪的文风真的不敢恭维，看着累，抓不到重点，不知道你想说啥。技术文章直截了当地写出来不好么。 像孟岩那样的人的文章，每次看得很舒服，说得就是很清楚；云风的文章可能文采稍逊，但是也是明白易懂的，可供揣摩的；文风活泼一点的像以前CSDN的g9老大（负暄琐话）在学到东西的同时也能开阔技术视野。偏偏就是怪怪的文章，真的看起来很费力。 还有回复中，经常都是： @a:xxx @b:yyy 引用一下原文不好么，上下文不知道是哪个啊... 文中可以少一点自我否定；还不太确切的结论没必要写出来，写出来了又加上诸如“话说到这里， 点到为止， 也许我是杞人忧天、不知所云、愤青、幼稚、浮躁、无事生非也不一定。” 这样的话，真的是浪费大家时间。

我也有..，我并不是说搞公司容易，放爱因斯坦希尔伯特去也不见得就能弄出什么像样的事业。 我只是不喜欢任何神话....

估计你没自己搞过公司，我是有失败的经验，市场运营和资本运作所需要的技巧、脑力和经验，大多数只搞技术的工程师都会严重低估。

本来就是个超高难度的东西嘛。

新的读后感可没把住门... 其实那书明显是苹果Jobs身后段时间内营销的重要一环。对于公关和媒体来说，招我这种少数人烦可能无关紧要，我太认真了。

说实话我总觉得你低估难度...

顶，说的是事实，并没有贬低乔帮主的意思。

按照自己不太可靠的感觉，已经进入到快揭开谜底的阶段了。 入口大概是一个我想称之为元演算的一个系统，这个系统可以成为lambda演算，谓词演算和各种形式系统的构造基础。在这个层次上倒是没多少细节了。 方法还是用prolog做一些小练习，代码量撑死也就几百行的规模，要是超过1000行就该怀疑是不是有问题了。

@uda1341 不过时、对一般程序员却不现实。而且其实很多这些表述，你心里向往的时候就觉得是金玉良言；如果换个心情去看，跟扯淡也没什么区别。 我的意思不是说尝试是不好的，而是作者本身因为没有像咱们假象的“他”那样深入实践过，并没有什么深刻的体会，不过是些“知道分子”罢了。 希望咱俩不要落进相似状况。你最近进度咋样？我自己的东西让数据底层的实现细节给耽误的让人抓狂，不是这些细节多重要，而是我自己工作方法不对。 @Joe & gordon 客气了。 这些东西我觉的泛泛的知道一下或者有的放矢的把其中对自己的有用的内容当作一个入门索引，在具体领域工作时肯定是很有好处的；但是对于一般工作者、学习者而言，我想不出那些“大道以一贯之”的体会是怎么从这些书里得到的。 数学的话，主要是学习者的心理门槛太高；而且就实际工作而言，有时候找不到所学内容的着力点，这成了一种学习阻力。

@ahking 一般外部来的工作就看人家用什么了无所谓。有时会用ASP.NET快速开发一下。 自己的工作一般用python，不过完全不使用任何python下的web框架，用python在于容易向C/C++移植瓶颈部分，各方面受限制少。 如果是一般web项目我不推荐python，没什么意思。语言弱点很多，运行效率不佳。

@蛙蛙王子 再次利用空间的抽象性想法并不难。说白了就是空闲列表。其实比如删除很多数据库产品做的也很简略，比教科书都不如，这不是因为不会，而是因为在实践上没太大必要。 关键是方方面面加在一起鉴于物理上的限制很难正交分解，如果想在哪怕一个局部精益求精，麻烦就多了。

SICP P248 正文 本章开始时提出了一个目标，那就是构造出一些计算模型，使其结构能够符合我们对于试图去模拟的真实世界的看法。我们可以将这一世界模拟为一集相互分离的、受时间约束的、具有状态的相互交流的对象。或者可以将它模拟为单一的、无时间也无状态的统一体。每种观点都有其强有力的优势，但就其自身而言，又没有一种方式能够完全令人满意。我们还在等待一个大统一的出现。 SICP讲的重点不是FP，它只是语言上采用了lisp，事实上它的内容涵盖了几乎所有的方面，而且一点都不过时。

可否联系下:ken767@live.com

"ASP.NET的深度开发",你现在网页深度开发用什么技术

注：谢谢你的经验，个人还是觉得有这么个精力，还不如看数学系的数学书，哪个颗粒度更小，而且更普适，你不是一个生活在计算机世界的人，你是一个生活在现实的物理世界的人。 数学在物理、经济学、机械可以说的出来的自然科学中都有应用，这样的投资收益比会更高，不要钻在这本书里，尤其是你自学的时候。 总的说来就是不要钻牛角尖。

@怪怪 嗯，是呀，数据库的物理实现比较麻烦，自己想，不太好想明白，尤其是删除数据后怎么再次利用该空间等，和内存管理有一些东西相似，有个垃圾回收的过程。

@蛙蛙王子 数据库的难度主要在于空间管理，因为用户要存储变长数据，而“物理”存储单位却是定长的；再考虑空间节约方面的需求和其它因素，就变得比教科书上的算法复杂得多。 至于编译原理，主要是理解那几个计算模型，以及它们和实际算法间的对照关系。如果只是“写编译器”，其实倒不见得要把编译学得太好，只要能实现翻译过程就行了。

我前阵子还想用python写一个数据库捏，还没想明白，这两天学编译原理，想学学怎么写编译器，呵呵

@蛙蛙王子 没...，我至少暂时不需要建立个人品牌，弄那玩意干嘛... 这文章是copy来备份的，不过其实如果抽的出时间，是值得看一看的。我自己忍着给看完了，确实有一些东西推翻了我熟知而且也相信的说法和段子。 这人虽然是搞社科研究的，但跟国内无论哪一派学者相比，确实采取了一种科学的态度，或者按照我自己的看法：“真正的程序员的态度”。

怪怪兄有微博不？这文章实在太长了也

@麦田里的守望者 的确不合适。 而且从我个人来说，我知道很多神交的朋友可能都和我站在不同的阵线上，我不愿意因为这些话题影响技术交流的无政治性，所以以往都是尽量避开这些话题。 不过这次的大规模运动确实让我觉得不得不做点什么。你看我转得这些调调（虽然具体文章有很多幼稚之处），基本没有一个主流媒体是站在这些立场上的，这健康吗？ 说实话，在动车事故之前，我就觉得风向不对了。而动车事故40多条人命最终成了某些集团达到目的舆论工具，这是对人的生命的最大的不尊重，起手段也是我难以接受的。 我不能保证自己没有站错队，但有些事情的发展趋势是关乎我们或者我们的同胞未来几十年的生活、关乎我们的子孙后代的，想避也避不过去。 在这种事情上我愿意就我当时的思想选择成为传播路径上的一环。就是如此。

这种文章发在博客园不太合适吧

@小猪凯 没错，此人确实把大家打败了。不但这话说得太不得体，后来看了视频，此人连表情都很那个。不过他能负什么责任？仔细想想什么也负不了，不过是一张嘴罢了。 在类似的问题上我的倾向是矛盾的，一方面我希望政府部分多点这样的愣头，那些懂得如何作秀的对咱们老百姓可能更不利；一方面就这个事故来说，这样的愣头对稳定社会情绪是非常不利的，还是东电那种十几年隐瞒问题等出了事故而且盖不住了四处磕头谢罪的表态比较让人舒服（这句话不包含任何反讽，只是从有益效果上来说）。 具体到此人，说实话如果是我，可能也说出类似的话。设身处地的想想，他的心态肯定是“你要什么都不信还问干吗”，压力大了没控制住。按理说正确的做法就是温那套，使劲儿做保证就好了。铁道部确实太大老爷了，居然选这么个未经训练的当发言人。

“信不信由你，反正我是信了” 这样不负责任的话是从一个国家的铁道部高管口中说出的，真是牛了

我是逼出来的啊...，烦某些“公众知识分子”的嘴脸而已（另外当反对派也用不着我了呵呵）。我知道我转的这个调调也很有问题，只是觉得眼前声势浩大的批铁路运动的根子更不纯正。 我比较赞成的是罗素推崇的那种知识分子参政方式，凡是极端的一边倒我都觉得反感。不过目前判断，保共比fan共对短期社会形势更有利，而民族发展的这个时间节点需要保下短期。 我其实很讨厌谈论这些话题，但这次从高铁故障开始到动车事故一系列表演让我有点坐不住了。我真正反对的其实是借题发挥、发酵。如果不含这种味道，就是骂得更狠些也是应该的。 其实各类媒体上还有一种让我坐不住的现象但是连骂都无从骂起：那些降低女性道德底线（性开放常态化的氛围）和糟蹋女性声誉（比如女大学生如何如何，99%是编的）的各类文章。 P.S. 我个人也不喜欢温...，不过博客园里咱就别这么说话了，给别人招事。

这么多天没见，已经快变成自费五毛了？仔细想想你的逻辑，在什么地方出了问题吧。 温二逼当众撒谎说病了，结果被揭穿的事情呢？

正如 布鲁克斯在《设计原本》一书中所说， 优秀的设计来自优秀的设计师，而不是来自优秀的过程。 越大公司往往比较难产生优秀的设计，因为大公司为了抑制失败和错误的产生，有更严格的过程，而严格过程对优秀设计的抑制是致命性的，除非这个公司有专门超出过程之外设计至上的优秀团队。 我想Dell、Sony等公司，都在苹果的成功面前，害怕自己的失败和错误，与其冒险去自己开创设计，不如借鉴现有的苹果模式，这对企业的利润来说是有益的。

现在是21世纪了好么，不是要求它没缺陷，而是21世纪有21世纪的消费级操作系统标准。 你在这强调Android如何耗费人力物力脑力又有什么用？比如说到Android在内核中的工作，在Linux社区有几个不骂的？是只有我一个人在这BB么？Android 2.2前技术上的污点（后面的我再也没碰过了）正在于你说的投入多少人力物力脑力却不过如此，Google又不是Palm一类的小公司对吧。 我承认Android绝对是工作量而且具有相当的复杂度，但也就仅此而已。而且如果你自己调试过那个该死的多媒体框架、自己被Android中间层接口的弱智设计气的没辙，你的感受一定完全不同。 我只是在说那些我亲眼所见的事情：无论是大多数局部、还是整体，都有比Android做得好的现实存在，而Google这样规模的一个公司，表现出的水准和声誉完全不相称。 当然我相信只要商业上成功，Android最终总能大成，但这种仗着品牌要开发者、消费者买单的启动过程我个人实在无法恭维。 “从内核到Java Framework? 这个整体构架哲学和实现不花点功夫？” 你觉得拿主意的需要几个人？除此之外剩下的都是什么活？就因为它是伟大的Android，于是抄一个Socket的Java包装（还抄出bug）都得用上高级人才？(btw 这篇文章这么长时间过去，最近大家工资都普涨了吧，我说那数可以提到8K~10K，RMB哦亲。) 另一方面，除了Intent部分确实有很好的考虑，其它大的小的框架/构架哪个不是抄来的？事件驱动不是？界面分离的方式不是？哪个比它抄袭的对象更加完善了？ 要说我经常胡扯，我还真得欣然接受。但就这篇Post发表的时候，至少本文涉及的内容我都是亲自挽起袖子干到一定程度的；负面印象都是第一手的，如此糟糕的开发经验，只在ASP.NET的深度开发上感受过，实话，爱信不信。 最后，你的逻辑我不认可，天朝有的是非*nix系的操作系统，比如那些实时操作系统，用户面窄罢了。Linux也不过是赶上一个好时光、好环境让它发展完善罢了。 至于逊不逊色，也要看从什么角度。垃圾的交互设计、封闭的商业环境、超弱的硬件，输给Android那是应该的，但这不代表技术上Android也有什么优越性。用个400mhz的ARM7试试？

1. 这是扯淡文，LS真有闲心... 2. 对象是概念，虚表和内存布局是在某种计算机上的一个映射。普遍的说法是对象是类的实例化，当然属于运行时。 3. 虚表等等本身就是类型信息的一部分的一种映射，被保留并带入运行时。没有这些类型信息你所谓的运行期多态Magic根本不能工作。 4. in which当然是修饰contexts，关键是their type是谁的type？你没发现即便你的翻译理解和你的“所有”都是矛盾的吗？-__- 5. 任何对象类型在它自己编译的时候当然都确定了；这里的关键是对象的具体子类型在使用父类型操作对象的代码编译时是不确定的。 6. 你的说法正是我原先的某一种解释，但用在这里并不贴切。只能说明你能看到绝对性的地方，却看不到相对性的地方。 7. BS的这个说法本身和其他类似的权威并不一致，没什么价值可言。只是当时正好提到，大家吵着来劲（也只为这个目的）。 8. 你最好搞清讨论的层次和上下文，就这个讨论而言，完全不必涉及语言提供的机制，更不论细节了。用下层否定上层，只能显得无知而不是高杆。 9. 不要假设别人都知道的比你少...，此处无论我们讨论的、还是你所知道的都不过是些地摊货色的“知识”而已，真当个事就别进步了。 10. 说实话碰着个兄弟你这样的我真挠头，说重了也不是说轻了又不爽。 看看我博客顶上狄德罗那句话，咱俩一起共勉 :) 凑齐十大了...，原来罗哩罗嗦的回复删掉~

胡扯。 Android上有很多闪光点。Dalvik虚拟机你说没技术含量，好。Google重写了加载链接器，这个也是几个核心程序员就搞定的事情对吧，好。Google重写了一个binder驱动用来做进程间通讯，并由此在应用层搭了一个轻量级CORBA框架。这也没什么技术含量是吧。Java Framework借助CORBA构架完成应用组件抽象，这个呢？ 加上各个子系统和底层驱动。 最后把这些工作统一起来。 Google投了几十个亿美刀，花了那么多时间才整合起来的系统。其特性和现在任何一个手机操作系统比起来都毫不逊色。 最后麻烦你看看人家的build system和里面的链接器控制脚本。 找些5000-7000的加一点点NB程序员来整这些？从内核到Java Framework? 这个整体构架哲学和实现不花点功夫？忽悠谁呢。咋天朝那么多NB公司天天操作系统操作系统的，明明linux内核源码就摆在那，怎么没见几个操作系统。 代码堆出来的东西，要说没缺陷，可能吗。

...... 看到这么纠结的东西...什么object based, object oriented,有必要讨论的这么严格？一般的界定是只要不使用继承(没有多态那么继承也就没有意义)，以及虚函数这种多态手段就算是object based. C++是静态类型语言，所有对象的类型都是编译时确定的。类型的语义维护发生在编译期。转换为汇编代码后所有的类型信息都会丢失，没有什么runtime和virtual machine来在运行时进行类型检查。所以严格的说C++不是类型安全的语言。 至于C++的多态、泛型(模板机制)能力，这些东西都是编译期确定的。我把它们叫做C++ Magic. 哼，还有异常机制呢，C++没有VM，它怎么做到栈回溯的？嗯，这些都是C++ Magic. 编译期确定的东西，和运行期运行逻辑所导致的运行期变化 -- 说来说去不就这个嘛。而天啦，编译期和运行期 -- 这根本没什么好混淆的 -- 所有使用编译型语言的称职的程序员都应该能区分它们。 当然，对于C++来说，-- 编译期为运行期逻辑变化准备了一些额外的东西，模版会替你生成实例代码，使用虚函数时编译器会为你生成虚函数表，异常机制会在函数代码中(运行期就是在栈上)加点料...嗯，这些是C++ Magic. 所以我想问LZ，你这么纠结的写了两篇烂文章来阐述一个烂问题？还写了些乱七八糟的烂代码。 最后，我想告诉LZ，Bjarne Stroustrup大师那句话的正确翻译： Objects of some user-defined types contain type information. Such objects can be used conveniently and safely in contexts in which their type cannot be deter-mined at compile time. 一些用户自定义类型的对象包含了类型信息。 这些对象能够方便和安全地使用在那些无法在编译期确定对象类型信息的上下文中。 -- 人家Bj S大师说的是，“上下文中”，那个in which修饰的是上下文啊上下文！不是对象！“你无法在编译期确定上下文中的(对象的)类型信息“ -- 而不是说，对象的类型信息在编译期本身是无法确定的 -- 事实上所有的对象的类型信息都是在编译期确定和维护的。 LZ，英文好好学学吧 ...... 另外，换句话也不是就说运行期就可以确定对象的类型信息，因为运行期没有对象也没有类型信息，所谓的对象不过是一个内存位置中放了一些东西，而C++在编译期做的那些Magic的事情能够保证运行期的，在人类看来的，对象和类型识别的逻辑而已。 ，...最后等我写完这回复才发现原来这帖子在N年前。挖坟了。我2了... Damn.

哈哈～ 现在我转学了php 和 lisp，真正的感觉到 ，netfx 和vs 真他奶奶的大而复杂。

@deerchao 嗯，我开始也觉得原子性应该是第一位的，不过我在实践中发现原子性不是真正的让我们选择DB的大麻烦，所以在此文中就干脆没提。 具体地说，最开始我本来以为保证了原子性就能很好的解决数据存储了，实现这个也确实没花多大功夫，用文件锁或者进程同步机制很容易在各种粒度上解决问题。 随着需求的深入继续下去，就发现DB和文件系统之间的区别、以及DB真正的作量根本就不在这。比如SQLite原来只有简单的整体锁，这是很容易实现的；那使用SQLite是为了什么呢？ 从另一方面看，虽然DB教材里也会有很多其它内容，如原子性、事务、并发、分布式等等，但其它种类的任务也可能产生这些需求，这就很容易看出易定位、可排序、致密摆放才是DB的核心。 说白了，此文的目的是正是为了排除那些并不只属于DB、与DB特性正交的其它特性，而留下那些由DB主要提供的保证。

我觉得DBMS最重要的是它让你能很轻松地实现操作原子性，不会出现一半提交的问题。用文件系统的话，就麻烦很多了。

@uda1341 这我提不出啥有效建议，毕竟虽然目标相似但路子不太一样，等你接下来的成果和心得了 :)

我在琢磨新的语法设施，前面弄出来一个合并句，后来弄出来一个“摹状词”，这两个语法设施，发现用关系代数的方法来定义可以更数学化，更简洁。合并句就是一个笛卡尔积，“摹状词”可以定义为一个关系值。 现在额外增加的工作是，找到关系代数和谓词逻辑的对应关系，并用谓词逻辑和时态为关系模型补上缺失的部分。

那小子似乎和咱们不是一路子的。比如他数据和操作的分离这样的观点说实话毫无意义：操作在物理上虽然不是数据，但任何程序员把它以任何方式描述出来，它是什么？而这最显而易见甚至有些技术明星都能理解的事情，有些人就非得视而不见。 他一边骂OO，却一边搞着和OO相似的实体与模型，唉。还有他英文博客上留言的那小子，虽然他比我清楚什么是FO、SO，但他那些有关trade-off的废话真是听的耳朵都起茧了，这就是读了不该读的东西的典型例子。和咱们说的也根本不是一个事情。 另外他那里似乎没有关于数据库实现的？说起来还是你的原帖对我这个唯名论的耳朵，哈哈。不过你豆瓣上的另一个留言的家伙说的和我这几年一直没改变过的想法如出一辙 ：） 关于其它话题，其实SQL、NoSQL不过是具体化的一些形式，带有典型的时代特征，我倒是不是特别反感前者。不过就现在的NoSQL热潮而言，很多fans都是被忽悠了，这两东西除了接口给出的对实现的抽象的层次不同，本质上是一样一样的。 其实真正要命的是多维如何映射到现有可用的硬件结构给出的一维上，无论是对他们还是对咱们而言。 以你的路子，建议你现在暂时不要考虑什么List、Tree之类的，也不要考虑优化和用户的访问方式一类的问题。就我看来这些并不属于容器的一部分，而是容器有了以后要承载的内容。

这几天有个搞数据库的关注上了我，还翻译了一篇我的日记发到英文社区。 而且这段时间在设计基础语法的时候，也不可避免地和关系数据库挂上了钩，一些地方要用到关系代数或者关系演算。 你可以看看有没有什么启发： http://thinkinmodels.wordpress.com/ 从关系数据库的发展来看，SQL被搞理论的大牛贬低得很厉害，而且对对象数据库的批评也深得我心，还包括我提到的并且认为是错误的E/R模型，他们也有很尖锐的批评意见。

@FireWard 嗨，这书的内容没什么可讨论的。毕竟对于真懂（一些）的读者，没什么深度、广度也有限；角度方面放到今天也不太新鲜了。 人文方面的读者，如果光从培养情趣之类的角度看此书还不错。

可以和xiaotie讨论讨论

顶楼主

@uda1341 嗯，所以我倾向于评价一个人的量（干的事情难度和规模），而不评价一个人的质（干的是不是我认为最有意义的）。

[quote]说到Anders和Knuth，你的评价是不公的。微软M语言原来的规划是大的，只是不知道为什么缩减了。而且即便如此，类似于Anders这样的人，他们掌握的实践经验和其它能力，其信息量就已经巨大了。Knuth在学术那块也是这样，我靠让我把那些东西整理出来还能弄个TeX，即便我有他的环境也完全没戏。[/quote] 不好这么比啊，你把图灵本人放到anders的位置上说不定还干得一团糟。让邱奇来写《计算机程序设计艺术》也未必写得出来。至于我，往这两个方向上发展，在我见过的并且认为还不错的程序员中至少有一半都会比我干得好。 各人有各人的造化，各人有各人的安排。

学习了。。。

数据是一切逻辑的灵魂。 面对未知时，能立刻拿来使用的恐怕也只有数学这个无所不在的工具。 数学无所不在。也是现代科学的基础。

@brilliant_idea 按照某些数学家的看法，数学只关乎“人类心智的荣耀” :) @yealov :) @Ivony... 非欧几何现在不新鲜，不代表20世纪初也不新鲜吧。说实话它越不新鲜，越说明基本数学训练的重要性啊... 其次我的例子是用来说明数学并不依赖于其它领域的需求；相反是由其它领域自行发现数学的用处。 我也没说要扬短避长...，只是对于没什么其它长的普通人来说，无论是对个人还是从社会角度来看，进行点思维训练总没坏处。