【在主画面加入捷径】
       
【选择语系】
繁中 简中

技术杂谈:为什么 Nim 语言无法造成流行

【赞助商连结】

    Nim 是一个新兴的编译语言,其核心理念相当地简单:Nim 程序代码会转为等效 C 程序代码,再由 C 编译器实际编译软件。在理想上,这个方向的确是可行的,因为 C 语言问世超过四十年,C 编译器的优化技术已经相当成熟,与其从头开始撰写一套新的编译器,还不如直接站在巨人的肩膀上。不过,Nim 项目从 2008 年问世,到目前 (2018 年二月) 已经十年了,这个项目并没有流行起来。笔者虽然不是编译器的专家,姑且让笔者事后诸葛一下。

    某种程度上来说,Nim 不流行其实是非战之罪。对于目标市场相近的产品,背后的团队还是会造成微妙的影响。和 Nim 目标市场相近的语言有 Go (golang) 和 Rust,Go 来自 Google,Rust 来自 Mozilla,而 Nim 的团队是谁呢?说实在的,相对没那么知名。项目的开发团队不仅仅代表着名气,某种程度也代表可投入的资源。像 Go 在语言特性上除了 goroutine 等共时性相关的语法外,其实没有很突出,但 Go 在简单及效能上做了很好的取舍,也写了一套强大的标准函式库,让程序设计者有足够的积木可以继续堆出新玩具,正向的循环就此产生。而 Nim 没有这样的效应产生。

    其实,Nim 不是一无是处,如果花一些时间把玩一下 Nim 语言,会发现这个语言的确有可取之处。基本上,Nim 就是 Pascal 和 Python (再加上其他相对冷门的语言) 的特性混合在一起的产物,比起用传统的 C 语言,的确可以用高阶许多的语法产出相对高效的程序。在 Nim 语法中,笔者最喜欢重载 (overloading) 的部分,如果设计得宜,可以写出相当简洁的 API。至于宏 (macro) 就稍微复杂了点,用到的机会其实不多。

    不过,Nim 的设计上仍有一些可改进之处。有些读者可能觉得 Nim 的语法看起来怪了点,但笔者认为写一小段时间就可以适应。以笔者观之,Nim 的物件系统的确有一些问题,Nim 的物件采单一继承,这倒也无可厚非,Go 甚至无法继承物件,只能嵌入物件;但是 Nim 却缺乏多重继承或等效的语法,这在撰写程序时会觉得绑手绑脚。现代语言较少直接采用多重继承了,通常都是用接口 (interface) 或 mixin 或 trait 等方式取代,即使像 Go 的物件比较简单,也加入接口来弥补其不足;而 Nim 的问题在于缺乏官方的方案,目前大概先用 proc 的 tuple 或 template 顶着先,而这些资讯只能透过社群的部落格文章得知。

    Nim 的宏比较复杂,而说明文件不太清楚;说实在的,笔者试着读官方网站和 Nim in Action 中和宏相关的部分,但还是无法有效地写出可用的宏。不过,宏这类的功能本来就比较进阶,平常在写程序时不太会天天写宏,即使在其他语言也是如此。Nim by Example 最后一个例子就是用宏写 OOP 程序,但笔者自认为一般写程序的人不会这样绕一大圈去建一堆 boilerplate code 后才去写物件,这些东西应该要由开发团队帮我们写好才是。

    Nim 编译器的错误讯息也有一些问题,某种程度造成学习的困难。刚开始写 Nim 程序时,往往无法第一时间猜出错误讯息所要表达的意思;由于 Nim 是一个相对冷门的语言,即使试着 google 也要稍微猜一下才知道这些错误讯息是什么意思;虽然在写一段时间 Nim 程序后可以逐渐适应 Nim 编译器的错误讯息,但这一来一往的过程可能就会赶跑一些潜在的使用者。像 Rust 的编译器是龟毛出名的,但是 Rust 编译器的错误讯息就很明确,Rust 开发团队甚至做了网页来补充说明每个错误代码背后所代表的意义,让使用者有足够的讯息来调试。

    Nim 的套件,不论是标准套件库、官方出版第三方套件还是社群套件,也是 Nim 相对较弱的一环。观察 Nim 的套件,似乎没有一个明确的目标市场,有 GUI 套件 (nim-lang/gtk2)、网页框架 (dom96/jester)、游戏框架 (zengine),以及一些其他的套件。从这些套件看起来,Nim 像是一个通用型程序语言,但却没有足以吸引程序设计者转枱的点;如果去把玩一下,说明文件也是相对稀少。像 Go 很明确地就是用在网页及服务器程序程序,Go 甚至没有官方的 GUI 套件,很多领域也是放任社群自行发挥;但 Go 的确有满足到某个特定领域,像中国许多的科技公司正在或已经将其后台转到 Go。

    不论 Nim 或是其他新兴编译语言,开发环境总是会比较复杂。由于这些新兴语言不太可能一夕间取代 C 的生态圈,往往都会透过 binding 的方式沿用 C 语言写的函式库。除了自身外,还要顾及 C 开发环境,项目的相依性就会变得更复杂。偏偏 Windows 又是对 C 不友善的平台,使得这个情形更加恶化,笔者曾撰文讨论过这个问题,有兴趣的读者可看这里。相较起来,虽然 Java 或 C# 的虚拟机器很肥,但这种模式的确大幅简化项目的相依性需求;Java 平台除了无数的函式库,上面还出现一大堆 JVM 语言,人们对 Java 平台的依赖程度又更深了,至少在这几年内 Java 生态圈还是相当有市场的。

    Nim 的核心理念相当良好,但仍然有许多需要努力的地方。或许再过一段时间,Nim 和 Nim 的社群会更加成长,到那个时候,我们就可以看到更多 Nim 相关的应用。笔者最近开始发表 Nim 程序设计相关的文章,欢迎各位读者到这里观看。

    【赞助商连结】