聊一聊轻舟低代码NASL编程语言

前言

之前在《轻舟低代码产品化进阶之路》和多次分享中反复出现过下面这张图，这张图的重点是NASL，今天我们就来聊一聊NASL。NASL全称是NetEase（Normal）Application Specific Language，是轻舟低代码平台提供给用户的应用建模语言。围绕NASL团队早前有过争论，有人强调NASL是一种DSL，有人则强调是一门编程语言，深入探讨后大家发现这两种说法都有道理，认知差异主要来自于看待问题的不同视角。

从模型驱动说起

正确理解模型驱动

模型驱动思想（MDSD/MDA）通常被认为是低代码核心思想。简单理解模型驱动，就是开发者参照一个抽象模型，将应用需求通过建模方式来实现的过程。但国内由于“表单驱动”和“模型驱动”概念流行，以至于很多同学把模型驱动中“模型”简单理解成“数据模型”，这其实是不准确的。要准确理解模型驱动，需要了解MDSD（模型驱动软件开发）和OMG（对象管理组织）在2001年提出MDA（模型驱动架构）。MDA使得开发人员可以使用UML（Unified Modeling Language）可视化设计PIM（Platform Independent Model），然后由工具自动执行针对特定平台和实现语言的映射规则，将PIM转换为对应的PSM（Platform Specific Model），并最终生成可执行的应用程序代码。MDA可以认为是MDSD思想的一种实现标准，它规范了很多术语、对工具集有清晰的定义。MDSD则更偏向思想或方法论，旨在通过抽象来提高复杂任务的易处理性，进而提升开发效率和质量（跟低代码目标基本一致）。MDA由于其整个标准体系复杂性和仅有部分平台实现、同时没有提供面向互联网应用特定问题域的好的解决方案（比如高并发、UI编程等问题），因此在互联网技术浪潮中存在感并不强。但是MDSD思想却对广大开发者有着深刻的影响，互联网领域众多流行的编程框架本质上都体现了MDSD思想，低代码可以被认为是其中的一种实践。

模型跟框架的关系

简单来说，模型是一种抽象，框架是它的一种具体实现。也可以说框架为应用开发者提供了一种可落地的模型（如下图）。说到框架，大家首先想到肯定是是react，springboot这种被广泛使用的前后端框架，低代码框架本质上跟他们类似，差别在于，低代码框架通常支持从前后端到数据库的全栈模型实现，而且封装程度更高。
-- 说"抽象"是站在应用场景的视角，说"封装"站在通用编程语言的视角。

模型抽象时，我们通常需要通过分层、分解、切面等思维拆解复杂度；框架实现时，通常要用扩展（extends）、实现（implements）、hook、表达式填充等技术体现开放性。

低代码框架核心就是要抽象一种编程模型：它既要能简单及高效的支撑用户编程意图的表达，又要能具备足够的通用性灵活性（但又不用受到MDA的束缚）。要达到这样的目标，需要具备以下一些条件：

• 首先，需要在应用软件开发领域具备非常丰富的知识和经验。具体点来说要对各种通用编程语言、框架和各种编程模式优缺点有清晰的认知，对传统研发模式影响效率和质量的因素有清晰的认识，只有如此才能给出有价值的设计。这也是很多低代码平台宣传“by developer for developer”的原因。
  -- 如果考虑的是如何打造完整平台，还需要对现代软件工程需要的配套设施,包括是云原生技术体系有清晰完整的认知。

• 其次，要对低代码框架的使用者有清晰界定和认知，框架设计要尽可能贴近这个人群的认知模型，同时要把复杂度控制在这个人群普遍能接受的程度。
  -- 模型可以针对不同人群体现不同的可变性，比如mendix通过Mendix Studio和Mendix Studio Pro为专业开发者和非专业开发者提供低、无代码两种开发模式。可变性差量的设计在这篇文章 https://zhuanlan.zhihu.com/p/64004026里有比较深入的解读。

• 最后，也是最重要一点是要有上帝视角。对很多程序员来说从框架使用者转变成框架设计者是一个非常大的跨越，需要有非常强抽象思维和站在更高的视角才能做到。

发起网易轻舟低代码项目的技术团队有着十多年数百个业务系统开发经验，同时团队在多年实践中培养了多位编程框架设计专家，这是轻舟团队在低代码领域创新所具备的优势。

NASL是轻舟低代码框架的建模语言

低代码框架实现了一个编程模型，NASL是这个模型的建模语，用于描述模型中可变性的那部分。NASL根据编程模型来设计，通过框架来实现。

从这个角度来说，NASL就是一组DSL（这其实是《领域编程语言》这本书中对DSL的标准定义）。

-- 稍微扩展一下，因为所有低代码（包括零代码）平台都可以被认为是基于MDSD思想设计和实现的，因此从这个角度来说，NASL就是稍微复杂一点schema，他并不能凸显出轻舟低代码跟其他零代码平台的差异（但模型本身凸显了差异）。参考《聊一聊低代码和零代码的差异》

NASL是一门编程语言

NASL不仅是一组DSL，而是一门编程语言，主要基于两点：

