为NGSOS智能操作系统设计编程语言

缘起

最近空明魏在全栈工程师网站发起一场有关智能操作系统开发的倡议，诸多大牛热烈参与讨论，详情见这里。涉及编程语言如何选择，已成为其中一个焦点问题，多方争执不休，莫衷一是，本文就这个话题谈谈个人浅见。

本文语境

编程语言就是一种宗教，关乎信仰，一讨论起来就没完没了，最终也不会有结果。在我看来，适用的、能最优解决问题的都是好语言，谈语言必在特定语境下，把要解决的问题是什么，场景是什么，摆清楚，才可能有最佳结果。

本文的语境就限定在空明魏所设想的“下一代智能操作系统”（NGSOS）上，假定为这个OS选择或新设计一套编程语言。关于NGSOS是什么，我摘录相关信息：

首先，这个操作系统是传统通用操作系统的一个封装，而不是要替代现有的传统、通用操作系统，主要有两个特征：一个是统一的开发语言，另外一个是一次开发完成然后可运行在所有的现有操作系统之上。在 NGSOS 上，不同的设备或节点承担不同的角色，可以划分为客户端、服务器端和中继端。这些节点之间通过类似 DDP 的协议和 IM 协议同步和传输数据并进行各自的展现或处理。比如在智能手表上，主要负责收集数据然后发给智能手机，智能手机再发给云端服务器进行处理。这种情况下，智能手表是客户端，云端是服务器，智能手机是中继端。

本文另一个语境设定是：如果我（Wayne Chan）为这个OS选配语言，该如何如何？每个人都有他的经验、层次、考虑问题出发点，别人我无从揣度，我只按自己的行业经验发表个人看法，有必要了解一下相关背景，点这个链接。

选择语言的依赖因素

NGSOS长什么样尚未定论，这对语言选择有很大影响，关键问题未确定的，我先作假设，要不然，后文无从展开。

其一：在什么设备上跑NGSOS?

假定先在智能穿戴设备上用，以后扩展到具有更强处理能力的设备，假定CPU至少是32位，内存至少128M，处理能力要超过当年Win95，如果处理能力太弱，编程语言选择肯定大不一样，也影响脚本解释器是否驻留。

其二：如何与现有系统对接？

脱离现系统（OS及OS之上基础服务框架），从零开始构造新系统不现实，也不必要，这么多开源的RTOS，从中选一个，这没疑义。问题是：OS之上的编程框架怎么定？选android，天然绑捆java，走MS路线的，C#最佳，如果不想脱离iOS，只能用C++ 与JS（因为ObjC、Swift被封闭系统圈住了）。语言与OS紧捆绑，涉及生态环境、商业形式、安全等因素，细论起来很复杂，我简化处理，就用C++与 JS，从iOS的限制倒推。C++ 在哪个OS都适用，能保证底层运行效率，JS在高层，可保证快速开发，也有广泛适用性（如果新操作系统不支持浏览器，就不该叫NGSOS，我假定NGSOS是必须支持WebApp开发的）。

为什么不能绕过iOS？如果你承认iOS在智能设备市场处于领导地位，就不该想着绕开，它留点缝隙都是宝贵的资产（其间有深意，不展开），如果您认同选择C++ 与JS是NGSOS两个基本出发点，我们继续。

其三：Qt必选

没太多理由，在NGSOS上跑的程序要炫、要酷，为了节能还要用C++ 开发，现实中，你能找到比Qt更好的图形库吗？即便找到，能裁减到资源受限设备上跑吗？

构造边界

每个OS都有边界，我们简单的将OS系统看成由两部分组成：含基础服务的操作系统，一套（或多套）编程体系。在前者构造边界，还是在后者构造边界？如果前者，你的主业只能卖一卖RTOS，NGSOS应该选后者，就像windows用.Net与C#，Android用java，iOS用objC，都用特色的编程体系强化它的生态特征。

前面选择了C++ 与 JS，这才刚开始，如果仅依赖这两项，如何让你的系统具有商业价值？没有商业价值，或商业价值不高的系统，会很快消亡。所以，NGSOS上的编程语言还必须承担锁住（或强化）商业价值的责任。因为你不贩卖RTOS，重任只能由编程体系来承担，就像在iOS上开发APP，严格受限后，才维持Apple的优质生态。这里，我想强调的是：C++ 与JS是基点，在两者之上还得发展新语言。

