凹语言开源1周年直播逐字稿 #

• 时间：2023-09-13
• 转载请注明原文链接：https://wa-lang.org/smalltalk/st0032.html

项目起源及动机？ #

柴树杉：

2004年前后上大三，当时对C语言函数/if/for等工作原理感兴趣，当前就申报了一个玩具语言的题目，是将<编译器原理与实践>书中的Tiny语言翻译到CASL汇编（补充：CASL是早期软考中定义的汇编语言）。完成该项目后算是搞明白了基本的分支循环到汇编语言语言的翻译过程，当时还发过一个《CASL汇编器的设计》论文。

毕业后编程语言的事情一放十多年，几乎是彻底忘记了。然后就到了2018年中美贸易对抗，作为码农也到了焦虑的年龄，开始思考后半生的职业方向。作为作为程序员三大浪漫的核心、传承计算机文化的编程语言，在国内依然是技术荒漠。云原生领域最流行的Go语言，第一个“hello，世界”中依然跑的是日文！

2017年前在武汉航天远景做过Emscripten相关的探索和实践，丁对WebAssembly做过一个断言——“一切可编译为 WebAssembly 的，终将被编译为 WebAssembly。”后来该断言被逐渐验证，在2018年8月作为Emscripten的继承技术的WebAssembly也发布草案。我和丁尔男也算是国内最早从事该技术实践的同学，因此基于在远景的实践经验上结合新草案出版了《WebAssembly标准入门》一书（活动赠送1本）。

作为半老码农，本着为自己定制一些工具的想法，我们想针对WASM平台精简定制Go语言。在2018年底我们想到了“凹语言”这个名字，这不仅仅代表着WASM的初始目标，也表达了某些“躺平”的梦想。但是启动一个新语言的阻力是360度全方位的，我们甚至根本没有敢对外宣传这个事情——只是悄悄地注册了域名并在github创建了组织，之后就是近乎3年的沉寂。

在2019年国外分别诞生了TinyGo、AssemblyScript和V语言等项目，这些同类或近似的潜在竞品都为我们提供了宝贵的路线参考。此外WASI规范诞生，其中内容几乎完美验证我们在2018年对WASM技术的推演，这也无形中增加了我们的信心。因此在2019年我们开始深入研究Go语言语法树部分的内容，希望基于这个肩膀连接凹语言的前端。

到了2020年疫情开始期间，我们邀请到了LLVM社区专家史斌的加入，到此凹语言三个联合发起人组织初步成型。2020年最重要的成果是几个发起人对凹语言的目标达成了共识——我们不做玩具车！可以说“不做玩具车”是凹语言后来发展方向和各种决策的基础原则。在2020年，三个发起人还完成了《Go语言定制指南》一书（我们活动赠送1本），至此凹语言未来发展路线的关键技术均已完成理论准备。

时间再跨越2年到2021年底和2022年初，结合内外各种环境的变化，我们开始正式启动凹语言的实现工作，并在2022年7月完成了凹语言的开源工作。开源之后，逐渐有社区小伙伴加入都给项目注入了极大的活力。然后就是开源社区公开发生的事情了。

“凹语言”名称及内涵？ #

丁尔男：

因为编译目标定为Wasm平台，所以刚开始起的名字是Wa-Lang，也就是WasmLanguage的缩写，有一次突然想到，凹凸不平的凹字曾经有另一个读音正好是Wa，并且凹字的形状跟Wasm的图标挺相似，都是个上边缺了个口的方块，这种象形文字特有的形状读音双重相似的巧合，我们觉得挺有趣，于是把名称定为了现在的凹语言。在凹字上简单添加了几笔，就成了笑脸似的Logo。虽然凹现在不是多音字了，有的朋友喜欢读作ao语言，这也没有错，怎么念都对，作品面世后所有人都有解读的权利。

为何开源协议使用 AGPL v3？ #

柴树杉：

2022年刚开源的时候，凹语言尚未明确开源协议，采用的是保留全部权利。当时有人在网上质疑：说凹语言开始大量使用了Go语言的代码是BSD，凹语言改为自有协议是否合适？这里我说明下：BSD协议是不阻止、甚至是鼓励拿来商业化和私有化的，因此凹语言当时做法没有任何问题。但是我想他是在隐晦质疑开源道德——网上总是会有各种声音！

