怪怪 | Nothing, Everything

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

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

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

提醒一下自己， 该干活干活， 少那么多废话； 再不行就拔网线了。

 

多提醒一次， 少发表对谁都没有帮助的意见。

 

如果写出来不执行， 那就是更大的祸害。

 

我还要加强对自己的管理，不要操心别人的事情了，我还不够格。

 

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

 

从状态上来说：

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.我没有专精， 而是每一个接触的方面， 都达到比第一流差的那个水平， 这是一个好事还是坏事？

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