Erlang-China

InfoQ 英文站放出了6月8日在 QCon 上 Joe Armstrong 老头的演讲视频 —— 《Functions + Messages + Concurrency = Erlang》各位粉丝，请点[这里]组团前往围观。

misc

Erlang 的编译检查相当宽松，有时候，会让人觉得宽松得过了头。比如说，在一个模块中调用另外一个模块的函数，如果被调用的函数还没有定义(比如说，忘了写或者拼写有误)，编译器是不会给出任何警告的。如果你看编译没有错误就冒冒失失地运行的话，得到一堆莫名其妙的错误。这通常会搞的人很挫折，而检查这种问题也要浪费不少时间。下面这个脚本是解决这种烦恼的最简陋形式。

需要说明的是，未对输出进行任何处理，能看，好懂，但是相当之简陋，有兴趣的同学，可以自己动手美化之。

misc

转载说明

“Erlang 是动态类型的语言，因而不能进行静态分析，所生成的文档也不包含有助于理解的类型信息”——这是惯常的看法，广为流行，而且被看作是 Erlang 在开发大型系统时的一个短板(大型系统意味着更强烈的静态分析需求和更严重的依赖文档进行沟通)。

然而 Erlang 是一个有着 20 多年历史的成熟系统，它早已发展出了一套自己的类型标注系统，不仅用来生成文档，更重要的是可以据此对源码进行静态分析，通过程序来排除一些低级的和隐藏的错误。在这方面， Erlang OTP 的源码本身及其文档就是最好的例子。在 《Erlang 程序设计》 的附录A部分，对于这个系统的使用已经进行了充分的说明。

需要强调的一点是在 Erlang 语言的背后还有一个活跃的社区(后者更为重要)，其 EPP 过程一直都在持续不断地推进语言本身的进化。这方面最新的成果便是：在 R13 中，将此前文档级的 @spec，@type 标注升级为语言级的 -spec，-type 标注。可以预期的一点是，在未来的版本中，这些方面仍将持续推进。

litaocheng 同学的这篇“Erlang类型及函数声明规格”，风格严谨，论述详尽，涵盖了最新的语言特性，是任何一个程序员想要开发“严肃 Erlang 程序”的必读文档。

Read more…

study dialyzer, erlang, guide, type

警告：本文纯属六一吹水，看客童鞋小心忽悠。

认识我有一段时间的朋友，肯定都在不同的场合分别听到过我对 “实时 Web 应用” 的鼓吹。有兴趣可以翻看去年 “CN Erlounge III” 上的《Realtime Web Application》，今年“Ajax 群英会”上的《实时 Web 应用》以及“BeijingOpenParty ——晚春夜曲”上的《实时 Web 应用中间件》。

虽说俺对于实时 Web 应用的爆发早有心理准备，但在5月31日，第一眼看到 Google Wave 的时候，还是和大家一样，被震到了。一是没有想到，实时 Web 应用还可以这么玩，太 TM 有创意了；二是没有想到，在这个“还没看清怎么玩”的领域 Google 竟然这么快就现身了，太 TM 神速了。(我很好奇，是怎样的公司文化和人才机制才能孕育这么恐怖的创新能力呢?)。

好吧，惊叹就到这里了(拍 Google 的马屁，那是众 G 粉的乐子，哪轮得着我呀)。下面照例，进入咱们的 “超强脱水” 上干货环节。

创新——Google Wave 创造性的解决了“实时”与“非实时”之间的无缝连接

非实时就是 Email ，实时就是 IM ，这两者的用户体验是如此的迥异，以至于此前试图将这两者统一起来的努力均告失败。而 Google Wave 所采用的方式则是老调重弹却又谱出新章的 Version Control —— 一个 Wave 就象是 Wiki 上的一篇文章，是一个有着版本控制的信息实体，被多个 participants (也就是用户)所共享。在这个隐喻下，非实时的访问就变成了“获取当前版本”，而实时的访问则符合“跟踪当前版本的所有更新”(所有的更新都通过实时消息广播给所有的 participants)。至此，让人目瞪口呆的 Replay 功能，也变得极其简单，只不过是版本控制的酷眩呈现而已。

现在看到很多说法，从“将会一统天下”到“未来互联网的基础应用”，等等，溢美之词不一而足。姑且认为这些都是 G 粉丝美好的 YY 吧。无须过渡诠释，咱们抛开 Google 的明星气质和强大的号召力不谈(借助这些， Google Wave 真的有成为 THE ONE 潜质也说不定)。单从“请下神坛”的“低俗化”角度， Google Wave 最本质的创新其实就是 Realtime ＋ Wiki 并在此基础上进行各种扩充而已。有心山寨的各位山大王，从这里开始抄就对了。

技术——基于 Web 的 Realtime 技术，以及有 Google 特色的开发框架

在创新面前，任何实现层面的技术都会显得黯然失色。虽然目前还无缘得见 Google Wave 的 Realtime 实现技术，但大致可以猜出肯定是 Web Socket 或者 Ajax Long Poll 中的一种(很有可能是前者)。从技术层面而言，早已经算不上是新鲜事物了。然而有 Google 特色的开发框架(这个句式怎么听来这么耳熟呢)，仍让人感到新奇。展现层的扩展直接使用了 Gadgets 模式。逻辑层的扩展则直接使用了 App Engine 的 Web 模型。