后来经过多次会议讨论，我们采用AGPLv3协议。这是是因为我们不想草根团队用爱发电的开源项目被商业公司白嫖。有几个前车之鉴：开源的MongoDB被AWS白嫖后改了SSPL协议被OSI等道德指责；HashiCorp将 Terraform 等核心资产从 MPL 改为商业的BPL；Facebook开源的大模型采用附加商业限制的开源协议；Qt直接回到商业协议。

为何OSI会拒绝SSPL，为何能接受GPL？这背景是因为OSI是代表商业公司在和GPL和SSPL等代表博弈的结果。凹语言采用AGPL是因为它是OSI认证的限制最严格的协议，否则很多平台会说你是伪开源（感情“开源”的解释权是你OSI家定义的吗？）

我只想说：开源真是用爱发电，但是开源者不是傻瓜。为众人抱薪者，不可使其冻毙于风雪！MongoDB的选择必须鼓励，而抵制和限制GPL协议的头部大厂才是需要指责！

为何选择 Gitee？ #

丁尔男：

确实，经常有人问：你们为什么不把主仓库放在GitHub？原因之一是安全性。我们期望凹语言项目的存续时间能达到五年、甚至十年级别，在这么长的周期中，一些大家认为理所应当的服务是否还能轻易获取，其实存在很多不确定性。如果GitHub不再支持中国用户的双重验证，那么重建社区需要很高的成本；或许这种情况并不会出现，但过去这几年发生的很多事情表明，貌似中立的技术和服务被武器化的威胁是切实存在的。

另外，Gitee的CLA管理功能非常好的满足了我们的一个刚需。刚才提到项目的存续周期可能很长，无法在项目一开始，就制定一套永远不需要变更的最佳制度，随着项目的发展，凹语言采用的协议可能发生变化，运作模式也可能发生更新。如果没有部署CLA，那么这些涉及项目基础的变动将很难合法的推行。Gitee的CLA管理在站内完成了贡献者身份确认、协议签署，整个动作整合到了pr流程中，形成了闭环的证据链，这远比线下收发协议文档的方式更高效、更严密。

组织形式？ 如何做决策？ #

丁尔男：

目前项目决策和主要的开发推进工作是由凹语言临时决策委员会完成的，这个机构我们平时简称临委会。根据临委会章程，语法或运营模式的变更需要由委员发起提案，经临委会投票通过后才能公示生效，也就是说委员可以通过发起提案，以及对提案进行投票的方式来对项目路线施加影响。除了在自己负责的方向持续推进之外，临委会委员还需要处理各种日常事务，比如开发会议组织、参加各种交流、评奖活动等等。有人一听机构名字中带有“委员会”三个字就说：你们这是个专制组织既不公开又不民主，不是真开源；其实我想问：怎样才算“正常”的开源社区？责权对等是公平性不可缺少的组成部分，除了三位联合发起人外，负责宿主框架以及外部工具链的扈梦明、和负责中文语法的赵普明，这两位委员都来自社区。编程语言项目出圈概率低，贡献难度大，早期的主要参与者承担了更多风险。说到底，人，才是开源社区最宝贵的财富，有些社区把项目存续放在第一位而忽视贡献者的做法我们并不认可。向关注者分享知识和经验、公平对待参与者、记住所有的贡献者，凹语言项目始终把人放在第一位，临委会也好、贡献点也好，所有的制度和约定都是为了保障这一点。临委会并不是一个封闭的机构，目前项目还处于早期，很多坑等着人占，有意负责具体方向的小伙伴可以和任意委员联系，讨论加入事宜。当然如果嫌临委会事务太繁重也没有关系，开发组始终欢迎大家以任何形式参与。

社区日常如何交流？ #

扈梦明：

