@kkkiio 是的 变量相关的信息现在全部放在 env 里面了 ，env 持有者结束之后 env 就结束了 env 是一个树形的结构

还可以中文编程
```
(
(define 定义 define)
(定义 定义函数 defun)
(定义 显示 display)
(定义 换行 newline)

(定义函数 打印 (打印的字)
(显示 打印的字)
(换行)
)

(打印 '你好 中国')
)
```

@zagfai 谢谢

输出流的的输出位置调整一下即可

@summerLast 内存空间连续的

@3dwelcome 数组是连续的，计算机架构里面有用空间换时间的多级 cache ，整块的空间更容易被 cache 提高命中率，其中的关键是 cache 和 内存的访问速度不是一个数量级,数组更容易被 cache ， 如果没有 cache 或数组较大时链表插入更优秀

自己定义格式有什么好处吗？

java 和 go

lisp 与 c

个人认为是 js 之前的模块管理的概念很弱化，很多都是三方的，import export 语法也是 ES6 开始使用的，而之前前端组合大一些的项目应该也多是面向页面 而非是封装组件 组件在组合成页面 组件模块化的概念教弱，而且前端这几年变化也确实挺快的，最佳实践有的时候是和特定框架 特定版本有关的，所以不必过多纠结，先默认使用官方的脚手架，后面有了自己的领悟再去寻找最佳实践。包和组件化与模块化是将大问题分解成若干小问题人为抽象出的概念，其实还是没有跳出 目录 文件 的概念

为什么 i 调大会发现基本上所有线程都出现的原因 有两个:
- 1.并发一种是硬件上的实现 并行，一种是软件上的实现时间片，而后者既然是时间片就牵扯到上下文切换，如果单个线程执行的周期小于上下文切换的周期，那多线程反而有时不如单线程快，比如 1：4 的关系 1 个时钟周期执行任务 4 个时钟周期执行上下文切换开四个线程反而没有一个线程要快，这也是为什么会看到并不是一个任务切换一次线程的重要原因，也就是线程执行并非是有序的，就不能按有序的思维去看待;
- 2.另一个原因是 如果一个 MyProducer 线程执行完 10 次会出现什么情况,显然并不会再去调用 producer 方法 那既然不调用 producer 方法 log.info 又怎么会打印呢

```
public void run() {
int i = 10;
while (i > 0) {
waitAndNotify.producer();
i--;
}
}
```
i 调大一些

核心是每个元素并不是第一个是第一个线程第二个是第二个线程，产生的第 n 个元素并非是 n%20, 线程的执行并不是有序的，所以并不会均匀分布，这里你可以对生成者的 list 进行改造 如 List<DataInfo> DataInfo {threadName,num}再看一下打印结果

32 楼给了思路，还有另一种方式 就是 能否 100w 分批查 与分批计算，否的话就让对象尽量的小 而非有过多冗余信息

@shintendo : 文章或项目还真没有留意到，个人的看法是控制好抽象的层数和命名，关于为什么是 7 层以内，最好是 3-4 层 往下，之前看过一篇刘未鹏老师的文章，讲到了一个工作记忆(其实我们意识的窗口很小，我们的工作记忆只能容纳寥寥数个条目)，
```
人在思考一个问题的时候，就像是在黑暗中打着电筒往前走（事实上，我们的工作记忆资源是有限的，有研究证明我们只能在工作记忆里面持有 7 加减 2 个项目；此外认知负荷也是有极限的），每一步推导都将我们往前挪一小步，然而电筒的光亮能照到的范围是有限的，我们走了几步发现后面又黑了，想到后面就忘了前面的，想到某个分支上去就忘了另一个分支，我们常常想着想着就想岔了，想岔了也就罢了，问题是一旦想岔了太远，就很难回到当初岔开的地方了
```
还有另一点是用好聚合和管理好代码的正交性，前者聚合是一种代码关联性比较强的关系可以放在一个包下，名字如 Todo ，TodoItetm 放在 todo 包下然后放在业务模块包下，这里 TodoItem 的创建依赖 父节点 Todo 是否创建；后者正交性则是我们理论上能达到代码复用性的最好状态，不依赖具体的父节点，如 Input button 这种 ，也就是一个函数具体实现的改动对另一个函数造成的影响要尽可能的小最好是无，而强依赖性显然会增大影响，写代码没有完全正确的模式，写的过程中慢慢找到“对就是这个感觉”，祝渐入佳境。

@lancelock 哈哈哈，这就是楼主为啥混乱了，数组 字典 明明是一个写法啊

不是邪教做法，没有什么缺陷，只是会增加逻辑的层数，抽象并非越多越好，只要是方便理解就可； vue 的单组件本质就是一个生成代码的模板,Composition API 之前 好像是 vue2.6 之前，复用手端有组合 、混合但粒度比较粗，最细的粒度就是函数了，这也是 Composition API 出来的原因，至于 Composition API 是只有 js 还是 html css 都包含，我个人站前者，原因是后者那样其实又回到了组件了 逃 （但是只要利于理解也没关系，但是会混乱，越简单越好）；所以 Composition API 也好，混合也好，继承也好，代码写出来是给人看的，只要容易理解易于维护就好。个人认为 Composition API 层数最好要控制在 7 层以内，最好是 3-4 层 往下。

对于这个语法糖 还是站 json 的写法，原因就是 当用数组'[]'时习惯的期望值是内存的连续空间 ，而使用结构'{}'时则更倾向与离散空间, 这个语法会导致思维的负担

@summerLast 0 1 2 解释器自动填充，一个语法糖罢了，但是好像这个玩意也可以做成结构的载体 可以做成数组的载体 至于底层内存分配是连续的空间或是离散的则被屏蔽掉了，用起来简单了，但也让楼主分不清为啥这样了，哈哈哈哈