博客园  :: 首页  :: 新随笔  :: 联系 :: 订阅 订阅  :: 管理

T语言开发笔记1

Posted on 2023-03-13 17:32  xuld  阅读(144)  评论(3编辑  收藏  举报

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

在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. 当然还有最重要的一点:用户学了这门语言后可以找到工作。