凹语言项目目前借助了不同平台构建了多种沟通的渠道，包括：国产语言论坛、QQ 群和微信群等。众所周知，对于开源项目而言，沟通是一大关键点，能够更好地推动项目的持续发展。我们也深知这一点，所以构建了多个沟通渠道，以便感兴趣的同学都能参与其中。在国产语言论坛中，我们会着重讨论有关凹语言本身的细节和发展的话题，而在 QQ 和微信群中会一起探讨更为丰富的内容，比如多语言、编译器、WebAssembly、VS Code 等相关的话题。对于那些引起激烈讨论的话题和知识点，我们都会进行总结，并发布在官网的“碎碎念”专栏中，做到每一次讨论不止于表面，能够得到深入有效的沟通和总结。另外，我们还会不定期通过腾讯会议的形式，与大家分享凹语言在开发过程中的挑战和收获，不仅让大家了解凹语言的最新进展，同时也分享项目成长的收获。而我也是在微信群聊中找到了自己在凹语言中比较感兴趣的事情，进而一步步融入到凹语言团队中的。

贡献点制度是什么？ #

赵普明：

贡献点制度是凹语言社区用来量化记录和激励社区贡献的制度。 基本设计：社区从2022年开始，每年产生10万个贡献点，所有参与项目并产生贡献的人，都可以按照贡献量获得贡献点。贡献的工作可以是代码、文档、参与会议讨论、参与宣传等一切需要花费功夫的工作。分配周期为1年一次或半年一次，需要发起决策提案，由决策委员会负责工作量的鉴定和贡献点的划分。贡献点的分配流程和结果都会记录并在社区文档中，并公开展示。

到现在为止，已经进行了3次贡献点分配，共计15万点。这些贡献点分给了12名同学，数目从35000到2000不等。

现在贡献点的作用主要是用来量化记录社区成员的贡献。等到社区成熟之时，社区的决策制度将转为公开投票制度，到时候贡献点可以用来调整投票的权重，即贡献点多的人可以投出更多的票数。最后，如果这个项目未来能够产生商业价值，那么收益分配阶段也可以用贡献点作为参考。

现状、MVP内容？ #

柴树杉：

开源推荐早发布多发布，MVP可以说是凹语言对用户的第一次稍微正式一点的发布，也算是对2023上半年成果和开源1周年进展的总结。MVP也算是某种承诺，MVP手册说明的语言特性会保持向后兼容，通过更大范围试用获得更多的反馈。MVP是一个承上启下的作用。

丁尔男：

凹语言立项目标可以概括为一句话：提供一门使用负担小的通用语言，用于WebAssembly模块的开发。Emscripten编译C++代码到Wasm很成熟，我在工作中也用这条技术路线开发过一套相当复杂的实景三维网页应用平台，但C++算不上对开发者友好，尤其需要多人合作的复杂项目，对参与者的要求很高。实际使用过的语言中，我们认为Go语言在易用性和消除不确定性方面有很多成功的设计，所以凹语言的语法是以Go为蓝本设计的。那为什么不直接用Go呢？问题在于Wasm模块在很多场景中是一个被宿主程序调用的库，它最好是纯被动的，页面或者容器不调用你，你啥也别干；而Go语言是为服务端而生的，它的运行时处于主动调度状态，这两种运行模式的差别使得用它开发Wasm库时，容易遇到一些违和的、不符合直觉的问题。

凹语言和Go是师徒关系，保留了很多相似的特征，比如内存是自动管理的、提供了原生的字符串类型、接口使用隐式合约等等；从分类上来说，也属于静态数据类型的编译型语言。另外凹语言对中文标识符更友好，实际上不仅是中文，所有名称为unicode的变量、函数都可以正常导出。

8月12号，项目组发布了凹语言最小可用产品（MVP）。这个版本实现了大部分的核心语法特性，可以以此为基础进行标准库的开发，同时我们提供了相对完整的手册文档和免安装的在线环境，便于大家了解、试用凹语言。

下面是一个典型的凹语言程序，它由导入、常数、全局变量和函数声明组成。下面这些是MVP支持的基础数据类型，包括9种整数、两种浮点数、以及原生字符串。这些是各种基础类型的操作，涵盖了常用的算术、比较、逻辑、位运算以及引用和解引用。

这些是MVP支持的复合数据类型，包括引用、数组、切片和函数值。引用类型的行为和指针几乎一样，但从运行时的角度看，两者并不相同，所以我们没有使用“指针”这个术语；函数也是一种可以被传递的值，和C语言的函数指针不同，凹语言的函数值可以携带状态，所以原生支持闭包。

自定义类型的结构体可以拥有方法，也支持通过匿名嵌入来进行功能组合，在“不使用继承而是使用组合”来扩展对象这一点上和Go一脉相承，但是在凹语言中，方法声明和方法内对成员的访问风格，更接近C++。

