从 NASL 说开：低代码编程语言能饭否

Gartner说，低代码是应用开发的未来。在国内，目前市场普遍认为低代码的核心价值在于低成本、低门槛，而在开发的世界，这往往意味着需求简单、扩展困难。但偏偏一家叫做网易数帆的公司，直言要用低代码来开发复杂企业应用，并推出了一个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并执行的能力。
• 我们要重点探讨一下的是逻辑的可视化，这是很多人质疑可视化价值的地方。比如有同行提出过以下观点（参见《从实现原理看低代码》）：
  “「命令式」代码无法实现可视化编辑，而可视化编辑是低代码唯一不可少的功能，所以我们可以得到结论：所有低代码平台必然只能采用「声明式」代码，这也是为什么所有低代码平台都会有内置的「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能带来新的饭碗吗

回头看Gartner的定义，也有LCAP（低代码平台）和CADP（无代码平台）之分，前者对开发完整性、应用独立性、逻辑完备性、可接入可集成等都有要求，所以说，NASL的实现使得轻舟低代码更符合这一理念。结合轻舟低代码的研发目标，我们甚至可以认为，网易数帆是在打造具有低代码（或可视化）特性的NASL编程语言。

作为一个新物种，NASL随着轻舟低代码编程框架和语言工具链不断完善。今天，从编程语言的格局，以NASL为内核的轻舟低代码平台，能为开发者放飞想象力构建应用提供什么样的支撑？能否为我们带来丝滑的开发体验？如果读者有兴趣探究，目前正好有机会体验：2022网易低代码大赛已经启动，轻舟低代码作为开发平台，全球低代码爱好者都可以报名参加。

为了吸引高质量参赛作品，主办方提供了Mac、大疆无人机等奖品，并为学生参赛群体提供5个网易低代码开发岗位名额，参与大赛就有机会赢取。如果身边有亲友在谋求新的饭碗，也可以推荐给他们——主办方还提供了开营解说、视频课程及多形式答疑，使得参赛者可以从0-1体验极速低代码开发。