别提代码风格，看看解决了什么类型的问题吧

要命。有什么好处呢？总是赢，不肯选择和接受别人的观点
我要是一直这样，走不到今天

一句话不说是最好的，闷声发大财
人们总是选择相信他们相信的东西，排斥不相信的东西，连看都不屑

即便三年前的我也知道要想改变一个东西，你得先融入它，证明自己懂它，才有资格批评它；
现在我看见别人对他们讨厌的东西，选择屏蔽掉，视若未见。

很多人在意的根本不是真理，他们并不希望让自己拥有更好看且可移植、定义式、高性能的编程思想/代码风格，只是简单地不愿让自己一直相信的东西被破坏罢了，就像中国一些只想着怎么讨好上级，不认真对待问题的人一样。

可惜不破不立啊，不探索怎么知道怎么做、合不合适
刚刚与我谈解释器等语言工具里不方便用全名的群友，是否知道我目前就正在用 Python 写一个支持宏展开的项目生成工具呢…… 😒
我举的例子也是一个完整、支持调用局部作用域、 Kotlin Multiplatform 的解释器，虽然还没有惰性求值调用这样的功能，控制流都实现了，他怎么不结合评价下呢

回来看看才发现这居然是红姐本尊啊…… 才发现😓
既然这样她在这个领域就有发言权了，而且她也有权说自己是无敌的，我菜鸡
是我没发现是红姐，就当成小白了 :(

我不敢再提建议了，只加个注释： n 和 name 的问题是红姐在一（ mulang 重写？）里实现 lambda lifting (noname->named, lift to def scope) 时出现的，记得当时我在 @dsuse 提过，没想到现在真人回复，被我当颐指气使的小白怼，冒犯了

但是呢就是，大佬和小白在与人交流上真是有共性…… 我分不出😥