文章目录
本周我们在 CodeLab Adapter 里基本实现了 Linda 并发模型，没有采用Linda 初始论文(1986)的策略，而是采纳了 Alan Kay 今年年初接受采访时提到的想法: “在对象之间 协商 意义，在 pub/sub 中实现它”。
Linda 是 CodeLab Adapter 4.0 的基础，不久将发布。 有了 Linda，我们距离 Bret 在 Dynamicland 所构建的基础架构已经不远。
我们将 Linda tuple space 实现为 server，在技术层面，它是一个 Adapter Node，内置在 CodeLab Adapter 之中，可为任何 Adapter Node 提供 Linda tuple space 服务。
如此一来，在空间中协调不同事物（object）变得极为简易，这鼓励编程者大胆去想象，让事物随意去 talk ，而不必担心会被连接和协调的复杂性压垮（多进程/线程和状态共享是个灾难）。
完成度
我们目前实现了如下原语:
- in
- inp(非阻塞)
- out
- rd
- rdp(非阻塞)
- eval(使用宿主语言里的多任务(进程/线程/协程)机制，暂不实现 eval，除非未来要构建类似 erlang 的东西（从错误中恢复），才考虑实现 eval)
我们还构建了一些辅助工具，这部分是我自己的扩展，与 linda 原始想法无关，用于控制 linda server。
我已经完全习惯了 smalltalk 的开发方式: 随时去增强开发环境，这些辅助工具帮助我开发 linda 本身，它们让我方便与 Linda server 对象沟通。
- dump
- status
- reboot
实验
以下是我们测试 Linda Node（它们扩展了原先了 AdapterNode 类）时的截图：
这个项目演示了两个 Adapter Node 的通信。
我们分别在 AdapterNode 和 AdapterNodeAio 里都实现 linda client，所以你也可以在 Python 异步代码中使用它。
使用原先的 AdapterNode 也可以做到这些，但不够优雅，而且内部实现复杂，复杂往往是可理解性和可生长性的敌人，linda 十分简单，采用 linda 之后，对象之间协调的变的惊人简单，这让 Adapter 可以进一步生长。
我最近处在 Alan Kay 的巨大影响之下: 用生物学视角看待软件。
性能
以下是一个大概的测试结果（2.3 GHz Intel Core i5）
在单一节点上，当ZMQ_LOOP_TIME为默认参数(0.02s)时
- out/in/inp/rd/rdp: ~30帧/秒.
影响性能的主要是PUB/SUB的速率（数量级的影响），而不是机器本身的性能，所以在树莓派和高性能笔记本上，差异不大。
如果想提高linda通信速率，可通过修改 Adapter 的 ZMQ_LOOP_TIME 配置参数，ZMQ_LOOP_TIME 越小，linda通信速率越快 当 ZMQ_LOOP_TIME 为 ‘0.001’时，速率为 306 帧/秒。相应的代价是 Adapter Node 会占用更多CPU。
注意: Scratch中帧率稳定在30帧/s，如果逆向提高帧率，在 Scratch 并行操作即可。
问题
in/inp 原语， 没有遵循 CQRS原则（Scratch 拓展最佳实践 – 以 Cozmo 为例）。
未来
近期我们将基于 Linda 在 Neverland 2 中构建若干 demo。 采用 smalltalk 的迭代周期方法论: 在系统中构建应用, 以便于获得对系统的直观感受 ,并据此观察和迭代系统。
在未来， 我们可能会将 Linda 剥离出来，分享给社区。
近期内我们将完善不同语言的 client， 目前 python client 最完善的，我们正在实施
- 系统调用 client
- JavaScript client
- rest api/http client
如果你想在 smalltalk 中使用它，可以先与 Python 互操作。