MVP支持了完整的接口特性，包括空接口作为值容器、接口值具体类型断言、满足多接口的具体类型的接口互查等等，这些特性是抽象能力非常重要的组成部分。

少数特性MVP尚未实现，主要有三个：map、反射以及defer。另外目前的版本中，有一些运行时行为不满足语法定义，比如切片下标没有做边界检查、孤环内存会泄漏，但随着编译器的更新这些问题会自动解决，不影响向后兼容性。

MVP的内容相对还是很多的，我们准备了手册对它的边界进行说明。大家也可以在Playground游乐场进行试用。Playground是一个纯网页版的测试环境，可以直接输入凹语言代码，在线编译运行。如果发现了任何问题，欢迎到Gitee仓库提Issue。

发展过程心得？ #

柴树杉：心理挑战从立项开始贯穿始终

我觉得心理是最大的挑战，凹语言始终受到这个心理影响：作为半路出家的非计算机专业出身、非编译器从业者，我不认为有能力达成这个梦想。在刚刚工作阶段，我甚至没有敢想从事这个方向的工作。我一直在幻想未来十年，国内的专家和头部大厂或许会解决国产编程语言的问题。但是，我从来没有幻想自己能有机会参与其中。

2010年Go语言开源后国内Gopher疯狂关注，我也为其贡献了BMP/TIFF等图像库，2015年第一时间翻译了《Go语言圣经》。这些经历让我第一次近距离围观一个现代化语言的诞生和发展的过程。或许我也可以尝试做一个自己的编程语言，后面的TinyGo、V语言都给了巨大的心理帮助。

2022年紧急决定开源，当时的一个想法就是想通过开源激发项目发展，或者提前死掉。因为，当时凹语言作为一个纯草根项目，我们担心一些有资本和国家背景的竞品语言出来后，凹语言将失去被关注的机会，我们自己也将失去继续的信心。这里要特别感谢CSDN在凹语言启动阶段的支持，让凹语言在开源阶段获得了一些关注。

然后在开发过程中，每一个阶段和成果之后都会发现新的广阔的空间需要我们建设。比如随着项目的发展代码变得开始膨胀，像早期的Arduino Nano33环境的例子已经不能执行。在每一个时刻都会担心突然冒出一个咋看起来不起眼的问题把我们击垮。除了技术也有其他的因素，比如核心同学可能遇到工作变化就可能让项目停滞。我每天都在想着会出现哪些风险、竞品可能会带来哪些影响、有限的资源该投向哪个方向，这个项目会怎么样死掉等？

Qt、Go是我以前常梦到的2个关键字，现在是凹语言，但是这次还伴随着危机感。

扈梦明：草根项目推广渠道有限，感谢媒体及平台支持

对我们这种纯草根的开源项目来说，流量、知名度始终是稀缺资源，而且舆论环境对编程语言项目的宽容度还有待提高。我们在中立论坛收到负面评价明显更多：有批评东西都没做好就跑出来炒作的，有质疑开发过程不透明是假开源的。国内几个没有资源背书或支持的开源语言项目，或多或少都有类似的困扰。耗费业余时间参与没有物质奖励的项目，却很少收获正面反馈，这无疑挫败了成为贡献者的积极性；再叠加本来就很小的受众基数，构建能够持续发展、自我迭代的社区，对包括凹语言在内的很多草根项目来说非常困难。所幸的是我们得到了一些媒体机构和平台的支持与认可，InfoQ、中国互联网发展基金会、GitLink、OpenTEKr 和 Datawhale 社区，通过“开发者最喜爱十大开源项目评选”、“中国开源创新大赛”、GLCC2023 编程夏令营、2023世界人工智能大会“开源集市”等活动给了我们参与机会，CSDN、OSC也为我们持续推广，非常感谢机构对我们的帮助。当然，最重要的是那些一直支持凹语言的朋友们，你们是我们前进的最大动力。

赵普明：业余爱好者如何参与

作为半路加入项目的业余爱好者，我最初遇到的困难是“业余爱好者如何参与到编译器开发工作中来”。

