同理 JVM 系也有这样的

JScript 倒是一个不错的例子，说的也是 JVM 上动态弱类型的也有

总之还是纠缠不清... 算了，因为我虽然基本知道你想说什么，但不熟悉 CLR

我是 JVM 还刚刚入门那种

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