其实泛型的多态方式不算仅面向对象吧……
Java 的泛型约束比 C++ template<> 大很多，对 C++ 模板 T 里 typename T 怎么换都可以，内部代码 T x; 后 x 上可以用任何操作，包括访问未知字段和方法，而 Java <T> T x; 后 x 实质 extends Object ，仍是有检查的，并不能施用任意有效语法；所以它类型错误消息不会有 C++ substution fail 那么长。

老实说 JVM 和 cpp 运行时相差很大的，并不是说支持了泛就有可移植优势了，你看现在 app server 也没几个人敢操刀移植的型（何况Java主力实践最多是有 Collection java.util 需要泛型避免 typecast ，而应用几乎不需要泛型）

然后 cpp 模板展开的开销的确比虚表高，但前提是 class 确实有用 virtual member 暴露未定实现的方法定义，才需要虚表做运行期方法版本选择，普通的派生不是 override ，并没有虚方法调用开销。

perl 完全就是文本处理「脚本」语言的代表，和 Java 没有可比性；泛型写的代码难读我觉得不是很准确，尽管 primitive/boxed Array 产生了很大问题， List<E> 是远远比 IntList 等一大堆东西符合程序可读性的。

虚表是为了这种情况产生的：
class U{void run();}
class A extends U {void run(){/*impl a*/}}
class B extends U {void run(){/*impl b*/}}
然后 U obj = rand()>0.5f? new A() : new B(); obj.run();

也就是 ((U)obj).run() 「可能」是 A 或 B 的实现，才有 virtual 一词的意义；单纯 override 但 U 只有 A 一个子类的话， U.run 实现有唯一性就没有 vtable 或 fat pointer 的说法；这种多态反而是对直接 if instanceof A/B 的优化。

对 Java 而言任何非 final 方法都是虚方法，但是 VM 有专门的CHA 继承树优化，不必担心什么抽象度开销的问题
就是动态性(duck typing)和类型安全性兼顾，只是要看你会不会面向对象设计了。

你这就是对函数式有偏见了，首先 JS 目前 declarative 化进程是非常实用的，和 Haskell,Scala 那一档完全出于不同的目的

其次泛型就是泛型，和函数式(大点说定义式编程)有什么关系？自信点吧，别总觉得别人装逼(ー_ー) 只有你去做他们做到了的事，才能理解他们。

对于 C++ stl (stdc++ .hpp) 我还是很欣赏的，尤其是 ptr iterator ，只有懂算法的人才能明白 back(), push_back(), insert() 这些动词组合里的语义优雅性，你没接触过自然觉得 push pop / add remove 才香。

Boost 和 C++ stl 设计范畴根本不一样，他们爱玩元编程被别人吐槽我不洗，但是这也并非无意义的。
Javaer, Pythonista, Pythonic 之类的概念我觉得就是从 web 网红界吹来的歪风，你看他们哪个不是学识浅薄但总爱企业级理解的⊙︿⊙。偶尔还设计出程序流程、数据存储架构安排不当，只有花皮没内涵的东西，比如 npm 。

我就是喜欢泛型，你不想写类型参数可以用 Ruby 啊，但你肯定还是逃不掉函数值(局部变量集的程序闭包) 的吧

不然你真的很难设计出无冗余的程序哦，只写 class 和应用层无泛型类的话。

可以把 err 重定向到 out ， bash 里可以 echo wtf 2>&1 实现， java.lang.Process ? 就不知道了
但是 lang.Console 好像是能设置啥 handler 的，javap 可看一下

顺便提一句这个本质上是在 native 层启动进程少调 Java API ，要 exec() 是肯定的

看看隔壁 Golang interface{} 满天飞的代码你就知道没有泛型会有多痛苦了。

另外 C++ 的模板（泛型）实际上是像宏那样将模板参数直接代入， 在代入时是不检查类型参数是否合法的（就像鸭子类型）， 是在展开之后才检查代码能不能编译通过， 这使得与模板相关的错误可以变得非常难以阅读 （ C++20 加入了 concept ， 支持对模板参数施加约束， 缓解了这个问题）
而 Java 的泛型是在编译时辅助类型检查， 在运行时擦除+类型转换。
两者差异还是蛮大的。

也只有 C++ 能做模板元编程， Java 没这种 feature 。。。
使用泛型的 Java 代码还是非常易懂并且容易维护的。。。

List<?extends Object> 感觉比较没意思吧.. 其实就是 List get,set:Object 的裸类型
轻松一点： list.add((Object)123); int x=(Object)list.get(0); ，这样不方便。
严苛一点： ?extends 相当于 Kotlin 的 out ，是有子类型兼容性的(即 P<T1> extends P<T> )。如果 List<?extends Object> xs = new ArrayList<Integer>(); xs.add((Float)0.1f); 就完蛋了，假设 xs 是作为函参定义的话。
这里正确的做法是用 boxed 的 List<Integer> ，也不能是 List<?extends Number> ，除非你保证不会 .add 或 .set。

这种情况(破坏 type constraint) Javac 抖机灵不让你 add() null 外的值，从某种意义上它也是有 in/out 检查的，只是语法太烂。
之所以 List<T> T=Any 或 Int 仍能用是因为 ArrayList<T1>() 的 T1是自动推导的，不存在子类型兼容问题。

嘛，我觉得这个作为面试题有点过分了。作为普通程序员，用 Kotlin 就能解决所有问题（逃

其实类型参数擦除是仅对虚拟机和方法体而言的…… 对编译器类型检查它是透明的。