众所周知，编译器开发是一个很“高大上“的项目，有很高的技术“门槛”。就我个人而言，尝试过几种玩具语言之后，就再也没有实质性的进步了。有“三座大山”一直没有跨过：龙书虎书等大部头书籍，缤纷繁复的算法，以及gcc/llvm这样的巨型工程。我曾经以为，只有读完了龙虎书，各类优化算法了熟于心，并读懂了LLVM或GCC的源码之后，才有足够能力去从事严肃的编译器开发。

去年因为偶然的原因，我发现了凹语言的前置项目μGo，这也是《Go语言定制指南》一书所对应的项目。μGo保留了Go最关键的几个特性，并重新实现了一遍。而凹语言正是在谬Go的基础上进行开发，扩充或修改了语法，添加了wasm等后台而实现的。当时，我正好也读完了另一本类似的书《用Go语言自制解释器》。这两本书的代码都用Go语言编写，也都参考并简化了Go官方编译器的实现。两相印证地学习之后，我突然有了一丝融会贯通、登堂入室的感觉。连以往理不清的Go编译器源码，也突然清晰了起来。编译器开发这个高高的门槛，就这么顺其自然地跳过去了。后来我也就自然而然地加入到凹语言的开发中来了。

那么这个门槛是怎么跨过去的呢？刚才说的三座大山为什么难于跨越？根本原因是它们并不是为了“学习编译器开发”的人而准备的：龙书虎书以及各种优化算法，面向的是那些未来从事编译器理论研究的人，所以他们会更关注理论的知识，描述也更偏数学偏严谨，不适合普通程序员。而LLVM和GCC这些编译器工程，本身是为了工业级应用而设计的，充斥着大量的工程细节：各种优化算法、多个平台的适应、以及C++带来的各种高阶特性。对于刚学完玩具语言的初学者来说，这些知识都太遥远，太高阶了，很难从到一条平坦向上的学习道路。“玩具语言”太容易，“严肃编译器”又太难，而《Go语言定制指南》和《用Go语言自制解释器》这两本书，以及凹语言项目本身，则恰恰提供了一个很好的中间桥梁。

• 首先它们是用Go语言实现的，而Go语言的可读性远高于LLVM或GCC的C/C++。
• 其次，Go语言编译器的源码仍然比较复杂，但恰好这两本书的源码都提供了一个简化版本，读完之后再去读Go编译器源码就容易多了。
• 凹语言的特性比Go语言更精简，现在也处于早期阶段，相对于Go语言编译器来说，它的运行时实现简单得多，更容易上手。
• 最后，凹语言提供了很多可以容易上手参与的工作，如文档、测试、工具和标准库等。我个人就是通过中文前端这个独立的模块参与进来的。
• 团队人都很好，相互学习。每个人都有自己所长。

总而言之，凹语言很适合作为编译器开发爱好者的切入点，欢迎广大的编程语言爱好者都能参与进来。未来我们也会在这方面做出更多的努力，提供更多的方便，让所有人都能更加平滑的加入编译器的开发。

最想分享的体会或经验？ #

柴树杉：草根团队驱动编程语言项目的天然优势

编程语言是一个短期内毫无商业价值，但是对应长期生态的基础软件技术。资本公司都是逐利的，完全不符合大公司为结果买单、为过程喝彩只看短期KPI的价值观。比如当ChatGPT结果之后，国内头部厂商预定50亿的英伟达h800芯片，这就是为结果买单。从ChatGPT的例子可以看出很多大厂是缺乏长期的战略定力的，很多时候是奉行投机主义。因此大厂驱动需要长期投入编程语言项目会面临诸多困难：比如内部为了获得更资源、外部为了获得爆炸性新闻，都会不自觉放大技术的指标和先进性；这些放卫星式的投名状随时都可能是击垮项目的最后一根稻草。

对于草根团队，因为缺少资源必然是小团队，能坚持投入一个缺少短期商业价值的项目的必然是真正的编程语言爱好者。简言之，草根编程语言团队必然是以极低成本方式运作，正所谓凹语言推崇的 slow is fast——低成本效率低让项目团队具备长期运行的潜力（凹语言从立项到现在时间将近5年）。同时草根小团队因为缺少KPI的压力，在实现过程中可以降低技术变形的风险，可以更坚持项目的初心和突出项目的个性口味。