应该说，这一整套扩展方案充满了 “Google 的味道”，而且，这个模型肯定是能用的。除了 Google 系扩展一贯的稍嫌“重型”之外，唯一让人感到担心的，恐怕是这种逻辑扩展模型的抗压性。虽说使用了批量发送作为两个层次之间的阻抗匹配，但这种方法实际上仍然是将实时性更高的 Realtime 通讯构建在了实时性较低的 HTTP 通讯之上，不知道这会不会带来潜在的问题。

战略——Browser Platform/OpenSocial/OpenStand阳谋的最新尝试

Google 对 M$ 的阳谋就是 Browser Platform 战略，浏览器即平台——管你什么设备，也不关心什么 OS ，只要有一个符合 HTML5 标准的浏览器，走到哪里都是一样的用。无论是 gOS 也好，Chrome 也罢，还有 Google 对 Firefox 的大力支持，所有东西全都围绕这个核心展开。利益攸关嘛，所以，在 HTML5 上 Google 的心急和 Microsoft 的拖沓，也就显得很好理解。而这次的 Google Wave 也没有例外。以超眩的用户体验为“ HTML5 兼容浏览器”阵营奉上自己的 Killer App。民心向背是革命成败的关键，Google 的革命理论学得不错。

M$ 之外，另外一些会让 Google 这样的巨头感到巨头疼的恐怕也就只有 Facebook/Twitter 这一票跟在屁股后面猛追不舍的 SNS 了。OpenSocial 战略就是分化瓦解 SNS 集团的阳谋，但似乎不大奏效。第二梯队的 SNS 始终各怀鬼胎，最起码的 Open Platform 尚且无法贯彻，更进一步的 OpenSocial 缺乏动力也就见怪不怪了(从国内 SNS 对“开放平台”的暧昧态度就可窥见一斑)。因为无法摆平各方利益，技术相当领先的 OpenSocial 几乎快到了要沦为鸡肋的境地。而第一梯队的 Facebook 之辈用户基数则继续保持爆炸性增长，搞得 Google 很是窝心的说。如果说之前的 OpenSocial 是“跟在后面搞破坏”，那么此番祭出的 Wave 则是“抢在前面打埋伏”，而且还摆明了车马，将要彻底开源，欢迎大家山寨。用心可谓良苦，但效果目前还说不好。用户到底是会被 Network 粘得死死的，还是会被 Wave 勾得心痒痒进而纷至沓来，仍然还需要时间的检验。但，计以至此却已然到了尽头，再没有回转的余地；如若不售，后续的手段恐怕只剩下收购一条了。

OpenStand 对于 Google 来说，乃是性命之根本。试想，如果某个“封闭标准”的公司独占互联网哪怕是十分之一的内容，而且不开放内容给 Google 的爬虫(考虑一个充血版的 Facebook)，那么搜索结果的质量会因此受到多大的影响？在这个普通网民都开始谈论“实时搜索”的时代，在底层(也就是通讯协议层)占据一个有利的位置(推出自己的开放标准，或者保证标准的开放性)，对于 Google 这样的公司来说是一件多么重要的事？从这个角度来看，被事先高调宣布的 Google Wave 的 Open Source Product 和 Open Protocol 路线图，无论怎么看都是必须的一步棋。

Google Wave 不是实时 Web 应用的银弹

其实这是一句屁话——哪怕是在某个犄角旮旯的小不点儿领域，这个世界上也都从来就没有过什么银弹。我得承认，说“Google Wave 不是实时 Web 应用的银弹”，完完全全就是为了寻开心。一个软件老民工装出一副思想很深邃的样子，恶心一把装腔作势的软件砖家们，没办法，就是这么低级趣味。

首先，我也承认 Google Wave 眩得要命，客户方的代表看了也会喜欢得不得了，但它完完全全是基于 HTML5 标准的——你的意思是想去说服公司领导，让他们完全抛弃占据市场份额超过 80％ 的广大 IE 浏览器用户么？XD，脑子笨一点不要紧，关键是不要进水就好了。

其次，我知道 Google Wave 提供了 Robots API 很多东西都可以“引入”到系统中，而利用 Gadgets API 又可以“展现”很多东西，况且 Google Wave 本身还会开源，哎呀，简直太好了，我们可以在 Google Wave 上架构我们的系统，既省钱来又省时间，这下终于有时间去泡妞了……。喂，醒一醒，XD。我们真的需要把我们的应用嵌入(接入) Google Wave 以获得 Realtime 特性，而不是相反？尤其是，当我们的应用并不像个 SNS 或者“协作系统”的时候也要如此？好吧，算你牛，非得这样，那，咱们项目组要不先回家待岗，等它出来了咱们再回来上班？

再还有，协作隐喻能够覆盖所有的 Realtime App 需求么？这是一个根本性问题，要不，咱再想想……？

干货上完，现在上水货。地址在[这里]，各路水神水仙纷纷出动，精彩得紧。不要问我这水到底有多深，你自己下去探探不就知道了。;)

misc