写在前面的一点小吐槽、一点杂感
学 Haskell 学了一段时间之后，虽说拿他来写东西还是完全不行，但是看别的语言特性时，总是会带着一种“诶，这玩意在哪哪见过”的蜜汁既视感。且不说几乎成为现代编程语言标配的 Lambda 、闭包，就是 Monad 都有不少引入了。
这段时间，出于学校项目需要，又在学习 java 。不知为什么，感觉看起 java 来真的是格外的蛋疼，觉得这玩意语法和某些特性的设计简直是糟糕，整洁度和美感还不如复杂和妥协的 C++，更别说以语法优雅著称的 C#。
虽说自己水平渣，但是这样一门满是历史局限性与不优雅的语言，网上不少 java 程序员倒是对这个饱受诟病的语法、api本身一股迷之优越感，完全不知道到底是不知道还是仅仅不想承认 —— java高占有的关键 —— 设计思想符合当时的时代进程、社区化的成功、当下的路径依赖。
到了什么程度呢？大名鼎鼎的《java core》作者，在书中都对其他的语言有一些优势（有些甚至 —— 个人认为—— 并非优势只是设计的不同）就大加赞扬，而对被对比方字里行间饱含嘲讽。而对 java 设计缺陷就不甚明显的提一下。
几个例子
一次编写，到处调试（误）
混乱的标准库设计
难用的时间、日期库
孱弱的以擦除实现的泛型系统
偏执的完全不加入隐式类型声明
只能传值、不允许运算符重载（这两个见仁见智）
Linq（后文将会讨论）
不支持拓展方法
没有部分类，导致的写 GUI 自动代码生成蛋疼至极
throws
final – sealed
final – const （说实话你 final 不就是一表层 const 么）
delegate （java core 作者说 java 的 method invoke 比 C#的 delegate 更好，完全不能理解）
没有原生 tuple，pair
其他语法糖的缺乏（如await\asyc）
当然其它语言也有各自的不足，这里只是提这些来印证前文
语言明明只是工具，是为表述思想服务的。如果说像《java core》作者这样一门语言的布道者尚可说是怀揣着对自己工作的热爱，是可以理解的。某些明明是格局有限或者单纯跟风的人，只能说是可悲了。
就杂感而起的 java8 Streams API 与 C# Linq 简要对比分析
起因
前段时间给某位老师写一个系统，api 路由是 node 实现的，一不做二不休干脆全上 node 了。因为要求数据安全，不敢用 mongodb，遂上 mysql，又因为需求不是很复杂，没想那么多就直接裸写 sql 了，写得简直了，既丑又容易给注入…… 写完之后才想起来为啥不用 ORM，看了看，那几个火的 ORM 库要不太大，要不文档太简陋或者相当于设计了一套自己的sql方言。这时候才怀念起c#的linq，太好用了。
项目暂时告一段落后的现在，因为在学习 java 的、听说c#、java的相似性高的缘故，想要在java中能找到类似的。就在希望快要转为失望之时，看到了这篇文章。
LINQ一直是.net程序系统中的一个非常棒的东东. Visual Studio 2008 已经引入了lambda 表达式和monads, 而同一时间Java6版本还在讨论要不要去掉泛型数据类型. 这一成果要归功于荷兰计算机科学家Erik Meijer, 他已经全停止掉别的项目. - Java的现状? 即将要发布的Java8和JSR-355,我们还需要LINQ?在过去的十几年中人们一直在尝试用LINQ给Java带来性能的改良。当时,Quaere和Lambdaj似乎在研究一种很有前途的库（非语言级别）. 事实上,StackOverflow上有很多Java的使用者提出的有没有与LINQ等价的Java做法(到现在依然) : LINQ的Java实现? LINQ的Java工具 Java中有跟LINQ类似的东西么? Java等效LINQ和实体框架是什么? 有趣的是, "LINQ"已经发展到EL 3.0版本了!<br> - 我们真的需要LINQ么? LINQ的高级特性存在重大缺陷, 从我们角度看来, 将会导致 "next big impedance mismatch". LINQ来源于SQL,这不是一件完美的事情. LINQ流行的LINQ-to-Objects,在.NET下是一种很好的查询方式.Haskell或Scala的成功已表明,真正的函数式编程可以忽略SELECT,WHERE,GROUP BY, 或者HAVING等来进行集合查询。他们使用"fold", "map", "flatMap", "reduce",来获得更高的性能.另一方面LINQ用 "skip", "take"使用混合式GROUP BY(不是OFFSET和FETCH). 事实上, 没有一种函数式查询方法可以超越那老旧但好用的SQL外部链接, 分组设置,或 框架窗口功能. 这些结构仅仅是一个SQL开发人员希望看到的结果的声明。他们不是自足的功能，这实际上包含在任何给定的情况下被执行的逻辑。此外，窗口功能，可以只用在SELECT和ORDER BY子句，这是一种明显声明方式，但是如果你没有SQL上下文这也是非常奇怪的。具体来说，SELECT子句中的窗口函数采用正确的数据预取影响整个执行计划和索引的方式。 相反，函数式编程可以在内存中就做到SQL的这些功能。使用SQLesque API 进行集合查询是用函数式方式狡猾的欺骗 了"传统"的人。这样的实现方式是不能将集合数据与SQL表查询的数据合并在一起的，也不会产生预期的SQL查询结果。 - 我该如何做? 相当简单，你如果使用SQL，你就有两个基本选择： 自上而下,专注你的Java模型. 使用Hibernate / JPA查询并且使用Java8 Streams API 转化Hibernate的查询结果. 自下而上,专注你的SQL关系模型. 继续使用JDBC或者jOOQ, 使用Java8 Streams API 转化的查询结果. - 不能回头.拥抱未来! 虽然 .NET "领先" Java了一些，但这并不是LINQ的问题. 这主要是由于引入了lambda表达式并且支持lambdas的很多APIs. LINQ仅仅只是如何构建这样API的例子. 但我更加兴奋的期望Java 8中的 new Streams API, 以及它给Java生态系统带来的函数式编程. 这是一个由Informatech illustrates写的很棒的一篇博文:如何将常见的LINQ表达式转换为Java 8 Streams API表达式. 所以，不能回头.你可以不用再对.NET开发者眼馋嫉妒. 因为Java 8,我们已经不需要LINQ或者其他API模仿LINQ的"unified querying", 有一个更好的称呼，像"query target impedance mismatch".我们需要真正的SQL关系型数据库查询,我们需要Java 8 Streams API函数式编程查询内存集合数据. 给力 Java 8! |
上面这篇文章中，对 java8 Streams API 的溢美之词，刚看到标题，仿佛心中顿时像遇到氧气的带火星木条似得——一下子复燃了。
然而真的是这样吗？或者说真的可以这样简单的等价么
正如文中提到，是的，Linq是起源于对强烈的对改善 sql 在某些方面缺陷的渴望。但是，这并不等于说 Linq 是一种简单 ORM 或者说是用 Lambda 来进行sql查询的包装或者说仅仅是语法糖。
linq-to-object的实现
让我们从相对“表层”的因素因素谈起：该文作者在文中谈到了 Linq-to-object 的速度，实际上，Linq-to-object在内核的层面就是使用btree的方式实现的，这就相当程度上决定了其效率，从复杂性上说，仅就这一项就可以说明绝不仅是某些开源 java linq 查询库那样的简单包装。
让我们再谈一谈深层次：
linq的组成
Linq ，或者说一个完整的 Linq ，是由以下几个部分组成的：
Lambda 表达式
Query 表达式
拓展方法
表达式树
匿名类型
我们按条目分析：
正如文中提到，java的新版本也加入了lambda特性。
java没有query表达式，这意味着不能写成monad形式，而monad作为函数式的重中之重。可以说让java引入函数式的举动徒有其表。关于monad，请点击该链接阅读
前面说到，java新版本实现了lambda，然而设计者们不知何故的没有支持标准的iterator和iterable，而是选择引入了一套streams api，试图实现c# 使用拓展方法实现的功能；结果是又增加了一套steams模型，iostream表示泪流满地。这样一来，其效用也仅仅可以用在设计的这些方面，难以拓展。
没有表达式树，限制了无法表达语句结构，也限制了动态编译函数。
java没有匿名类型，限制了它借助临时结构减少计算，更使得难以借此增强表达能力。
总结
streams api 是处于语法落后的 java 在函数式上的一次勇敢尝试和追赶，然而从结果上看，是比较失败的。或许是某种情结在作怪，怕得到“抄袭”的罪名。然而，这种结果上的残次 linq 和缺失相当多部分的函数式，更会阻止自身进步的步伐，不能给使用者带来的便利，可以说是一种对尝试初心的背反。