Java 很长时间都没有提供直接的数据集运算语法，写个简单的 SUM 都要很多行，更不要说分组、排序等复杂运算了。完全同样数据处理功能的代码远比 SQL 长，开发效率低下。
从 Java8 开始，Stream 登场，提供了支持 Lambda 语法的集合运算类。程序员不再为 SUM 就写很多行了，常规的分组、排序都有了现成函数。
数据集上的排序写成这样，比早期 Java 确实方便很多：

Stream<Order> result=Orders
.sorted((sAmount1,sAmount2)->Double.compare(sAmount1.Amount,sAmount2.Amount))
.sorted((sClient1,sClient2)->CharSequence.compare(sClient2.Client,sClient1.Client));

不过，和 SQL 相比，方便程度仍然差距不小：

select * from Orders order by Client desc, Amount

更复杂一些的分组汇总

Calendar cal=Calendar.getInstance();
Map<Object, DoubleSummaryStatistics> c=Orders.collect( Collectors.groupingBy(
    r->{
        cal.setTime(r.OrderDate);
        return cal.get(Calendar.YEAR) + "_" + r.SellerId;
    }, 
    Collectors.summarizingDouble(r->{return r.Amount;})
));
for(Object Sellerid:c.keySet()){
    DoubleSummaryStatistics r =c.get(Sellerid);
    String year_sellerid[]=((String)Sellerid).split("_");
    System.out.println("group is (year):"+year_sellerid[0]+"\t (sellerid):"+year_sellerid[1]+"\t sum is："+r.getSum()+"\t count is："+r.getCount());
}

大体等价于 SQL 语句：

select year(OrderDate), Sellerid, sum(Amount), count(1) from Orders group by year(OrderDate), Sellerid

差距相当明显。

基于 Stream 又发展出了 Kotlin，它不再直接使用 Java 语言，这样不再受 Java 的局限，可以使用新的语法和符号，写出更简洁的 Lambda 表达式。
比如前面那个排序：

var resutl=Orders.sortedBy{it.Amount}.sortedByDescending{it.Client}

简洁程度已经和 SQL 很接近了。
但面对复杂些的运算，仍然不够方便，比如前述的分组汇总：

data class Grp(var OrderYear:Int,var SellerId:Int)
data class Agg(var sumAmount: Double,var rowCount:Int)
var result=Orders.groupingBy{ Grp(it.OrderDate.year+1900,it.SellerId) }
    .fold( Agg(0.0,0),{acc, elem -> Agg(acc.sumAmount + elem.Amount,acc.rowCount+1) })
    .toSortedMap(compareBy<Grp> { it. OrderYear}.thenBy { it. SellerId} )
result.forEach{ println("group fields:${it.key.OrderYear}\t${it.key.SellerId}\t aggregate fields:${it.value.sumAmount}\t${it.value.rowCount}") }

虽然比 Stream 简单了，但和 SQL 还是没法比。

看来，想在 Java 中取代 SQL（以获得更好的架构）编写结构化数据集相关的业务逻辑，Stream 和 Kotlin 还需要继续进化。
开源软件 esProc SPL 可以一步到位实现 Stream 和 Kotlin 的目标。
esProc SPL 也是纯 Java 的开源软件，和 Stream 和 Kotlin 类似，都可以完全无缝地集成进 Java 应用中，一起享受成熟 Java 框架的优势。

