有点不太理解这段代码，什么情况下泛型会被擦除，什么情况不会？

有没有了解 Java 这方面的大佬给普及一下知识，我意向是他弄错了，这个问题和泛型擦除无关，Java 8 本来就只有虚泛型，反射的元数据另一回事

emmm 有点不太懂，你说的第一条我看了一会找不到具体的条目所以无法判断

第二条嘛，脚本语言大概就是说... VB 这种会把 Long 看成什么... 的？

不同语言杂交嘛... 我觉得他的意思大概是 FCL（CLR 的 std, CLR 就是 Common Language Runtime）
开始只考虑 C# 语言设计了，有些程序员在 FCL 里创建其他的 CLR 语言（e.g. 基于 DLR 的 IronPython）里不自然的方法名称（如 GetLongLength() 而不是 GetInt64Length()）

CLR 本来就是『杂交』语言运行时嘛... 虽说 CLR 语言不是一个语言，不像某些语言里还能内联其他语言代码一样
但是... 他们都在这个 CLR 共同运行时里运行，所以一些东西比如各种 CTS/CLI 类型是可以共享的，他说的杂交大概是这个意思

e.g. 我们有个 VB .NET 的伪代码

Class Fot
  Private Bar As Boolean = False

  Sub New()
  End Sub

  Public Sub Baz()
    If Bar Then
      Console.WriteLine("Faz")
    Else
      Bar = True
    End If
  End Sub
End Class

C# 里也可以用 VB 的类型

var fot = new Fot();
fot.Baz();
fot.Baz();

泛型擦除就是 class<T> 的 T 只在编译期检查吧

#ai #machl 唉，现在中国小团队的『字典机』机器人，真的不足以称之为『人工智能』
侮辱了人工智能这个名词

顺推 @elepover 的 VB.Net 项目 "意大利炮”

所以，看到了吧？ #learn #CS #dev

我们吹的其实不是什么会几门语言，我们吹的是能看透各种各样语法糖、各种各样范式语言背后真正的逻辑和结构的能力

吹的是能在一周内学会 7 门语言，但不是吹会 Bash 会 Java 会 Kolin 会 Python 会 C++ 什么的
也不是吹什么全栈工程师

吹的是对这类抽象结构的分析能力，吹的是看一眼 VB.Net 代码后就能把 var str = new String() 化为 Dim str As New String() 的能力

吹的不是虚荣，是自信

正如王垠吹他的 70 行代码，吹的不是那 A+ 的分数，吹的是 7 天手写解决别人 20 多年困扰难题的能耐

当然，其实这能力还是非常有限的，推荐学习 Type-level programming

其实我很菜的，大佬不要看我又飘了就吊打（QAQ

#life #tech #PL #Java #Haskell

出去和我妈的朋友吃了个饭，有幸在最后无聊的那段时间里看了看 Wikipedia 的 PL 列表，顺便看到了 Nim、Haxe 这种奇奇怪怪的语言

顺便学了点特性分类的知识（比如泛型和反射）

https://en.wikipedia.org/wiki/List_of_programming_languages

https://en.wikipedia.org/wiki/Comparison_of_programming_languages

防止给别人造成「类型」上的误解是个伪需求，况且这不是 C++，是 C#，类型长度是有明确的标准。难道看个代码发现一个整形变量，我一定要在心中确定它有多长？我知道它表示一个整数不就够了吗？真要深究它有多长，为何不去了解一下相关的标准？

而那个「别的语言因为你使用 long 但是这不是关键字就不编译」很莫名其妙。难道是用某个不用 long 作为关键字的语言的编译器来编译 C# 的代码吗？就算是能内嵌代码，不应该是参照公共类型的标准吗？
假如我用 VB.Net 写的一个程序集里有个参数用 Integer 类型，难道在 csc 眼中它就是叫 Integer，但是 C# 没这个关键字就拒绝编译？这是哪个次元的 CLR？

https://t.me/dsuse/8340

CLR 的标准 CLI 明确是一个无关语言的架构，但是在 Jeffrey Richter（该书作者）的世界里 CLI 是语言相关、一些代码是以脚本存在、没有中间语言

哦，我基本明白了，就是说 C# 就是 using int = System.Int32 这种吧，然后别的语言

... 哦... 我彻底糊涂了... 算了 😶
CLI 还真是乱伦风格... 各种语言纠缠不清的理解起来有点麻烦... 我还搞不懂... 头昏

其实最后你那个

假如我用 VB.Net 写的一个程序集里有个参数用 Integer 类型，难道在 csc 眼中它就是叫 Integer，但是 C# 没这个关键字就拒绝编译？这是哪个次元的 CLR？

我看得懂，其实 Jeff 之前的意思大概是 FCL（就是 C# 的标准库，当然也是 VB.NET 之类的标准库）的某些方法（不得不硬编码进去）的『方法名』『字段名』

里面不可避免的出现 C# 里所定义的类型名称诸如 long e.g. TryParseLong()，（因为那个方法名里的 Long）容易引起误会，因为不是所有 CLI 语言里 long 关键字都表示 Int64

