什么样的代码算低？

低代码这个词这两年热闹起来，冒出一堆创业团队搞这东西。以前只知道代码有长短，现在才知道代码还有高低。

所谓低代码，直观来讲，就是让代码写起来更简单。完成同样的任务时，代码量（也就可以理解为工作量）更少；另外，还有个重要指标是要对开发人员的要求够低，如果都要 N 年经验的高手来写，即使能写得短小也很难达到降低成本提高效率的目的。

显然，讨论低代码时，首先得有一种代码，看看这种代码是不是比其它代码更低一点。
不过，现在很多喊着低代码的所谓开发平台并没有自己的代码，而是做了一些框架和模板，由开发人员在模板内填填东西就搭出一个应用系统。应对简单需求也没问题，也还算好用，但业务复杂到要用代码来搞定时，还是要用 Java/C# 这些代码。
低代码要低的是代码，而不是框架。不用代码的模板确实能解决一些问题，但仍然有太多业务需要代码来搞定，代码的高低确实和开发效率休戚相关。

那么，什么样的代码才算是低代码呢？
低代码主要面向信息系统（广义上俗称 MIS）开发，因为只有这种应用的需求五花八门，每家不一样，永远在变做不完，高效率低门槛的开发手段就显得特别有意义。
信息系统的主要任务其实就是围绕数据的三样事：输入 Input、处理 Process、输出 Output，合起来就是个 IPO。IO 现在可以由成熟的报表工具和界面控件解决，那麻烦的事就剩 P 了，大部分开发过程要写的业务逻辑也就是这种事。

这样，我们评判一种代码是不是够低，就是看这种代码处理数据是不是方便。
什么样的数据呢？
主要是结构化数据，也就是存在关系数据库中的那种数据。这是信息系统中最常见的数据种类。其它的非结构数据要么只有一些专门固定的处理需求，要么还是要转化或抽取出结构化数据才会有灵活处理的需求。
问题就转换成哪种代码擅长处理结构化数据了。

在这个评判标准下，Java 肯定不算低了，它就没有一个像样的结构化数据对象。新版 Java 有了 Stream 等集合类库并开始支持 Lambda 语法，但也是且也只能针对很通用的数据对象（这是 Java 本身的目标决定的），处理结构化数据时写起来仍然比较麻烦。而且，Java 是编译型语言，也天生难以动态化。还有，Java 是个强面向对象语言，深刻理解面向对象理念并不是件很容易的事情，开发 Java 应用时还需要建立复杂的工程化环境，这些对于开发人员来讲都是不低的门槛。
C# 类似。

SQL 一定程度算比较低了，许多非专业人员都能用 SQL 写出查询，写 SQL 时也不需要过于关心应用架构，只要理解数据和业务本身，而这也是开发人员必须要有的知识。
但是，SQL 有两个硬伤：有序计算和有过程的逻辑。这会导致稍复杂一些的处理都变得非常麻烦，经常写出几百行 N 层嵌套的语法，过几个月自己都看不懂。SQL 还特别难调试，进一步推高开发成本。
如果改用存储过程倒是可以实现过程运算，但那又像转回 Java 了。虽然存储过程是用 SQL 写的，但它同样没什么好用的结构化数据对象（只能靠临时表对付）和集合运算，经常还不如用 Java 指挥 SQL 来工作（好多应用就是用 Java+SQL 写的）。而且，使用存储过程时，也会面临一些应用架构的麻烦事。
SQL 的“低”，只适合于相对简单的场景。业务需求复杂化之后，它的复杂度就会指数级陡增。

Python 略好一点，pandas 有个 dataframe 可以算作是结构化数据对象。但是 Python 的集成性比较差，除非整个应用都是用 Python 写的，这种情况还不多见。而且，dataframe 也只能算个半吊子，它本质上是个矩阵，并不是我们常规意义的数据表，很多运算思考起来很绕。而且，还要再说一遍而且，pandas 是个第三方类包，它的应用环境也不太简单，调试麻烦度依然。
Scala 也是一种选择，它也有个 dataframe 可以对付一些结构化数据处理，但也不算很专业。Scala 代码本身还算低，但是面向对象那堆东西的理解门槛一点也不低，而且也面临复杂的工程环境。

SPL 才是低代码

那就没有够低的代码了吗？
还是有的，开源集算器的 SPL 就是低代码，很有可能现在是唯一的了。
这其实是 SPL 被发明的原因。润乾做报表工具，自然会涉及很多复杂运算，然后发现这些运算用 SQL 和 Java 都很难写，而且这些困难无法在现有体系上完善来解决。磨了 N 年，干脆自己发明一种语言解决这些问题了，也就是 SPL。