和 Kotlin 类似，esProc 也提供了一种新的程序语言，也就是 SPL。但它并不是从 Stream 和 Kotlin 发展而来的。
为什么要设计一种新的程序语言而不直接封装成 Java API 呢？
Java 是编译型的静态语言，在这个基础上很难实现动态数据结构和便捷的 Lambda 语法，而这又是结构化数据运算中特别常见的，也是 SQL 的优势所在。
SQL 中任何一个 SELECT 语句都会产生一个新的数据结构，可以随意添加删除字段，而不必事先定义结构（类），这在结构化数据运算中家常便饭。但 Java 这类语言却不行，在代码编译阶段就要把用到的结构（类）都定义好，可以认为不能在执行过程中动态产生新的类（Java 理论上支持动态编译，但复杂度太大）。如果用一个专门的类来表示所有数据表，把字段名也作为类的数据成员，这又不能直接使用类的属性语法来引用字段，代码非常麻烦。
Lambda 语法是在 SQL 中大量使用，比如 WHERE 中的条件，本质上就是个 Lambda 表达式。Java 这种静态语言虽然现在也支持 Lambda 语法，但方便程度远远不如 SQL。每次书写时还是要有个函数头定义来告诉编译器现在要写 Lambda 函数了，代码看着很乱。在 Lambda 函数中也不能直接引用数据表的字段名，比如用单价和数量计算金额时，如果用于表示当前成员的参数名为 x，则需要写成 "x. 单价 * x. 数量" 这种啰嗦的形式。而在 SQL 中可以更为直观地写成 "单价 * 数量"。
解释型的动态语言才能实现 SQL 的这些特征，可以随时生成新的数据结构，也可以根据宿主函数本身决定当前参数是不是 Lambda 函数，从而没必要写个定义头，更可以根据上下文正确引用未写表名的字段。
SQL 是解释型动态语言，SPL 也是。Java 以及 Java 基础上的 Kotlin 和 Scala 都不是，所以用这些语言很难书写出简洁的代码。

在解释型动态语言基础上，SPL 提供了比 SQL 更完善的结构化数据对象（表、记录、游标）和更丰富的计算函数，包括 SQL 中有的过滤、分组、连接等基本运算，还有 SQL 中缺失的有序、集合等运算。所以，SPL 代码通常会比 SQL 更简洁易维护，比 Stream 和 Kotlin 就更强得多。
前面两个排序和分组运算，用 SPL 写出来比 SQL 更简洁：

Orders.sort( -Client, Amount)
Orders.groups( year(OrderDate), Sellerid; sum(Amount), count(1) )

更复杂一些的任务，比如这个任务，计算一支股票最长连续上涨的天数，SQL 要写成多层嵌套，冗长且难懂：
select max(ContinuousDays) from (
select count(*) ContinuousDays from (
select sum(UpDownTag) over (order by TradeDate) NoRisingDays from (
select TradeDate,case when Price>lag(price) over (order by TradeDate) then 0 else 1 end UpDownTag from Stock ))
group by NoRisingDays )

Stream 和 Kotlin 缺乏窗口函数等支持，同样的计算逻辑写出来更会困难得多也长得多，而用 SPL 就非常简单：

Stock.sort(TradeDate).group@i(Price<Price[-1]).max(~.len())

SPL 还有完善的流程控制语句，像 for 循环，if 分支都不在话下，还支持子程序调用。只用 SPL 就能实现非常复杂的业务逻辑，直接构成完整的业务单元，不需要上层 Java 代码来配合，主程序只要简单地调用 SPL 脚本就可以了。
esProc SPL 是纯 Java 程序，它可以被 Java 调用，也可以调用 Java。这样即便有个别用 SPL 不易实现而要使用 Java 实现的代码（比如某些对外的接口）或者已经有的现成 Java 代码，也都可以再集成进 SPL 中。SPL 脚本和主 Java 应用程序可以融为一体。

作为解释型语言，SPL 脚本可以存储成文件，置于主应用程序之外，代码修改可以独立进行且立即生效，不像基于 Stream 和 Kotlin 写的代码在修改后还要和主程序一起重新编译，整个应用都要停机重启。这样可以做到业务逻辑的热切换，特别适合支持变化频繁的业务。

SPL 支持的数据源也很丰富，无论关系数据库还是 NoSQL 或者 Kafka、Restful，无论是常规二维表还是多层次的 json，SPL 都可以计算直接读取后处理。而 Stream 或 Kotlin 都不涉及这些内容，还需要自己写 Java 代码访问。

非常特别地，SPL 代码写在格子里，这和通常写成文本的代码很不一样。独立的开发环境简洁易用，提供单步执行、设置断点、所见即所得的结果预览，调试开发更方便。

这里 写在格子里的程序语言 有对 SPL 有更详细的介绍。

最后，esProc SPL 在这里 https://github.com/SPLWare/esProc 。