从状态上来说：

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

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

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

namespace fields
{
    struct name;
    struct age;
    struct code;
}

typedef map<fusion::pair<fields::name, std::string>, fusion::pair<fields::age, int>, fusion::pair<fields::code, char> > person;

person a_person;
at_key<name>(a_person) = s;
at_key<age>(a_person) = i;
at_key<code>(a_person) = ch;