Interpreting Low-Code from the perspective of open-source SPL

What kind of code is considered low？

In recent years, the term "Low-Code" has gained popularity, giving rise to numerous entrepreneurial teams. Unlike the binary classification of long and short codes, Low-Code introduces the dimensions of high and low codes. Simply put, Low-Code aims to simplify coding, reducing the workload and lowering the expertise requirements for developers.

In the Low-Code landscape, it's essential to assess the actual codebase. Many self-proclaimed low-code development platforms rely on frameworks and templates, offering simplicity for basic requirements. However, as complexity grows, these platforms often necessitate traditional coding languages like Java or C#.

The essence of Low-Code lies in minimizing the amount of code, not just relying on templates. While templates address straightforward needs, many businesses require intricate coding solutions. The effectiveness of Low-Code is intricately tied to development efficiency.

So, what qualifies as Low-Code? Primarily tailored for information system development (MIS), Low-Code is crucial for handling diverse and ever-changing requirements efficiently. In the realm of MIS, the core tasks revolve around Input, Process, and Output (IPO), with coding focusing on the 'Process' aspect, particularly efficient data processing.

Structured data, prevalent in relational databases, is the primary focus for Low-Code. Java and C# struggle in this domain due to a lack of structured data objects and the inherent complexities of these languages. SQL, while accessible, faces challenges in ordered computation and procedural logic, leading to convoluted code and increased development costs.

Python offers some relief with Pandas' dataframe, serving as a structured data object. However, Python's integration challenges and the dataframe's matrix-like nature limit its applicability. Scala provides a dataframe option but falls short in professionalism and imposes a learning curve, coupled with complex project environments.

In conclusion, Low-Code thrives in simplifying code for structured data processing within information systems, offering efficiency benefits. Choosing the right Low-Code solution involves considering the language's proficiency in handling structured data and its overall suitability for complex business requirements.

SPL is the low code

Is there not a kind of low enough code?

Absolutely, there exists a form of code that meets the criteria of being low enough—enter SPL (Structured Process Language) from the open-source esProc.

SPL emerged from Raqsoft's need for a robust solution in handling intricate operations within reporting tools. Traditional coding in SQL and Java proved challenging, leading Raqsoft to pioneer a new language tailored for these tasks—SPL.

SPL boasts well-defined structured data objects, capable of efficiently managing both big and small datasets. While incorporating a modest amount of object-oriented syntax, SPL sidesteps esoteric concepts, focusing squarely on streamlined data processing. Resembling the simplicity of early BASIC language in program logic, SPL features fundamental constructs like branches, loops, and subprograms, ensuring ease of comprehension. Notably, SPL excels in supporting complex set and ordered operations, enhancing the simplicity of code composition.

Let's move beyond words and delve into code. SPL code is structured in a grid, leveraging cells as variable names, a familiar concept for Excel users. Noteworthy characteristics include seamless support for stepwise operations, clear code hierarchy through grid indentation, and robust debugging functionalities. SPL stands as a testament to practical low-code solutions for intricate data operations.

In SPL, you can even use SQL directly (independent of database):

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

$select year(OrderDate),Client ,sum(Amount),count(1) from d:/Orders.csv  
group by year(OrderDate),Client  
having sum(Amount)&lt;=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 itself has the process control capability similar to Java, therefore, SPL can achieve the effect of Java + SQL whether there is database or not.

Let’s compare it with other codes. For example, we want to calculate the maximum consecutive days that a stock keeps rising.
Write it in SQL is like this:

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&gt;LAG(price) over(order by sDate)
                              then 0 else 1 end updown_flag
                  from share))
      group by no_up_days)

This code is a bit difficult to understand, right? You can take it as an exercise and think about how it works.

Coding in Python is as follows:

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)&gt;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 &lt; continue_inc_days else max_continue_inc_days
print(max_continue_inc_days)

Although this logic is not complicated, it is not very simple to code.

As for Java, we won't try. You can imagine its complexity yourself.

For the same operation, coding in SPL is as follows:
| Header 1 |
|------------|
|1 =T("d:/AAPL.xlsx") |
|2 =a=0,A1.max(a=if(price>price[-1],a+1,0)) |

There is no loop statement in this code, because SPL has a large number of strong lambda syntax-style set functions. Many tasks that can only be achieved with loops in other languages can be done with a single statement in SPL.

SPL solves the serious flaws of SQL, and combines the common advantages of Java and SQL. In addition, SPL can easily support the big data operation and multi-thread parallel computing, but for Python, it will find it at a loss when it encounters such situation. If you are interested in learning more SPL code examples, go to Raqforum.

More than a kind of low code

SPL provides perfect data source support; it can support almost all data sources that you may or may not have heard of:

Thus, it reduces a lot of work load of preparing the data interface and conversion.

Since SPL is implemented in Java, it is provided with JDBC driver, and can be seamlessly embedded into Java applications:

…
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();
…

In this way, SPL can be easily integrated into some application framework. Most developers only need to care about business logic and data structure, and don't even need to understand complex application architecture.

In particular, for those “low code platforms” without code, they will have real low code after integrating the open-source SPL. Letting template and code to complement each other is a complete low-code platform.

SPL is also the interpreted-execution dynamic language, and the scripts written can be placed outside the main application. In this way, not only does it reduce the coupling between the script and the main application, but it also brings the benefits of hot swap. After all, the business logic (especially query and report)is often changing. When the requirement changed, it can take effect immediately as long as the script is rewritten, and there is no need to restart the application. If Java code is used in this case, then... (it also shows that Java code is not low at all).

To know more about SPL, check them out on GitHub

Reference: https://blog.scudata.com/interpreting-low-code-from-the-perspective-of-open-source-spl/