adoal

@kuanat 说起来，见识过 OSC 52 的效果之后，再也看不上 :set paste 了

建议标题改为“PC 二奶机我要坚定地选 arm ，欢迎 x86 铁杆粉来反驳，反正我也不接受”

有没有可能，让你觉得卡顿的，不是真卡顿，而是基于单元格的滚动导致的跳跃感

AI 比较容易搞定从青鸟/达内/蓝翔/etc 出来的转码程序员所从事的工作。

ibkr

至于 eunm 会不会更快，当然是不会。类型系统的完备性，不是为了性能，而是为了有更严谨的数据一致性约束。也就是减少程序的 bug 。但有些人认为这是多余的负担。

数值类型只有作为基数（表示数量多少）和序数（表示先后顺序）使用时才有大小的语义。作为枚举类型的值，没有大小语义。

你可能以为，一个业务流程状态是序数，因为你很清楚流程是一路流转下来的。但实际上的流程，中间可能有分支、回转、跳跃。比如因为有特殊要求中途补付一些钱，比如物流弄丢了重新发货。这里每个节点使用的数字，只是为了把这个节点和其它的区别开，并没有任何大小的意义，所谓的 1 与 2 之间，只是莫某个节点与另一个节点之间，1 不是 1 ，2 也不是 2 。

换个角度想，如果用文字类型来描述，难不成能你也要让业务流程中的每个状态的名字恰好是按字典顺序从小到大？为什么用数值类型你就要有这种追求呢？

我非常讨厌一些互联网行业“毕业”后做信息化的人以及盲目追随互联网布道的原生信息化人。

@BreadBig varchar 也有 varchar 的问题。这个类型在不同数据库上的长度计算单位不一样，有的是字节，有的是字符。