新兴生态系统还得解开“鸡生蛋，还是蛋生鸡”的死结，刚冒出来的OS应用少，应用少就没价值、没影响力，也就没有开发人员愿为它开发应用。看看微软近几年的表现就清楚了，如果找不出一条路径跳出这个闭环，只能一次次坐失良机，竞争对手一直快速迭代，高速前进，你很容易落下，而且越落越远。讲这个与编程语言有什么关系？关系大了，别人构造边界，你想办法打破边界呀，别人用编程系统筑墙，你就用编程系统翻墙呀！

编程语言的发展趋势

近些年来，与JavaScript相关的编程语言、框架或库很活跃，拜移动设备兴起、Html5技术发展等条件所赐，有关WebApp方面的创新层出不穷。融合WebApp与NativeApp，融合强类型与弱类型，俨然成为当今编程语言的发展趋势，苹果推Swift，微软搞TypeScript，Google推Dart，Facebook弄Reactive Native，Firefox搞Rust，都反映了这种趋势。

JS仍是基于浏览器开发WebApp的不二选择，任何公司无论他多牛，当下都得接受这个现实，所以，MS只能用TypeScript编码翻译成JS，Google也只能用Dart开发，最后都译成JS脚本。之所以要用一种语言描述另一种语言，折腾一下，不外乎两大原因，一是JS存在不少固有缺陷（但还不致命），像某些语法易误用、不支持class、模块化特性欠佳、开发大工程困难、调试不方便等，二是JS太过动态，动态语言固有的某些缺陷要克服（主要是类型检查），加入一些静态语言特性。

为NGSOS设计新语言，少不了要像Dart、TypeScript、CoffeeScript那样，先解决上面2大问题，但如果停留于这两点，市场上无非多一个 xxScript 语言而已，没有颠覆性，我们希望引入新东西，超越Swift、TypeScript不少，才能更有效吸引开发人员投身进来。不再卖关子，这个新语言就是CSE，因为作者认定这门语言是具有跨代意义，才这么多年坚持研发。CSE将脚本语言与编译语言合二为一，同时享受动态与静态语言的优势，结合NGSOS来说，它将带来如下几方面好处：

1. 脚本化开发，在高抽象度层面编码，高效，编码过程清爽、愉快，我用Python开发做类比，大概要超过一些，因为智能提示、调测跟踪可以更优。
2. 发布时代码译成C++，或为追求在线更新的效果，支持JIT，这两者保障代码运行效率达到C++水平，高出脚本（如Python或JS）百倍。
3. 脚本在线JIT，实际可支持“热注入”机制，即：可运行代码任意迁移，免安装经物理传递后在远端运行。（这一点没什么特殊的，现有JS脚本也能做到，但若在NGSOS或Elasteos概念下会赋予新含义，如：网盘变网站，也能变服务热点）
4. 避免Web开发过程碎片化，全程开发在一门语言框架内完成，避免分层切换调试，底层调一下（如java），切到上层又调一下（如JS），两者调试环境完全不同。（注：让CSE做到这一步路还有很长，但最终是可以做到的，要整合诸如Angular、react框架，让界面与逻辑良好分离后）
5. 彻底混淆生成的JS代码，包括它依赖的各个底层库，一起混淆，此项保证发布的JS难被他人直接抄袭。TypeScript、Dark等不容易做到这一步，因为工程一体性难保证，翻译后JS常假定与工程外JS配合使用。
6. 客户端开发与服务端开发合一。得益于CSE对Javascript的亲和性，CSE对NodeJS也是友好的，加之翻译转化的特性，CSE编程具有很宽挪腾余地，客户端开发与服务端开发可以统一起来。
7. 在语言级别支持NoSQL DB（不考虑关系数据库）的操作表达，就像Python描述AWS的DynamoDB，比较简洁。CSE会更简洁，操作方式、数据表示等与语言内置类型无缝结合。
8. 突破iOS AppStore发布条款限制，JS是iOS上唯一明文规定可以不经审核就能发布的（注：非明文规定，但审核能放行还有lua）。结合iOS6之后的JsBinding组件，在iOS上能实现的WebApp其实已经很强大。

此举意义深远，用你的工具开发APP能跨越多个平台后，意味着，你可以到Apple的池塘去捞鱼，前面提到“别人筑墙，你再借编程语言翻墙”是这个意思。而且，此方案中，Apple处于劣势，因为同样程序，在别人平台能译成C++ 发布，在iOS只能慢腾腾跑脚本。（让Apple品尝一下封闭平台不得已的苦楚，嘿嘿）

