JVM 连真泛型都没有

反正第一点的就是，我看代码，我只需要大致明白该变量是什么（是数还是字符串）

没必要就这个时候对变量类型理解到细致

我就无法理解 JR 到底在想什么

毕竟他是非常吹毛求疵的，后面有一段他还吐槽 FCL 开发人员没有捕捉 OutOfMemoryException (可能叫这个名字)之类的东西，只是因为用到了 new 操作符

其实软件工程做久了大概都这样... 没办法

第二点的就是更匪夷所思的

为什么我类型用 long，别的语言下用我的库会认为是不是关键字就编译不了

你可能理解错了，他的意思貌似是说会导致方法名和变量容器名称的不统一，就很难受

long n = "12222".ParseLong()
如果这个 long 是 System.Int32 就可能不能正常编译

只能 long long n = "12222".ParseLong()
造成了视觉上的不统一

绝对不应该出现符合 CLI CTS 却不能用的情况

那问题就在于「In fact, most languages won’t even
treat long as a keyword and won’t compile code that uses it.」这话的意图

那就只能理解为是『使用类型的人』不能用 long 这个 typealias 而不是定义类型的人不能使用，或者说使用会导致其他没 long 的语言里不能使用被定义的类型喽（

简单说，

|a... keyword and won’t compile code that uses it.

这个 code 是说语言『A』的代码，而不是已经编译好的 MSIL

我就觉得，如果要把用 A 语言实现的代码用在 B 语言，那些不是公共的东西我不应该去找 AB 之间有什么等效的可以替换吗

可惜 CLR 开始设计的时候没有考虑这么多啊... 现在看来大概也没有办法了吧

于是就产生了 C# 主义，于是 CLR 就成了 C# 的 JVM

就他可能的意思就是，你在 A 用 long，你在 B 也要写成 long，但是因为 B 不支持无法编译，这就是你的错

（毕竟 CLR 是为 C#、F# 而生 hhhh

所以你应该用 AB 都支持的 Int64

那他的错可能就是没有考虑到一些类型或者成员不需要导出喽（

完全用这种方式的确有点走上极端了

有点因为车会撞死人所以就不开车的意思

所以这段我是觉得莫名其妙