good good study, day day up

近年来各种编程语言如雨后春笋一般涌现出来，令人眼花缭乱。有些是已经有相当历史的近来得到了广泛关注，有些则是新创的但风头不弱于前辈。它们的名字虽然我很多都听说过，大概知道是什么样的语言，但也是仅此而已了。

这些新兴语言大都是动态语言，运行于虚拟机之中。而我一直都是使用C++/Java这些静态语言，这些新语言让我觉得很新鲜。在具有动态特性的语言中，我唯一熟悉的也就是PHP了，但是php给我的印象是方便灵活，但是显得零乱，缺乏OO特性，难以承担大规模应用。也因此我对这些语言就带有一点偏见，觉得“不够严谨”、有点“小儿科”。

由于所开发系统的业务逻辑的复杂和多变，让我们吃尽了苦头，寻找解决方案的一个思路是将业务逻辑控制分离出来，降低这部分修改的难度。如果要再进一步，就是要采用script来描述业务逻辑了，那么是设计这样一种script，还是有什么现有的架构可以重用？

将视野放开，可以看到动态语言在这方面得到了越来越广泛的应用，有好多新兴语言就是用来做embedded script的。在嵌入的脚本和宿主语言之间，数据可以传递，函数可以相互调用。因为我做的应用使用C++开发，因此我这几天看了Lua和Squirrel这两种用于C/C++的嵌入语言的资料，这两种语言目前主要都是在游戏开发领域使用，Lua比较出名因为魔兽争霸使用了它，Squirrel是从Lua派生出来的。先不考虑怎样应用于具体业务，单从语言本身来说，这些简单的语言给我印象不错，一些语言特征能够给编码带来很多方便，如function作为first-class value，table数据结构(关联数组)，而我特别关心的是它们对coroutine(协程)的支持。

使用通用的script还是自己开发引擎，自定义script格式，这就看怎么权衡了。动态语言的语言机制强大而灵活，其描述能力是自定义的script难以到达的；但是通用、灵活往往也意味着复杂，自定义script专注于要实现的业务功能，往往比较简单，学习难度要低；自己定义script虽然要开发解释器，但是针对性很强，与业务紧密相关，使用通用script还是要考虑怎样来描述业务操作，宿主程序如何提供接口来结合起来，其实要做的事情并不少。

不过我现在对它们的了解还只是很表面，仅仅走马观花而已，观点一定是片面的，还需要进一步的学习。就目前来说，我对使用嵌入语言存在着这些疑问：

• 缺乏OO特性，如果是宿主程序是采用OOD的话，不容易结合起来，我现在已经很难想象一个大型系统如何能够不采用面向对象来实现了。（不过这个还是因语言而异，据介绍某些语言是具有很完善的OO特性的）。Lua支持基于原型的面向对象编程模型(prototype-based OO Modal)，我对这种对象模型是持怀疑态度的，它并不完善，好多OO设计方法都无法实现出来。不过我必须承认我并没有深入研究过，也许还需要多些了解。[见附注]
• 与宿主语言的binding太复杂。不使用class应该还是挺简单的，但使用了class之后就比较麻烦了。使用嵌入脚本，就是希望让开发更简单快捷，如果因此又引入另外一种复杂性，那么优势就被抵消了。
• 怎样将通用的script用于针对性的业务？是不是宿主程序需要以例如API的形式提供一套接口？我现在还没有看到这部分，如果找到一些开源应用的代码来看看应该可以解答这个疑问。
• 性能始终是一个需要关心的问题

 

---

PS. 刚才网上花了不少时间读了关于面向对象的讨论和文章，看来我对于面向对象的了解还是相当片面的，只是局限在C++/Java语言对于OO的实现，而C++/Java是属于class-based OOP，单纯的用class-based的思维去套用prototype-based OOP得到的结论当然不合理。另外一个错误就是我将prototype-based和object-based混为一谈了，其实完全两码事，object-based model则一般不认为是OO。花点时间去了解一下prototype-based OOP和动态编成语言应该是值得的，起码可以开拓思路。

喜欢DIY的人不应该错过这个网站，instructables ，在这里分享DIY的创意，可以看看人家做了些什么好玩的东西，是怎么做的，也可以将自己的经验发布出来。

试过了好几种RSS阅读器，换来换去都感觉总是差那么一点点不够好用。最终还是用回了blogline,简单、方便，这就够了。不过前提是网络的速度够快，好像在国内访问的速度不怎么样，也许又得换了。

2009-5-31 Updated: 现在应该改为“还是Google Reader好用”

最近一年，随着GPS使用者的增加，geocaching开始在国内媒体上有所介绍，也出现了一些相关的网站。但是因为大家都没有多少玩的经验，很多人都只是找过一两个cache，甚至还没有找过，就开始自己藏cache了，对规则的理解也出现了偏差。例如将cache埋藏在地下，找的时候居然要带铲子去挖；为了能让寻宝者知道往哪里挖，就将藏宝地点的照片贴出来。这样，寻宝过程完全变成了单纯的GPS定位，寻找的乐趣都没有了。

我以前也只是找到过一个cache，对geocaching的了解都是在网上看回来的，纸上谈兵居多。在Stockholm玩了一段时间的geocaching后，经验增长了不少。在这儿寻宝很有乐趣，一方面是很多cache都放在有意思的地方，有景色或者有历史背景，找cache的过程中随之了解这个城市，发现这个城市；另一方面是cache藏匿的方法花样繁多(应该是我以前了解得少)，寻找起来很有乐趣，找到后特别有成功感。

感觉有必要将学到的经验总结一下，让国内玩家多了解人家是怎么玩的，开拓思路。先是写了一篇“藏宝指南”，原本打算发到论坛上的，但是想到别人也会有自己的经验可以分享出来，如果贴论坛，就只能发新的帖子，信息就零散了。论坛不太适合用作知识的系统整理，这方面还是wiki比较合适，于是我的计划又扩大了一层：建立一个介绍geocaching知识的中文wiki。

尝试、比较了几个免费的wiki服务，最后选定了使用schtuff.com，wiki的网址是 http://geocaching.schtuff.com 。仿照维基百科，编辑策略也是“人人可编辑”，不过schtuff.com是不允许匿名编辑的，必须先注册用户。License方面也是考虑了一阵子，在CC与GFDL之间拿不定主意，其实关键就是要不要SA(相同方式分享)，最后选定了最宽松的CC-BY。

目前几个主要的条目都已经有了基本的内容，好意思拿出来说了:) 目前为止大部分条目都还是我写的，geocaching.cn的网友贡献了一些内容，期待会有越来越的参与者。不过，我也不抱多大希望，国内网友对wiki的接受程度比较低，参与度就更加低。

如果对geocaching有兴趣，就来看看，了解一下吧。如果认同这个wiki的，帮忙宣传一下：人人可编辑的Geocaching中文指南，http://geocaching.schtuff.com