• 一是NASL支持全栈编程、且具有统一的静态类型系统。全栈是指通过NASL可实现数据表设计、服务端编程和多前端（H5/web/小程序）的编程。我们知道在传统编程中，数据库字段类型、JAVA中类型和TypeScript类型体系并不一致，但NASL为了确保编程体验，抽象了的统一的静态类型系统，并提供该类型系统转译到TS、JAVA和不同数据库数据类型的机制。

• 第二个更明显的特征是我们为NASL实现了一套跟传统编程语言类似的工具链（如下图）：

• webIDE中实现了数据、逻辑和页面可视化设计器，负责NASL可视化编写。

• NASL Language Server实现了NASL查找引用、跳转定义、类型检查（推断）、自动补全（推荐）等能力。后续可结合机器学习等技术进一步演进智能编程的能力（这会是个非常有意思的领域，很可能成为未来低代码产品核心竞争力）。

• NASL仓库实现了NASL的存储，版本和分支管理。

• 资产中心实现了相当于maven、npm的职能，可以以模版方式管理NASL代码片段，可以扩展库方式管理以JS和JAVA实现并以NASL声明的组件和逻辑。

• 前后端翻译器（generator）负责将NASL代码翻译成JS（基于VUE）和JAVA代码（基于Springboot）

从这两点来说，NASL就是一门编程语言。当然NASL不是一门严格意义上的编程语言（例如JAVA、C++），因为它没有实现编译器后端部分也没有自己的运行时。但如果大家能把TypeScript看成编程语言，那把NASL同等视之好像也不过分。

-- 从编程语言的视角，NASL凸显了轻舟低代码跟零代码平台的差异。参考《聊一聊低代码和零代码的差异》

NASL可视化编写能力来自设计器

NASL理论上可以跟通用编程语言一样提供文本代码编写能力，但是基于降低难度、提升效率考虑，我们提供了可视化设计器。应用开发主要涉及UI、逻辑和数据三方面开发需求。

• UI的可视化设计的价值很清楚，实现方案也有很多，这里不展开详细说。讲一下轻舟低代码UI可视化特点：轻舟UI组件属性具备类型的，因此按照从数据、逻辑到UI的应用设计流程，UI通常可以根据类型被推导出来。这也是后续轻舟低代码进一步实现智能化编程很重要的一个方向。

• 数据可视化设计，在传统开发中也需要，只不过以往我们设计完ER之后，需要给出DDL让DBA去实施，低代码平台可以有设计自动生成DDL并部署到数据库中。此外数据查询这里低代码平台提供了可视化生成NASL，再解释成SQL并执行的能力。

• 我们要重点探讨一下的是逻辑的可视化，这是很多人质疑可视化价值的地方。比如有同行提出过以下观点（参见文章https://zhuanlan.zhihu.com/p/451340998）：
  “「命令式」代码无法实现可视化编辑，而可视化编辑是低代码唯一不可少的功能，所以我们可以得到结论：所有低代码平台必然只能采用「声明式」代码，这也是为什么所有低代码平台都会有内置的「DSL」。”
  虽然有道理，但个人觉得可能并不尽然。因为编程本质上是组织各种符号的过程，传统命令式编程中，我们需要记忆大量的符号，比如各种控制语句、操作符、变量、对象、方法等，还要理解各种上下文作用域，这其实是编程复杂性和易错性很大一个来源。虽然传统语言也有通过实现language server提供自动补全等能力来降低符号记忆和理解负担的机制，但这是否已经是最好的方案了呢？可能并不尽然，在大部分业务编程场景下，优秀的可视化设计可能可以更进一步降低这种负担、让开发者更加专注在符号的高效组织上。目前有三种逻辑可视化编写方式，逻辑图（outsystesm、轻舟低代码），mirco-flow（mendix），blockly（scratch），都具有进一步发展的潜力。不过也要看到逻辑可视化方式确实存在一些需要克服的问题，比如逻辑图信息密度太低，传统开发人员接受度较低等，所以后续轻舟低代码一方面会持续优化逻辑图绘制方式，另一方面也会考虑提供逻辑图和文本代码能够互转的编码方式。
  

NASL的可扩展性来自于框架

NASL可扩展性主要有两种情况，第一种是在不增加NASL符号的情况下，通过传统编码方式扩展UI组件、逻辑的能力。UI组件和逻辑是NASL中的两种对象。UI组件是NASL中基本对象，只能通过传统语言开发并声明到NASL。组件扩展是说组件可以不由平台提供，而是由开发者自行开发并声明到NASL中，这可以解决企业特殊UI或复杂角度的需求。逻辑在低代码平台中通常由低代码开发者通过NASL来创建，逻辑扩展是说，当遇到某些场景，开发者可以通过java语言开发然后声明到NASL中。这种扩展方式可解决复杂算法逻辑、或者引入企业存量资产到NASL中的需求。第二种是NASL符号本身扩展，这种目前还没有真实需求，我们也还没想清楚，所以不展开了。NASL的扩展性主要依托前后端翻译器实现，同时影响到可视化设计器和资产中心。

后记

随着轻舟低代码编程框架的逐步完善和语言工具链的逐步完善，NASL也将逐步趋于稳定和完善。希望NASL在不久的将来能为轻舟平台上的应用开发者带去丝滑的开发体验。