GData的文档，Google的野心一览无余呀
http://code.google.com/apis/gdata/overview.html#Motivation
Google’s mission is to organize the world’s information and make it universally accessible and useful. Sometimes making information accessible requires making it available in contexts other than a web browser.
用了一早上把能找的认识的人的rss都放到bloglines上了（当然还有一些fancy的东东）
开始用Google Calendar了，希望（估计也会）这个东西能和gtalk整合起来
bookmark已经都在delicious上面了，不怎么用收藏夹了（不过tag的不爽就是这东西是平面的）
豆瓣，提得挺多的了，看的书和电影都放在那里
想换个能支持定制界面的blog，这样就能把常用的功能都放到界面上，还不是太喜欢google的个性化首页（不过如果不行，我很有可能自己去花精力去写module）
我想要一个不用代理就能出国的ip
有一句话说得很好：量变引起质变。2006是integration年，说得是enterprise。个人呢？生活方式就快发生变化了，每个人，或早或晚，赶早不赶晚
Borland announced plans to seek a buyer for our IDE product lines
M$的VS.net 2005，Java有Eclipse。一代Borland，可惜了
以成为世界上最复杂的语言为己任？呵呵。不过看C#3.0（VB9）还是有点启发。
记得原来说python要加入静态接口的时候，以为在动静融合这条路上动态语言有动态类型可能是要方便一下。不过现在C#3.0要把这些原来CLR不支持的特性在轻度修改CLR的基础上，大部分职责全推给编译器来搞，倒很是让我想起C++静态多态（泛型）的做法来，充分发挥编译器能力这一点上来说，静态语言倒是拥有长足的优势，虽然
var i=new A()
写出这种东西，然后让编译器来推理类型，不如动态类型那么自然，但是效率上的得益在这里又不能忽略了，而获得的能力（匿名类型、匿名方法，还有传说中VB9的动态接口）又足以实现DLINQ这种东西了（虽然不怎么喜欢这个方案）。效率和表现力的比拼，在这方面可能更大程度上要去看硬件的表现了――真的有一天能略掉反射的损失的话，哼哼……
Osterweil说对于Process Software，单单Modelling是不够的，要Coding要精确。
问题在于Process是个高度并发的东西，而像编程语言这种东西确实线性的，并发则是语义外的（其实对于人类的语言也是如此，所以我们总是说“……，同时……”。当然七只桶语言是例外，呵呵）。
所以Osterweil的那个JIL就成了个图形化的语言——如果还算是语言的话。
结论是我们需要一种天生描述并发的语言来描述Process Software，如果没有这种东西就造一个。
这两天用C#编码，一旦考虑向后兼容性，突感静态类型的不爽。模式上无论如何努力，实际上一旦系统成型就结构上的改变都代价很大(可能我对重构的理解还不好)。
而动态类型缺乏编译时期的类型检查，小系统还可以，3-5人的团队。如果是构件级的开发，无法描述接口的影响将是灾难性的——文档都不知道应该怎么生成。
想来不久前Guido说要在python中引入可选的静态类型检查，当时一片NIMP(Not In My Python)的声音。不过仔细想想很有道理。
当Java、.Net都在虚拟机上引入字节码兼容的动态语言，动态语言爱好者们就往往陶醉在Helj那句“针对动态语言的特点，静态语言能做的反击是非常有限的”。实际上静态语言在努力吸收动态语言的优势。反过来动态语言的动作却很少。如果将来Python真的加入了可选的静态类型检查，可以算是一种尝试。
设想一下，如果将来是模块用静态接口包住，但模块内可以有动态语言的表现力。可爱至极。总之，动静之间就是融合、融合。
ps:感觉没有范型的静态类型太可怕了。Bjarne说把一切都继承自一个统一的object来实现容器是愚蠢的，有点偏激，但也有点道理。到处是向下类型转化，不知道java们这些年是怎么坚持过来的。