build block and design tools
distributerl 是最近 google code 上 open 的一个项目，在它的介绍中这样写道：
Building blocks for Erlang/OTP systems using distributed algorithms.
……
Coming soon: generic versioned objects for convenient use with Merkle trees
Coming a bit later: Generic Gossip Protocol
它提供了：Vector clocks, Consistent Hashing, Merkle Trees 这几种分布式算法的 Erlang 实现。此外它还将会提供 Gossip Protocol。
老实说，对于这种后面标有引用论文的算法，我一向都是相当景仰的(也就是说，基本不懂)。在此强烈召唤达人现身，科普一二。但这几个名词的出现频率有猛增的趋势(比如 scalaris 的 pdf, amazon s3 的宕机说明，等等)，因此仍然引起了我的注意。现在的情形似乎是 —— 要是不懂这些大词，看见别的搞“分布式”的，你都不好意思上去打招呼。反正俺是准备知耻而后勇的上去 wikipedia 啃一下英文的了。
与此同时，在 maillist 中也有人正在讨论 Erlang 的 Design Tool。非常好，因为这个问题我已经找了很久，但并未找到答案，若有高人现身说法解我疑惑，那就再好没有了。
关于 design 的问题，我也顺便 blah 一下(当前版本)感想，：
1. 在 Erlang 设计中 UML 的协作图比较好用，能够帮忙理清思路。好多工具都已经“进化”到不再支持这种不是那么 OO 的非主流图型了，如果找不到合适的工具，试试相当老旧的 borland together architect 吧。
2. 用 Erlang 写东西，设计上仍然需要精心设计 API ，也仍然需要在“对象”(或曰进程)“生命周期”的设计决策上浪费大量“生物 CPU”时钟。在这一点上 Erlang 也好 Java 也罢，彼此之间其实并没有太多差别。当然 otp 的 application 或者 gen_xxx 实际上已经在扮演“生命周期管理者”的角色。但，毫无疑问，它的“接口”设计并不怎么“性感”，望之常常让人有“#$@!%*”之感。我在想，是不是也该有个像 Spring for Erlang 这样的东西，把所有“对象”的“生命周期”给管起来呢？
building block for distribute 的通用项目，以及 design tools 的讨论，表明开发者们正在越来越认真的对待 Erlang 语言，这或许也表明大家正从“学习”阶段向“扩大再应用”的阶段转换。
Comments
借贵地问一个问题：
1> X = [a,b|c].
[a,b|c]
2> is_list(X).
true
3> length(X).
** exception error: bad argument
in function length/1
called as length([a,b|c])
X到底是不是List？
上述 is_list 的返回结果为 true 已经表明它仍是列表。但它并不是“格式正规”的列表，所以不是 length 的合法参数。
在用 X = [H | T] 来构建 List 时，如果 T 是列表，那么这个列表是“正规形式”的列表，如果 T 不是列表，那么这个列表就被称作“非正规形式”的列表。大多数的库函数都假定其参数是“格式形式”的列表(比如：length()，还有列表解析语法等)。“非正规形式”的列表不被很多函数支持，但仍然是可用的，如，在模式匹配中：
1> X = [a | b].
[a|b]
2> [X1 | X2] = X.
[a|b]
3> X1.
a
4> X2.
b
thanks, jackyz!!
Write a Comment