T语言开发笔记1

为什么会有开发语言的想法

在2012年，我准备开发一个给前端切图使用的屏幕取色器。

需求很简单，前端经常需要获取设计稿特定位置的颜色代码。虽然当时 PhotoShop 提供了内部取色器，但操作麻烦，而且打开 PhotoShop 很慢。有时候还想要从别的网站抄一个颜色，当时没这么现在这么强大的网站开发工具，操作也非常麻烦。所以就想找一个能快速复制用#开头的CSS颜色代码的软件。然而找了一圈，只找到几个截屏软件，操作还特复杂。

于是，我就寻思这东西也不复杂，就干脆自己做一个吧。软件的原型很简单：启动软件后先截屏，鼠标右下角参考当时的 QQ 截图显示放大镜，双击复制颜色值，然后程序退出。因为是 GUI 软件，所以我就用熟悉的 C# 开始整了。

C# 做标准的软件是比较简单的，新建项目后自动创建了一个窗口。但截图软件不是常规的窗口，经过一些研究，终于把窗口的标题栏彻底去掉了。然后接下来要实现获取系统截图的功能，但之前并没接触过这类 API，于是就谷歌了一下，最终在 CodeProject 发现了一个 C# 截图的案例代码，原来C# 标准库没有截图的现成能力，而是直接调 WinAPI。最后软件的功能如期完工，但发现另一个问题：每次启动软件都需要近一秒的启动时间，这严重影响了整个软件的体验。于是我就对代码进行了优化，但无论怎么优化，都达不到理想速度。

我最终分析慢的原因是：

1. C# 只被编译为字节码，每次启动时还需要继续编译生成可执行的机器码，这需要占用时间。

2. 我用了标准的 WinForm 框架，但又把框架自动生成的界面隐藏了，这些多余的功能也占了时间。

正是因为 C# 这两个性能问题，让我无法写出快启动的软件。于是，我就用 C++ 重写了一次。

最终软件成功开发完成。但 C++ 做起来很累，大部分在 C# 一行代码搞定的事情，在 C++ 好几行。C# 版本用了 3 天完成，C++ 版本用了 10 天，还有一些功能因为实现复杂就没做了。

此时，我就想着能不能发明一个语言，既可以像 C# 这样用起来方便，又能达到 C++ 的性能。这便是我准备发明语言的原始动机。

第一次尝试语言开发

语言分脚本语言和编译语言，因为当时开发语言的动机就是性能，自然选择了编译语言。

语言的语法就觉得和 C++ 差不多就行了，再增加一些 C# 好用的功能。

要让语言运行起来就需将代码翻译为汇编。但这东西太复杂，于是就发现了 LLVM。

第一次开发语言的目标也就成立了：做一个用起来像 C#，但可以直接编译成 LLVM 的编程语言。语言命名 T。

然后我就基于更早之前完成的 JSParser，快速完成了语法解析功能。

但后面怎么生成 LLVM 卡住了。实现起来工作量大，而且难度高，还没文档。

于是我变换了开发思路，改成基于已有的编译器改。最终找到了 Mono 开源的 C# 编译器，用了一个月时间啃代码，并做了个 Hello world。

后来有一天，Swift 发布了，我发现整个语言的设计，和我正在开发的语言非常接近，于是我就果断放弃了继续开发语言的想法。

第二次尝试语言开发

2014年，JS 还是 ES5 时代，随着前端工程越复杂，越觉得 JS 因为缺少类型信息、缺少智能提示而导致难以做成大项目，就想着能不能做一个语言，以 JS 为基础，参考  ActionScript 的语法添加类型，然后通过编译将类型去掉，生成纯 JS 代码和 API 文档。

经过小范围的用户调研后，我开始了第二次语言开发，语言名 TScript。

语言本身还是用 C# 开发，将之前的 JSParser 重新改造下，花了 1 个月时间，完成了初版。但还有很多细节没完善。

后来有一天，在开发过程中我发现了 TypeScript（那时国内还不火），我发现它的目标和我正在做的简直一摸一样，并且成熟度更高。于是我就果断停止了开发新语言。

第三次尝试语言开发

2016年，移动端大火，那时公司有很多跨端业务，同样的程序需要 H5、安卓、iOS 三个程序员做三遍。于是我就开始思索有没有可能做一个语言，只写一遍，可以同时生成五种代码（H5、安卓、iOS、Windows、Mac）。

整个语言以 TypeScript 为原型改造，UI 框架以我熟悉的 .Net SliverLight 架构为原型。编译器可以将这份代码转换为等价的 .java 文件及 .swift 文件，对于不同系统不同的业务，先通过系统判断，然后调不同的 API。所以运行库也是根据不同系统不同，但会开发一个通用的适配框架。

在投入了两个半个月后，我发现了 Dart 和 Flutter，显然这条路已经提前被发现了。于是我就果断停止了继续开发。

第四次尝试语言开发

React 和 Vue 是目前最火的两个前端 UI 框架，但随着框架的不断升级，就会发现，要想实现更好用的响应式，必须通过语言层面提供支持。就像 Solidjs 这样。

于是，我便开始第四次语言开发。目标为：以 TypeScript 为原型，支持响应式组件开发，同时增强 JSX 模板语法。

但最终我发现，如果仅仅是实现上述目标，似乎只开发 TypeScript 插件即可，没必要开发新语言。因此就没有往新语言的方向思考。

第五次尝试语言开发

当我花了一年时间在低代码后，我总结认为低代码的本质就是一个新的编程语言。针对低代码平台的新型编程语言也在不断构思中。

但我并没有立即去开发语言，指不定又能发现一个类似的实现呢？

第六次尝试语言开发

现在，经过多轮验证，我决定第六次尝试语言开发。开工前记录一些先前的经验和结论。

对编程语言的质疑

没人愿意学习新语法

如果你认为现有任何语言语法比较“丑”、写起来不够“优雅”，想要根据自己喜好，设计一套新的写法，还是尽早放弃吧。

因为更多时候这只是你的一厢情愿，你觉得不习惯的东西，说不定别人很习惯了。

我们已不再需要更多动态语言

如果你准备做一个非编译的、不考虑性能的动态脚本语言，还是尽早放弃吧。

我认为 JS 、Python、Lua 等足够支撑所有动态语言的场景了。

我们已不再需要更多强类型语言

如果你准备做一个强类型的编程语言，还是尽早放弃吧。

我认为 C++、Java 等足够支撑所有强类型语言的场景了。

强类型语言本身足够复杂，需要开发者先学几个月才可以上手。显然是不会有开发者愿意把时间放在一个没有存在感的新语言上的。

唯一可能打动用户的语言

1. 首先它必须是稳定的、安全的、开源的。

2. 它必须有完备的 IDE 和充足的三方库。

3. 它的学习成本不能高于 JS 、Python 等这些能自学入门的脚本语言。

4. 它的运行性能必须高于 Java，而不是传统的脚本语言性能。

5. 当然还有最重要的一点：用户学了这门语言后可以找到工作。