本章总结：
过去两周断断续续的持续尝试用E3开发，总体体会是：
如果能规避一些常见的编程错误，也就是运行前会报错的情况，E3的体验还是很给力的。我也在尝试总结一些避免常见错误的应用习惯，KavinD也计划让报错机制表达的更加清晰。这部分感受相信会越来越丝滑~
在这段自学的时间里，是我试图在E3上复现一些gh电池的功能，希望在E3上能够复现一套类似GH操作习惯的模块组。一方面这和我个人过往的使用习惯比较贴合，另一方也希望众多的GH玩家在上手E3的时候能够无缝衔接。于是我在第一阶段用大概三周的时间做了这些升级包
说明文档：Tulo.LSO.zip (29.1 KB)
说说核心的感悟，我新写的这些包，主要是在把E3一些底层的面向【Item】变量容器编程的功能块，通过内置打包【创建变量】和【循环计算】的方法升级成了面向【List】变量容器编程的功能块
有了这些包我们就可以丝滑的做一些“算法唱片”了~
说明：文中的【Item】和【List】指代的是一系列配套的输入端为Item或List的运算模块，它们因为输入数据容器类型的不同，导致了在实际使用过程中，建模思维方式存在较大的变化。所以文中【Item】和【List】也寓意了不同的编程思维“流派”。
在实际操作的感受中，面向【Item】和【List】不同的变量容器，图形的编程逻辑思维也是不一样的。面向【Item】的编程思维更像是利用循环套循环的方式逐一处理程序中的单个元素。其思维方式和写代码编程很接近。更加关注编程相关的知识点和编程经验。面向【List】的编程思维则省去了对底层程序思维频繁的思考，能够直接把编程人员的注意力集中在几何逻辑上，也就是更纯净的思考点线面的空间逻辑。
那么如此说来参数化设计师是不是就只掌握面向【List】的工具流就可以了呢？
很遗憾，我实际体验完之后【List】是有局限的，它是被降维后的或者说阉割版的编程，为了更容易使用，强加了一些辅助规则，形成了一定的应用局限。所以现在在诺亚开发团队中，除了我以外是没人面向【List】开发的，都是面向【Item】。
GH是不是面向【LIst】？还不完全是。 GH其实是一套面向【Tree】来编程的思维逻辑，Tree就想当于多维度的【List】。多个List之间通过path被巧妙的组合了起来，并赋予一定定制化的计算规则（如Longestlist法则）。我猜测这也是David看到了【LIst】的局限后再一次给工具流的操作能力升维的思考。
那么【Tree】是不是就是最好的？我不这么认为。 大家知道国内我是第一个总结讲解【Tree】的人，我脑海中的参数化建模思维和Tree是深度绑定的。都就在过去的几周里，给了开发丰富【List】，我对【Item】越来越熟悉，也发现【List】的升维方法可以有很多种，【Tree】只是其中一种选择。所以这样一看，每种可能性都能够开发出一整套的参数化设计软件，它们的应用思维本质一样，但驱动它们的建模思路可能各不相同。面对可预见到的各种应用体系及思维分支，我更提倡接受最本质的，最底层的【Item】工具流。
从产品推广的角度讲，应用越简洁越好，但简洁也意味着局限。 产品的推敲就是在某一个特定的维度上反复拿捏局限和简洁的平衡点。而这个平衡点也会随着应用生态的进步动态位移。
所以我决定会为大家持续的更新这套【List】工具流，让它在处理几何逻辑的时候更加丝滑。同时也会开源其内部文件，让大家可以以此学习如何用【Item】工具流去实现等效的开发。
这套工具我会另行开贴与大家分享：E3开发实例开源：Tulo.LSO（List工作流模块组）
补充几点干货：
1、除了【Item】、【List】、【Tree】以外，还有一个重要的变量容器是【Dictionary】，它是信息模型的基础。【Dictionary】的工具流也是独立成套的，而诺亚第五代开发思想，强调直接对【信息模型】进行几何编辑。其中的信息模型就是一种类似【Dictionary】的【Type】；
2、比较几种工具流操作思维，【List】最容易学，【Dictionary】次之。【Item】和【Tree】学习难度差不多都很绕脑子。【Item】和【Dictionary】组合的体系可以把智能化设计赛道打通关，不需要【List】和【Tree】；
3、所以如果诸位想搞图形算法开发的话，可以用【List】先过渡一下，学起来快，然后就可以直奔【Item】了。