可以对比目前的主流编程语言：C/C++，Java，Python，Ruby，Lua，Go，TypeScript、Swift，他们的创始人都是个人在驱动。当然，如果大厂的编程语言团队能够彻底摆脱KPI的魔咒或许会有更大的潜力。但是我本人对此不报太大的希望，因为在群众、公司、团队、员工中间存在着一个极长的猜疑链。开源可能是打破猜疑链的一个可行方式。

扈梦明：面对开源项目时，如何找准定位，参与并赋能

在学习 Go 语言的过程，机缘巧合的知道了凹语言，并且加入了社区的微信群。在日常的讨论中得知，凹语言团队由于精力有限暂时还没有对 VS Code 插件的支持，发现和我最近研究的方向非常吻合，于是找到柴树杉，想参与到凹语言的建设中，就这样成为了首位社区成员。在完成前期 VS Code 的语法高亮、格式化、代码运行等功能后得到了团队的鼓励和支持，但是同时也陷入了迷茫，因为感觉自己并没有为团队建设做出太大的贡献，支持的内容不够底层，没办法凸显个人在团队中的价值。而柴树杉和丁尔男一直告诉我说，对于语言而言外围的支持，开发者体验才是最为重要的。在这里也是非常感谢两位对我的鼓励认可和支持。而我也在不断地反思和摸索中完成了凹语言官网的重构和在线 Playground 的开发，内心才算是坚定了自己在团队中的角色和定位。在心态转变中发现融入开源团队其实很简单：只需要找到自己的专长并持续为团队做出贡献，从而实现赋能。当然也离不开团队成员的鼓励支持和帮助。这也就是凹语言团队的魅力所在，其多样性和包容性让每个人都能在团队中发挥自己的专长。而且在与团队伙伴们交流过程中也能收获到不同领域的知识和经验。另外，俗话说出名要趁早，越是处于早期的项目，可贡献的方向越多，参与越容易。

赵普明：中文语法设计的探索和演变经历

我现在在凹语言项目中的主要工作是中文语法的设计和实现。现阶段中文语法还处于探索阶段，没有定型。关于中文语法的设计，我的第一个体会是“众口难调”：既想要有编程语言的精炼性，又想要有自然语言的易读性；如果设计的太精简了，会有人说”这是文言文吧？“；但要是设计的太直白了，又会说”这和英文版有什么区别？不就是翻一个关键字吗？”；做一些更适合中文的语法结构，会说“这个干嘛不采用英文的语法，是为了创新而创新吗？“。连”if“关键字中文用”如果“还是”若“都可以争论半天。我之前做了初步的设计和实现，经过一段时间的讨论和思考，打算应用凹语言的社区决策制度来重新决定中文语法的设计：把整套语法拆分成不同的部分，分别写出提案，征集各种方案，再经过讨论和决策委员会的投票定下来。这会是一个比较繁琐的过程，但我认为是不错的社区化尝试。在这个过程中，我也在不断学习和总结各个编程语言的特色，看看能不能做到采众家之长。最近正在看Haskell。第二个体会就是实现比设计更重要。语法只是本子上的字符而已，而真正去写代码、去调试、去改错，最终执行成功之后，才能有更深刻的体会。中文语法在凹编译器里暂时只涉及到前端的工作，即从源码文本转化为凹语言的标准AST的过程，这里有一个很方便的情况：整个开发流程实际上英文版已经做好了，我最初只需要复制英文版的Lexer和Parser，并尝试一条条语法进行修改即可，后面的代码生成到测试执行流程都已经很完备了。因此我有种感慨，我选择的这个中文语法，确实是很好的学习编译器开发的切入点。最后一个体会是，实现中文语法后发现了一个新的独特的需求，即凹标准库是用英文写得，那么我们如何用中文去调用英文的库函数？如何访问英文实现的结构体？编译器需要在中英文代码之间架起一道转化翻译的桥梁。

丁尔男：“语言项目高门槛”可能是种偏见

