我以前觉得 ECS 是 OO 发展的终极形式，因为 OO 仅考虑了对象有什么属性，ECS 还考虑了视角的问题，即同一份属性在不同人看来是怎么样的

这些称作计算器语言更恰当，定理证明器是什么样的可以参见 https://ruby-china.org/topics/41265 或者 https://leanprover.github.io/ 。

现实中的例子就是把数学证明写成代码，然后用计算机验证。定理证明器只能通过搜索来找证明，搜索空间不会太大，因此自动并不是重点，重点只是验证。

数学非常关心数据类型，类型决定了性质，同样一个数字 1，在 mod 5 和 mod 6 的意义上是不同的，前者是域可以套用线性代数，后者就不行。所以数学里取一个数字都会写 let n ∈ N，let n ∈ Q 等等，这些就是数据类型。数学的未来反而是迁移到由更强大的类型系统支持的定理证明器上，这样才能用机器验证证明，并且构造一个可靠的数学知识库。

支持，代码用粤语读起身好过瘾

js 有 proxy 之后能完全实现 ruby 的元编程功能，decorator 甚至可能比 ruby 更方便，rails 难抄很大部分是 codebase 的复杂度，但是这个复杂度即使是今天的 ruby 程序员也未必当成值得骄傲的事

如果按 review 活跃程度来判断 offlime 其实未必有什么问题

人是计算机，那么做菜的时候装载的程序是菜谱，跳跃的时候装载的程序是物理定律，读书的时候装载的程序是书中的推理

支持，我可以来搬砖

谢谢各位，我研究一下

发个 pg 的

如果说的是正常 html 转这个，很容易弄出转换器，如果说的是普通缩进，那 python 怎么贴就怎么贴

mint 看上去不太好看，简单看了一下，mint 的 connecting store 类似于 react hooks，而 store 内的状态更新则接近 svelte，我猜测它是有响应式设计的。但是 imba 是没有响应式设计的，参照楼顶更新的内容。

一个 fun fact：svelte 是参考 imba 做出来的 https://gist.github.com/Rich-Harris/0f910048478c2a6505d1c32185b61934

可以用 set_trace_func 获取外部 binding，然后 eval

ruby2.7 开始已经去掉了

机翻？

100.times do
  long_str = "a" * 10_000_000
  sleep 1
end

仅仅执行这个内存使用是很稳定的，我觉得如果有问题的话应该是 rails。还有就是之前用 development 来跑一个小项目，大概几天之后就会非常卡，production 没这个问题，当时没细究但是也有可能是这个环境差异

英语写作可以扔去 grammarly 过一遍，比较有利于提高

结构化编辑器（例如 MPS）就可以做到，不过是不是比原来容易写（大概率不是），是不是比原来易读（一半一半）

雾雨 灵梦 斯卡雷特

理论上可以只分发 yarv 字节码

关于下拉一半的问题，翻了下源码，你可以自己判断加载的时机，然后用frameElement.delegate.loadSourceURL()来手动触发 frame 的加载

第一个真是太黑科技了

turboframe 在用 src 加载的时候，会读取对应 url 的整个模板，但是只会用到其中 frame 的部分，这样会造成无用的渲染。但是现在 turboframe 并没有专用的 format，不知道以后会不会加上，虽然直接在 param 里面区分一下应该也可以。

我个人的体感是 ruby 基础教程是垃圾，比较好的是 ruby 编程语言，封面是雨燕的那本，虽然老但是好。一个有用的观察是尽可能看语言原作者写的书，例如 c 就看 k&r，erlang 就看 joe 的，老从来不是什么问题。

crystal 的教程里教了多用栈少用堆可以写出跑得快的 benchmark2333333

只有没钱的公司需要换语言，有钱的公司只要堆机器就好，换语言是公司能力不行的体现

🐂🍺

Pry 里用$可以直接看