为什么Java不支持运算符重载？
Java不支持运算符重载 = 小白也能学编程
Java之所以不支持运算符重载，并不是如下原因：
- 会使JVM变得复杂、性能下降：君不见C++内置运算符重载的能力？C++的性能在任何时代秒杀Java相信没有争议。
- 便于静态分析、工具化等：一叶障目、不见泰山。运算符重载只是一种动态特性，动态语言的形式化静态分析方法已经有成熟的方法论。
- Java是面向对象语言：Ruby是比Java更彻底的面向对象的语言，然而它对运算符重载的支持非常优秀，在Ruby中一切都是对象，几乎一切都可以override。
不支持运算符重载的根本原因，是源自James Gosling设计Java的初衷：那就是要让Java的学习门槛足够低，这样才能让这个编程语言被更多的人使用，从而拥有最大的市场占有率。
Java诞生之前， 基本上是C/C++的天下。光C语言的一个指针，就吓退了多少莘莘学子？C++引入更多的动态特性：多态、多重继承、函数重载、函数重写、运算符重载、泛型……这更不知道让多少人望而却步！
正是在那样的大环境下，James Gosling才萌生了“开发一个小白都能上手”的编程语言的念头。
运算符重载的底层思想并不是面向对象
运算符重载的底层逻辑来自函数式编程。它的祖师爷是Lisp，一个“从来被模仿、从未被超越”的神级语言。
可以负责任地讲，如今流行的Python、Javascript、Typescript、Go、Ruby、Haskell、Scala、Groovy等，在动态高级特性上都是在不断模仿60多年前的Lisp。包括Java从诞生起就在鼓吹的垃圾回收等优点，全部都是“偷师”Lisp。有兴趣的小伙伴可以自行下载Lisp的发明者——John McCarthy老爷爷1960年发表的GC论文。
函数式语言的核心思想其实是数学。
说得更白话一点：通过数学表达式描述问题，而不是人肉模拟解答过程。问题描述完了，也就解决了——运行时处理执行细节。
说得更学院派一点：通过无状态的函数加以其他优化特性，将这些函数组件进行拼接。
看到这里，估计有不少人要来拍砖：运算符重载看起来那么复杂，明明可以定义方法或者函数来解决，除了装逼格，没有实用价值。
笔者这里回应一下：数学本来就不是普通大众擅长的，数学的目的就是用最简洁的方式来解决最复杂的问题。所以函数式语言从诞生之初，就没有想过要芸芸众生。它追求的是大道至简。
这里来看一个例子：计算一组数据（假设放在一个一维数组中）的标准差。
如果不采用函数式编程，采用通常的面向过程或者面向对象的编程范式，那么只能：
第一步，先通过循环体（for/foreach/while等），挨个遍历求出平均值mean；
第二步，再来一次循环，挨个求与mean的差值并平方，然后逐个累加得到平方合sumOfSquares；
第三步，对sumOfSquares调用平方根函数，求出最终值standardDeviation。
下面我们来进化一点：
有基本函数式编程概念的小伙伴可能会写出如下的简化范式（这里以Ruby为例）：
mean = a.inject {|x,y| x+y } / a.size
sumOfSquares = a.map{|x| (x-mean)**2 }.inject{|x,y| x+y }
standardDeviation = Math.sqrt(sumOfSquares/(a.size-1))
但是真正的函数式编程高手是会这样写的：
第一步：写一个通用的数学意义上的复合函数（f(g(x)) = f*g(x)）的表达：
module Functional
def apply(enum)
enum.map &self
end
alias | apply
def reduce(enum)
enum.inject &self
end
alias <= reduce
def compose(f)
if self.respond_to?(:arity) && self.arity == 1
lambda {|*args| self[f[*args]] }
else
lambda {|*args| self[*f[*args]] }
end
end
alias * compose
end
第二步：把计算标准差所需要的各个元素的数学表达列示好：
sum = lambda {|x,y| x+y } # A function to add two numbers
mean = (sum<=a)/a.size # Or sum.reduce(a) or a.inject(&sum)
deviation = lambda {|x| x-mean } # Function to compute difference from mean
square = lambda {|x| x*x } # Function to square a number
第三步：像写标准差的数学表达式一样，一步到位：
standardDeviation = Math.sqrt((sum<=square*deviation|a)/(a.size-1))
总结
Java之所以流行，并不是因为其语言设计得最优秀，相反地，在很多地方——比如泛型、Lambda、完全面向对象等设计上都存在不足。它的成功在于：扬长避短，把所有牛X的高级语言特性在一开始全部都抛弃，留一个最小核，然后通过营销，大规模地培养本语言阵营的程序员，建立各种各样的“轮子”，成就了巨无霸的生态；在站稳格局之后，慢慢地再逐步添加回来一些以前抛弃的其他语言的优秀特性——这是一种比较实用的策略，但是带来的恶果就是：历史包袱比较重，导致新特性很多时候是“半残”的。
回到运算符重载本身，对于高手，可以利用该特性写出极具“魔性”、接近数学语言的代码，这样的代码可以体现“极简之美”——但是，一个不利影响就是：数学不好的小伙伴，不容易看得懂，也很难体会其中蕴含的“数学之美”。
1) 简单性和清晰性。
清晰性是 Java 设计者的目标之一。设计者不是只想复制语言，而是希望拥有一种清晰，真正面向对象的语言。添加运算符重载比没有它肯定会使设计更复杂，并且它可能导致更复杂的编译器, 或减慢 JVM，因为它需要做额外的工作来识别运算符的实际含义，并减少优化的机会, 以保证 Java 中运算符的行为。
2) 避免编程错误。
Java 不允许用户定义的运算符重载，因为如果允许程序员进行运算符重载，将为同一运算符赋予多种含义，这将使任何开发人员的学习曲线变得陡峭，事情变得更加混乱。
据观察，当语言支持运算符重载时，编程错误会增加，从而增加了开发和交付时间。由于 Java和 JVM 已经承担了大多数开发人员的责任，如在通过提供垃圾收集器进行内存管理时，因为这个功能增加污染代码的机会, 成为编程错误之源, 因此没有多大意义。
3) JVM复杂性。
从JVM的角度来看，支持运算符重载使问题变得更加困难。通过更直观，更干净的方式使用方法重载也能实现同样的事情，因此不支持 Java 中的运算符重载是有意义的。与相对简单的 JVM 相比，复杂的 JVM 可能导致 JVM 更慢，并为保证在 Java 中运算符行为的确定性从而减少了优化代码的机会。
4) 让开发工具处理更容易。
这是在 Java 中不支持运算符重载的另一个好处。省略运算符重载后使语言更容易处理，如静态分析等，这反过来又更容易开发处理语言的工具，例如 IDE 或重构工具。Java 中的重构工具远胜于 C++。