有一些感觉想跟大家分享。我1996年进了武汉大学计算机系，所有专业课里面，拿到成绩最好的是何炎详老师教的编译原理这门课。即便如此，工作了快20年也没动过搞通用语言的心思，因为之前总觉得这东西神仙才能玩得动，和普通程序员没啥关系。但凹语言一步步走过来，我意识到之前的看法可能是种偏见。很多软件问题有一个共同特征：就是如果要求所有的指标都拔尖，复杂度会急剧上升，而只要降低某些指标，系统就可以大大简化。我们平时接触到的大多是在各自方向被优化到极致的通用语言，所以很容易忽略，编译问题其实也符合这一规律。从实践角度来说，虽然编译器通常按照解析、转换、代码生成的流程执行，但学习上手并不一定需要严格遵守这个顺序，我选择的路线是从抽象语法树入手向前后两端扩展，因为抽象语法树在编译过程中起到了承上启下的作用，两套不同的语法可能背后对应的是同一个语法树（就好比凹语言的中文语法和英文语法看起来风格迥异，但实际上对应的是同一套AST），再加上市面上成熟的语言已经非常非常多，只要不是特别非主流的设计，大概率能找到AST风格相似的语言，然后按照自己的审美进行改造，这样就可以极大的降低启动阻力。总的来说只要不把目标定得过高，并且选择合适的路径，和其他类型的项目相比，语言项目在技术上并没有更难；而最需要克服的困难的反倒是跨出第一步的犹豫不决。凹语言项目组2020年就成立了，但我们花了2年时间才做好跨出第一步的心理准备，回过头看，其实很多技术层面的担忧都是没有必要的，内耗了大量的时间精力。如果今天有正在筹备或者将来有可能发起类似项目的观众，希望这些经验教训能给大家一些启示。

规划、展望、寄语？ #

柴树杉：

MVP后继续完善标准库，希望在2024年上半年能发布带标准库的MVP。另外围绕标准库，再构建1-2个案例。个人收益：满足自己对技术的追求，为后半生的职业生涯找到一个方向。社会效益：希望能带动国产语言和社区的发展，行业能多一些编程语言领域的声音。

寄语：如果编程语言是您的真正兴趣，不要被网上各种编译器比你聪明、ChatGPT将淘汰码农行业、龙书是PL必读图书等观点影响，只有自己摸索找到的路线才是最适合自己的。

扈梦明：

MVP 后的发展规划：完善 VS Code 插件功能：LSP、Debug、Test 等功能。继续探索研发其他 IDE 插件相关内容，担起提高凹语言开发体验的责任。重构在线 Playground，并引入新玩法，新特性，为凹语言增加不一样的色彩。参与宿主框架、 FFI 整体工具链的建设中，让开发体验更加完善。期望的收益：希望能够学到更多不同领域的知识，提高个人技能。也希望不同社区平台的同学们对凹语言多一些理解和包容

寄语：有趣比有用更有意义

丁尔男：

“有限的精力和无限的待办列表”始终是主要矛盾，我这边接下来需要完成核心语法剩余部分的实现和测试。另外有一些新的方向等待启动，首先是增加SourceMap为调试提供支持；然后是加入一些必要的优化；刚才扈梦明提到的FFI也是个重头戏，设计的好坏会直接影响库开发的可用性。刚提到的这些是具体的短线目标。我们有一个中期目标，那就是自举。因为“不做玩具”这句话如果没有经过大型项目的验证，那就只是一句口号。在缺乏应用项目的情况下，自举是一个很好的证明语言有能力解决复杂问题的途径，有心的观众应该已经发现了：凹语言的技术路线和很多具体的取舍都是围绕自举这个目标进行的。

参与凹语言项目这件事情，是我作为一名天赋平平的普通开发者、试图掌握工具（也就是编程语言）本身的一次尝试。不论结果如何，如果参与者觉得自己获得了一些经验、关注者觉得自己看到了一个还不错的故事，大家都认为自己的时间没有完全白费，那么就意味着项目获得了巨大的成功。

赵普明：

短期：我接下来的计划第一是完善中文语法，并完整实现出来，做到对英文语法的100%跟进。第二是做好中英文代码的桥梁，尤其是标准库的桥梁。中文MVP。中期：更深入地学习中端优化和后端代码生成的知识，读完龙书虎书，扩大可以贡献的领域。第四，用凹语言中文版开发一个自己设计的应用框架，我的初步设想是一个2D图形框架，可以用来做小游戏。收益：用自己设计的语言开发出自己设计的应用或框架。这应该是程序员能得到的最满足的回报了。

寄语：书山有路勤为径，码云无边凹作船。