将脚本语言与编译语言融为一体，非常不易，如函数式、闭包、并发、这些要原生的融入语法语义，还有一点很关键，解释执行的实体如何高效的反映到C++ 数据对象上，没有精心设计你只能做到像Python扩展模块那样，处处与相对繁重的PyObject打交道（如“i += 1;”无法直接对数据结构的某偏址做累加）。这是前沿领域，要耗大量精力去积累，要不，MS、Google、Apple早有更牛逼的东西推出，这几家中，Swift走在前面，它的编程方式已非常接近脚本了，典型的，如采用类型推导定义变量（做法与CSE如出一辙），让编译语言用起来像脚本语言，再有Playground辅助，随时改一下代码，立即跑，在Playground即时看效果，表现脚本语言的应用效果。CSE比Swift做得更系统，更彻底些，Swift在Playground即时运行实际仍按编译方式进行，所以，只能把全部代码看作一个整体来跑，这导致Swift只能让片断代码受益于动态调测，CSE则在语句级别与函数级别实现“即时运行”，说白了，是真正的脚本语言在跑，调测中，能随时增加一个函数定义、类定义，随时写几条语句让它跑起来。

从语言进化链上看，CSE更像从OO语言向脚本的进化，或者说，可视作Swift下一级进化物，而不是原型化脚本编程（如JS）的进化物，其间细节差异，包含了个人对语言发展趋势的判断。我讲一个佐证，最新消息，Google宣布Dart决定将集中精力在dart2js的使用模式上，Chrome浏览器将不再嵌入Dart VM。大体预示着：尝试发展一个新东西替代或越过JavaScript不是发展方向，JS有缺陷但不致命，况且还有ES6、ES7规范在一旁候着。所以，CSE选择这样道路是恰当的：独立自成主线，把JS当作中间过程，视JS语法为CSE一个子集，能翻译代码到JS。

Swift专为Apple自家服务，遇到可能给iOS生态带来破坏的趋势，它就不会跟进，CSE没这个负担，我很乐意让CSE与JS合体，Swift做不到，不是技术做不了，而是不能自毁长城。这也是CSE可以发展壮大的一个机缘。

双工开发模式

前面讲了为NGSOS选择C++ 与JS两个基点，既是行业现状决定的，也是语言生态链上的自然选择，存在即合理。C++是OOP典范，JS是脚本语言中基于原型编程的典范，原型化比OO更为初始（也更基本），两者融合形态就是：C++ 更脚本化，JS更加面向对象化。

CSE基于C++开发，CSE脚本可译为C++，所以，C++ 是CSE最基础、最底层的东西，你完全可以用C++ 在CSE基础类型库接口上做开发，对外接口按规格去写，由工具自动生成与脚本对接的binding，之后，可将它导入到CSE脚本解释器，由脚本调用它。

双工开发模式是指：既可以用C++，也可以用CSE脚本做开发。极端情况下，比如设备能力非常受限，跑不了脚本解释器，这时只用C++ 做开发也是可以的。

锁住商业价值

基于前文描述，CSE若用作NGSOS的主编程言，它应该闭源，不是完全闭源，涉及语言内核的封闭起来，其底层与上层开放，底层主要类型库定义（如Number、String、Array等），必要的同步异步分发机制，及支持脚本解析运行的最基础环境（像线程、信号量等封装），这些必须开源，因为双工开发模式中的C++开发，要依赖这个底层库。

上层开放是自然的事，核心语言只是小部分，一个体系需要大量的扩展库支撑起来，扩展库是开源的，而且会大幅度重用NodeJS现成资源。

此策略对用户使用影响不大，拿VC类比，相当于VC Express你随便装，想要源码没门。编译工具闭源，但使用免费，这个体系其它部分全都开源。用局部闭源保证这个体系可持续发展。OS需要开源，不开源现状下已没发展空间。

建议的实施步骤

CSE发展成熟还要一段时间，核心技术接近成熟，不会做太多改动，但为了落地，平台适应性要拓宽，基础库要增加对NodeJS数据类型的兼容，上层要适配引入众多库模块，还要为适应类TypeScript、Angular等框架作修改。目前CSE集成环境比较简陋，开发起来工作量还很大。

NGSOS是新东西，重用现成RTOS，也会加许多新增特性。大致判断这两者走向初步可用的时间点较接近。初步可用前，NGSOS新写代码要么用C++，要么基于javascript，而CSE对NGSOS依赖更少，其内核本来就是跨平台的（windows、linux、mac，之前也搞过一个WinCE版本），无非适配性做些改动，仅一处有风险：目前CSE并行计算用GCD（Grand Central Dispatch），换RTOS变化较大。

CSE的基础类型库先做，先提供，NGSOS新增功能中，计划用脚本解析调用的，可在CSE基础库接口上用C++开发。其它内容，CSE与NGSOS可并行推进，穿戴设备对JS依赖不深，前期NGSOS与CSE可以弱耦合。

（本文太多假设，座而论道，夸夸其谈，见谅）