编译到 MSIL 以后呢，TryParseLong 的返回类型值为 System.Int64，但有些语言里面 long 关键字定义的类型却是 System.Int32 可能，所以诸如 Dim foo As Long = "123".ParseLong() 这种可能就无法工作或者不易察觉地不正确

... 总之还是有点头疼.... 看不懂，如果愿意的话不妨让我弄懂了再来讨论一下，毕竟 Telegram 上很少有这种不 trivial 的『无用』技术讨论了

btw. 大佬不妨私聊我，我 +86 的可以随便撩（跑

顺推 #PL #CS #PLT #Learn StackOverflow 这个问题（Soundness and completeness of systems）的回答

Soundness prevents false negatives（假阴性） and completeness prevents false positives（假阳性）.

In modern languages, type systems are sound (they prevent what they claim to) but not complete (they reject programs they need not reject).

Soundness is important because it lets language users and language implementers rely on X never happening.

Completeness would be nice, but hopefully it is rare in practice that a program is rejected unnecessarily and in those cases, hopefully it is easy for the programmer to modify the program such that it type-checks.

Type systems are not complete because for almost anything you might like to check statically, it is impossible to implement a static checker that given any program in your language
(a) always terminates, (b) is sound, and (c) is complete.

Since we have to give up one, (c) seems like the best option (programmers do not like compilers that may not terminate).

— Robert Harvey

我没彻底理解，感觉总而言之，类型检查系统里，soundness 就是让通过检查的程序不可能是突破了类型约束的（但是有些符合约束的程序会被误判为『positive』有问题的），而 completeness 就是让类型系统尽可能『智能』一点，允许实际上符合约束的程序通过编译

而由于某知名的确定性问题否定答案『停机问题』
不可能太做到完美（逻辑上是不可能的）
(a) 编译器（检查器）能得出结果
(b) 实现是 sound 的
(c) 实现是 complete 的.

只能抛弃一个，所以就抛弃最不需要的 completeness 了
Java 8 里泛型的形变就是一个例子，可能吧（也可能不是，因为这类类型理论往往和 Agda、Idris、F* 之类的完全完全不 Industrial 的语言有关

List<Integer> 其实可以是 List<Number> 的子类型（换句话说，List<Number> 类型的容器可以容纳 List<Integer> 类型的值），可是其实不是，还非得 PECS 原则改成

List<? super Number> ls = new ArrayList<Integer>();

Kotlin:

val ls: List<Number> = ArrayList<Int>();

（因为标准库里处理了泛型型变问题）

才 check，不过这貌似是 generics 的 variance 问题，所以可能和这类无关，要想得到更准确的知识得问大佬

"Don't block, Keep Moving!!!" 🏁

#China #life

首先我们说说那个乘公交车『接钱』的问题

通俗地讲就是说你搭公车，结果带的钱不是不够，正好一张大约 5 块左右的整钱无法找开，因为现在公交没有售票员了，只好自己找钱的意思

for example:

小明一人搭公交车，手上 5 元人民币，票价一张 2 元

小明将五块钱投入收款箱，我们认为现在他手上有 2.5 张票，因为票价一张 2 元，半张就是 1 元

首先来了一个现金付款的吃瓜群众，小明对其说明情况后吃瓜向小明付款 2 元购买到车票（其实不是实物，不过可以认为是）

然后又是一个吃瓜，小明又是如是一通，这名乘客向收款箱里放了 1 元钱后给了小明一元钱（来购买另一半车票）。

所以这个问题里我们讨论的粒度实际上是半张车票，或者说，可以把它视为一张车票，不过那样一人登车需要两张车票
然后这个对象我们可以付钱（给箱子、给别人）买，也可以随便卖给别人，就这事。之前我妈教我的，推荐不要使用。
中国人并没有网上说的那么团结，除非是在围观跳楼起哄的时候，怪团结的。呵呵。真棒。

（一转攻势）想到这里的时候我突然悟出『教学半』（教人是学习的一半，或者说，不教人你就只得到了一半知识）

（我好突然啊）

因为教别人需要你对某种知识有更深刻的理解，这种老师才是好老师

如果不是，就会像某本最近很火的前端开发书一样，把分词和预处理、编译和预编译、解析器和解释器都混为一谈...

普通的程序员也可以教别人啥啥框架怎么使用，但只有看破框架层的东西的人才能写出好教程。

好比老师教人植树，不好的老师只看到表象，授人以鱼（树木长势好坏的外观，好比给人编译好的程序）

而好老师看到本质授人以渔（树木长势好坏从它的根部，暗处来判断（透过表象看到本质，透过因变量看到引起变化的自变量），好比给人程序的源代码允许进一步研究扩充）

即使是在讲比较浅层的知识时易学性也比不好的老师高，因为他们真正了解自己讲的事情，从整个算法流程和结构图广度来看都是

最重要的是好老师一般都是好学生，他们知道如何学习最好，效率最高
哪些方法自己理解的快，哪些表示方法理解慢容易混淆误记，所以他们拿捏得当，教人起来也更为游刃有余一些。