SPL 中有完善的结构化数据对象，大小数据都能搞。它虽然采用了少量面向对象的语法，但并没用深奥的面向对象概念，重点都放在数据处理和运算上。程序逻辑上有点像早期的 BASIC 语言，基本的分支、循环、子程序都有，很容易理解。再提供了基于结构化数据的集合类型及丰富的库函数，特别擅长支持复杂集合及有序运算，让代码编写能简单很多。

Talk is cheap, Let’s show code.
SPL 的代码写在格子里，可以直接用格子作为变量名（Excel 用户表示很亲切），天然支持分步运算，网格缩进能清晰体现代码的层次，还提供有完善的调试功能。

丰富的库函数，常见的基本运算只要一行搞定。

在 SPL 中甚至可以直接使用 SQL（不依赖于数据库哟）：

$select * from d:/Orders.csv where (OrderDate<date('2020-01-01') and Amount<=100)or 
(OrderDate>=date('2020-12-31') and Amount>100) 

$select year(OrderDate),Client ,sum(Amount),count(1) from d:/Orders.csv  
group by year(OrderDate),Client  
having sum(Amount)<=100

$select o.OrderId,o.Client,e.Name e.Dept from d:/Orders.csv o  
join d:/Employees.csv e on o.SellerId=e.Eid

$with t as (select Client ,sum(amount) s from d:/Orders.csv group by Client)  
select t.Client, t.s, ct.Name, ct.address from t  
left join ClientTable ct on t.Client=ct.Client

SPL 本身就有类似 Java 的过程控制能力。这样，不管有没有数据库，SPL 都能起到 Java+SQL 的效果了。

再和其它代码比一下，比如我们想计算一支股票最长连续上涨了多少天。
SQL 写出来是这样的：

select max(consecutive_days)
from (select count(*) consecutive_days
      from (select sum(updown_flag) over(order by sdate) no_up_days
            from (select sDate,
                         case when price>LAG(price) over(order by sDate)
                              then 0 else 1 end updown_flag
                  from share))
      group by no_up_days)

这个代码，看懂都有点费劲吧。留作练习题，思考一下它的工作原理。

Python 写出来这样的：

import pandas as pd
aapl = pd.read_excel(‘d:/AAPL.xlsx’)
continue_inc_days=0;
max_continue_inc_days=0
for i in aapl['price'].shift(0)>aapl[‘price’].shift(1):
    continue_inc_days =0 if i==False else continue_inc_days+1
    max_continue_inc_days = continue_inc_days if max_continue_inc_days < continue_inc_days else max_continue_inc_days
print(max_continue_inc_days)

这个逻辑倒不复杂了，但写出来也不是很简单。

至于 Java，就不尝试了，大家自己脑补。
同样的运算，SPL 写出来是这样的：

这个代码中都没有出现循环语句，这是因为 SPL 有大量的强 Lambda 语法风格的集合函数，很多在其它语言中要用循环才能实现的任务，在 SPL 中就是单句。

SPL 把 SQL 的硬伤解决掉了，集合了 Java 和 SQL 的共同优点。SPL 还能方便地支持大数据运算和多线程并行，Python 碰到这种情况就容易抓瞎了。有兴趣的同学可以去乾学院看更多的 SPL 代码例子。

不止是代码低

SPL 提供了完善的数据源支持，你听说过还是没听说过的数据源几乎都能支持：

这又减轻了很多做接口和数据转换的工作量。

SPL 是用 Java 实现的，它提供有 JDBC 驱动，能够无缝地嵌入到 Java 应用程序中：

…
Class.forName("com.esproc.jdbc.InternalDriver");
Connection conn =DriverManager.getConnection("jdbc:esproc:local://");
Statement st = connection.();
CallableStatement st = conn.prepareCall("{call xxxx(?, ?)}");
st.setObject(1, 3000);
st.setObject(2, 5000);
ResultSet result=st.execute();

这样，可以轻松地把 SPL 集成到某种应用框架中。大部分开发人员只要关心业务逻辑和数据结构就可以了，甚至不需要理解复杂的应用架构了。
特别地，对于那些没有代码的“低代码平台”，把开源的 SPL 集成进去之后，就有了真正的低代码，让模板和代码互相补充，这才是完整的低代码平台。

SPL 还是解释执行的动态语言，写出来的脚本可以放在主应用程序外部。这一方面能降低脚本和主应用程序之间的耦合性，还能带来热切换的好处。毕竟，业务逻辑（特别是查询报表类）常常在变化，需求有改动后只要重写脚本就可以立即生效了，应用程序不用重启。如果是用 Java 的代码，那就…（这也说明 Java 代码一点也不低）。