高三生，为keylang及其作者送上美好的祝福！

[Glomzzz]

我不明白为什么有些人戾气那么重（ 可能是因为将自己曾经没有获得到某些事物的情感反射到作者身上了吧（？）

总之作者加油喵！

[dao-jun]

虽然但是，一个opensource项目如果经不起批评，那还不如设为private自己玩

[dao-jun]

BTW，我刚来，但我真有点看不下去

可能是因为将自己曾经没有获得到某些事物的情感反射到作者身上了吧

谁教你的就这样随随便便口出诛心之言的？谁教你的随随便便以最大的恶意揣测别人心理的？

[Glomzzz]

虽然但是，一个opensource项目如果经不起批评，那还不如设为private自己玩

首先开源项目为什么一定要经得起批评，都开源了还想怎样？ 其次开源项目应该经得起批评，也不应该经受 "这是我阅读过最差的代码，没有之一" 这样的批评

请不要道德绑架开源项目的贡献者，也不要为大庭广众之下发表过近似人身攻击言论的人再做辩护。

BTW，我刚来，但我真有点看不下去

可能是因为将自己曾经没有获得到某些事物的情感反射到作者身上了吧

谁教你的就这样随随便便口出诛心之言的？谁教你的随随便便以最大的恶意揣测别人心理的？

比起keylang作者几个月的心血被人喷成：

"这是我阅读过最差的代码，没有之一。"

我的这句：

可能是因为将自己曾经没有获得到某些事物的情感反射到作者身上了吧 (?)

显然攻击性有待提高。

我只是在表达：这并不是诛心之言，也不是恶意揣测心理，只是去分析一下某人的心理，让他先审视一下自己再去审视他人。

我觉得你也该审视一下你自己哦。

[Glomzzz]

点错了，不小心close了。

[Glomzzz]

@dao-jun 抱歉喵，我不太想参与进来讨论，因为我还在忙项目。

不过这件事倒是让我回忆起了我的过去：

万恶之源喵

14岁多写出了第一个小parser，当时只花一下午的精力，暴打了某社区内一个叫kether的dsl（从功能到性能）

受到了社区内很多人的鼓励，这使我信心爆棚

这部分是我前进下去的动力。

当然也有人批评，但他们只是提出要改进的点，还有让我加油，不要骄傲，路还很远 etc

这部分让我真正看清了自己的实力，让我心怀更远大的目标脚踏实地继续走下去。

于是我就入坑PL了，一直到现在。

（抱歉我太年轻了，现在才过了2年多。。）。

以我来看

如果一个14岁的小孩子将自己满心热血编写的项目开源到网上，却收到"这是我阅读过最差的代码，没有之一"这样的恶评，

我说不好我是否能继续坚持下去，毕竟有句总结说的很好：

"z世代最需要的是鼓励，而不是恶评"

大部分z世代的原生家庭与社会环境所给予其的压力已经很大了，互联网没准是他们唯一能倾诉自我的场所。

所以我一向持"积极地批评"的态度：

• 我不想看到一个年轻人因为一点小小成就就心高气傲，飞扬跋扈，好高骛远。

• 我更不想看到一个有志于此的同龄人因为某些恶评丧失了动力，丧失了希望，丧失了生活中那最后一抹光。

注：现在回头看两年前的代码，哎，难以言表。

我每天都想着什么时候能有时间重构一下呢，重新建构出来它存在的意义。

也许是时候了，待我从fp那边取完经就去重构！

[dao-jun]

我只是在表达：这并不是诛心之言，也不是恶意揣测心理，只是去分析一下某人的心理，让他先审视一下自己再去审视他人。

这种还不是不是诛心之言？你这并不是分析，就是恶意揣测

比起keylang作者几个月的心血被人喷成：

"这是我阅读过最差的代码，没有之一。"

不是说一件东西你付出了很多心血，就会有好的结果，好的评价的。很多时候你认为的心血在别人看来一毛不值，你如果进过一个公司，接触过商业级项目你就明白。当你维护前人写的shit的时候，你最好也能像你现在讲的这样。

首先开源项目为什么一定要经得起批评，都开源了还想怎样？ 其次开源项目应该经得起批评，也不应该经受 "这是我阅读过最差的代码，没有之一" 这样的批评

开源项目本身就需要面对各种各种的好评差评甚至恶评，有些人比较激进，评价的也比较激进，这很正常。 现在这个项目还在草创阶段，很多东西没有到积重难返的地步，接受别人较为激进的评判并不是什么坏事。

可能是因为将自己曾经没有获得到某些事物的情感反射到作者身上了吧（？）

你这句话已经近乎人身攻击了，在社区乃至于其他地方，这种言语都不应该出现

[Glomzzz]

你说得对，我双手双脚赞同喵！

抱歉昨天实在是没时间辩论，所以草草了之回复了。

可能是因为将自己曾经没有获得到某些事物的情感反射到作者身上了吧（？）
你这句话已经近乎人身攻击了，在社区乃至于其他地方，这种言语都不应该出现

我现在认同你的观点，我不该草草说出这样过激的言论。

我现在应该再申明一下：

• 我分析的目标群体不仅仅是yiyue，也包括很多b站恶评，那些家伙更是重量级。

和那些家伙一比，yiyue算很礼貌的了，我在发这个issue的那天也在 #30 关心过 yiyue。

所以请不要认为我针对的只是yiyue喵。。。

然后我觉得我应该指出几个逻辑谬误（？）

不是说一件东西你付出了很多心血，就会有好的结果，好的评价的。很多时候你认为的心血在别人看来一毛不值， 你如果进过一个公司，接触过商业级项目你就明白。当你维护前人写的shit的时候，你最好也能像你现在讲的这样。

经典诡辩，显然keylang作者依然是个未成年 （或刚成年）的高三学生，keylang也只是他开发的一个语言

• 首先keylang属于他个人的toy，并不是什么正式的大型项目，更不是什么商业级项目，所以用上文那个例子并不妥
• 其次 你如何看待一个项目 和 你如何评价这个项目，在某些情况下是两码事。前者反映了你的技术水平，后者反映了你的道德素质。

开源项目本身就需要面对各种各种的好评差评甚至恶评，有些人比较激进，评价的也比较激进，这很正常。 现在这个项目还在草创阶段，很多东西没有到积重难返的地步，接受别人较为激进的评判并不是什么坏事。

我本来想站在“他还是个孩子”的角度去反驳，但现在我发现我才是那个孩子，你这段话说的有道理。

我今天中午才意识到：

• 我的大部分目标群体并看不到这个issue，他们只在乎自己能不能对着某个事物宣泄，并不在乎那个事物会怎么样。

现在看来参与进来讨论的都是好人啊，我属于是对着友军贴脸开大了。

抱歉。

[Reqwey]

支持楼主和作者~大家都很棒，本人也是高中生，在准备高考，一起加油啊！

[Glomzzz]

支持楼主和作者~大家都很棒，本人也是高中生，在准备高考，一起加油啊！

加油！

[yongrongwang]

这是我阅读过最差的代码，没有之一。

这是用非常严厉的语气批评项目。

可能是因为将自己曾经没有获得到某些事物的情感反射到作者身上了吧？

这是以很大的恶意揣测别人。

事实上对项目提出批评的人没有恶意，属于话糙理不糙，他的建议接受与否的决定权在项目作者。他气不过的是自己建议不被采纳还被控评，但言论还是过激了，我感觉他属于易怒的体质。你支持项目作者没有错，顺便踩一脚批评项目的人是觉得这件小事闹得不够大吗？

[TabNahida]

这是我阅读过最差的代码，没有之一。

这是用非常严厉的语气批评项目。

可能是因为将自己曾经没有获得到某些事物的情感反射到作者身上了吧？

这是以很大的恶意揣测别人。

事实上对项目提出批评的人没有恶意，属于话糙理不糙，他的建议接受与否的决定权在项目作者。他气不过的是自己建议不被采纳还被控评，但言论还是过激了，我感觉他属于易怒的体质。你支持项目作者没有错，顺便踩一脚批评项目的人是觉得这件小事闹得不够大吗？

You should read #30 and you will know why she wrote #12 in such anger.

[Glomzzz]

这是我阅读过最差的代码，没有之一。

这是用非常严厉的语气批评项目。

可能是因为将自己曾经没有获得到某些事物的情感反射到作者身上了吧？

这是以很大的恶意揣测别人。

事实上对项目提出批评的人没有恶意，属于话糙理不糙，他的建议接受与否的决定权在项目作者。他气不过的是自己建议不被采纳还被控评，但言论还是过激了，我感觉他属于易怒的体质。你支持项目作者没有错，顺便踩一脚批评项目的人是觉得这件小事闹得不够大吗？

抱歉，my bad。

我的动机前文阐释过了，并不是想把这件事闹大，而是像看到了过去的自己，将我眼中过去的自己反射到了keylang作者身上，油然升起了一种保护欲，忍不住想分析一下。

其实我的分析的主体其实不仅仅是yiyue，更多的是一些恶意的b站评论（但好像现在被删掉了（？））

我的表达确实过激了，是我的不对，我没想到会不小心刺痛这么多人。

在这里给所有被我的过激言论刺痛的人道个歉。

[Glomzzz]

又点错close了喵

我在事后担心key-lang作者的精神状态，毕竟作者现在是一个高三学生，每天晚上还要面对网上的流言蜚语（哎）

但我与作者交谈后发现是我多虑了，作者真没我想象的那么脆弱，他不是过去的我。

所以我的分析可能并没有我想象中的那么奏效，我的目标群体貌似根本看不到这个issue，但友军被我轰倒了一大片。

现在看来属于是对着友军贴脸开大了（绷）

我现在处于一个很尴尬的状态，哈哈，该怎么才能缓解尴尬呢（急）

[Glomzzz]

[FrankHB]

瞄之前请避免一些错别字，特别是标题里的。看起来太怪了。

如果一个14岁的小孩子将自己满心热血编写的项目开源到网上，却收到"这是我阅读过最差的代码，没有之一"这样的恶评，

这倒未必有多能说明问题，可能单纯就是代码见得少了，这都能大惊小怪。退一步讲，就算明确作为恶评，比起看过就忘的代码，这种反应其实可能算不上是最差的。

[Glomzzz]

瞄之前请避免一些错别字，特别是标题里的。看起来太怪了。

如果一个14岁的小孩子将自己满心热血编写的项目开源到网上，却收到"这是我阅读过最差的代码，没有之一"这样的恶评，

这倒未必有多能说明问题，可能单纯就是代码见得少了，这都能大惊小怪。退一步讲，就算明确作为恶评，比起看过就忘的代码，这种反应其实可能算不上是最差的。

我的输入法有问题，总是打错字喵，没关系，能表达清楚意思就好了。

现在很多z世代孩子的心都比较脆弱，我担心发生一些不好的事，但显然我是多虑了，keylang作者比我想象的坚强得多。

[dao-jun]

你似乎是没太理解大家的意思，我换句话说吧

就像你和队友打游戏，你玩的坑了，队友喷你玩得菜，不如人机。然后你反手喷你队友穷，生活不如意

这是一件很令人恼火的事情

另外一件事就是，其他人是没必要惯着一个陌生人的。你可以心怀善意，谦逊有礼貌又富有同情心，但是人类是多样性的，不是每个人都会像你一样

[Glomzzz]

你似乎是没太理解大家的意思，我换句话说吧

就像你和队友打游戏，你玩的坑了，队友喷你玩得菜，不如人机。然后你反手喷你队友穷，生活不如意

这是一件很令人恼火的事情

另外一件事就是，其他人是没必要惯着一个陌生人的。你可以心怀善意，谦逊有礼貌又富有同情心，但是人类是多样性的，不是每个人都会像你一样

我看不懂这个比喻，但我应该理解了

[FrankHB]

@dao-jun 抱歉喵，我不太想参与进来讨论，因为我还在忙项目。

不过这件事倒是让我回忆起了我的过去：

万恶之源喵

14岁多写出了第一个小parser，当时只花一下午的精力，暴打了某社区内一个叫kether的dsl（从功能到性能）

受到了社区内很多人的鼓励，这使我信心爆棚

这部分是我前进下去的动力。

当然也有人批评，但他们只是提出要改进的点，还有让我加油，不要骄傲，路还很远 etc

这部分让我真正看清了自己的实力，让我心怀更远大的目标脚踏实地继续走下去。

于是我就入坑PL了，一直到现在。

（抱歉我太年轻了，现在才过了2年多。。）。

以我来看

如果一个14岁的小孩子将自己满心热血编写的项目开源到网上，却收到"这是我阅读过最差的代码，没有之一"这样的恶评，

我说不好我是否能继续坚持下去，毕竟有句总结说的很好：

"z世代最需要的是鼓励，而不是恶评"

大部分z世代的原生家庭与社会环境所给予其的压力已经很大了，互联网没准是他们唯一能倾诉自我的场所。

所以我一向持"积极地批评"的态度：

• 我不想看到一个年轻人因为一点小小成就就心高气傲，飞扬跋扈，好高骛远。
• 我更不想看到一个有志于此的同龄人因为某些恶评丧失了动力，丧失了希望，丧失了生活中那最后一抹光。

注：现在回头看两年前的代码，哎，难以言表。

我每天都想着什么时候能有时间重构一下呢，重新建构出来它存在的意义。

也许是时候了，待我从fp那边取完经就去重构！

这里我倒是另外关心的话题了：PL 。本来我是纯吃瓜避免卷入的，但是……

总的来说，蓝星人的 PL 的水平是非常差的，差到只有个别的个体值得单独评价其历史影响，而群体上连回顾历史加以鉴赏的能力都几乎没有。以至于就算你能接触到真正的当代职业选手，也未必能有多少参考意义——连能找准自己的位置都难以做到——因为你接触到的当代一线从业者的水平大多太逊了。

这里本想即兴点名黑一个 MS Research 的自以为发现新 paradigm 的语言，却发现甚至没存在感到让我记住叫啥。算了，那就黑 Luca Cadelli和 Gabriel Dos Reis吧，这俩除了都算是 MS 赞助的，共同点是都更有名且有多个让我明确不爽的实质性的破坏性影响（链接里给的是代表一作；才不是因为我不确定能熟练拼写姓名为了核实才重新现找的呢，喵）。（免责声明：MS 已经算是各大厂商里 PL 总体水平 T0 的，好到能稳定在 PL 方面总体碾压 MS Research 的只有 INRIA 这样的非商业机构了；非讽刺。）

遗憾的是，凭良心说，（能轻松卷进去大厂的）普通人就算是正经科班训练个十坤年，光是接触到的材料作为经验，也是喂不到触碰到上面这些人的水平的。并不是有多少编程经验，见得多了，就自然会有有效产出；哪怕是上面这些人的这些效果上糟烂，但总算仍然符合学术上创新要求的水货，也极少有人生产得出来。多数人注定是原地踏步，仅仅是用一种低效的方式补课罢了（如果不愿意承认是浪费时间的话）。

所以这里我有一个全局的、总体的观点：PL 不适合没天赋的普通从业者玩，尤其是不适合作为第一爱好。即便是职业从业者，也不要指望这个星球上存在多少人有本事正确评价你的工作成果——至少这几十年内小圈子外的业界平均水平都不配。这类项目，不管是什么水平的，不管用什么许可证，在 pure PL（总结应用 PL 的普遍规律、研究设计新的语言）这个方向上大部分的净效果就是添乱，就算有商业赞助基本都是一样。所以，这类 PL 项目上在技术上受到可靠的恶评，都不能说明多少实质问题，因为能面向一般公众（GitHub 用户平均起来都是外行，这不会误伤），评价到点上能分清主次的绝对概率就太小。这也是作为专业人士，我到现在都不太愿意评价（关于语言设计上的）具体技术问题（即便平均每几句话都是槽点）的原因。（所谓专业人士的定义：指有作为负责人的相关全职工作经历。以我的专业观点，这在技术上倒不算什么——充其量就是影响上有资格被我点名鄙视罢了。反正这里我也没见到；母语是中文的这些人士，基本上会进我这的值得注意的实体清单。）

所以，对高中生：要么你矿里有家，否则老实卷你的应试（再考虑改变它，如果还有余力），那是简单路线；别在娱乐目的以外耍小聪明（娱乐还上头吵起来那就太下头了）。不信邪觉得有天赋和热情可以克服困难的我不拦着，但请先做好准备能顺利接受统计规律的制裁。

这样看，是不是觉得对待（技术上虽然经得起推敲但整体无足轻重的）批评能好受一点了？不巧，接下来才是真能引起决定性玉玉的……区区社区人际关系和公关问题比起技术壁垒算个什么毛线啊……你们差不多永远可以别人一开源就自主研发地遥遥领先，我呢？

——远远更倒霉：明明能说是穿越党的素质（顺带理解这里被我鄙视的玩意儿满打满算就花了一坤年，这还是把 WG21 papers 大致上都过了一遍的情况下），正常来说应该帮助古代人提升姿势水平是吧，结果他喵的遇到的几乎全是还在学说人话的猴子……（说实话，我是宁可早穿越 100 年跟 David Hilbert 或 Alonzo Church 谈笑风生的，至少真正有意义的工作不容易那么淹没在杂活中，顺带可能提早 debug 一些东西而改变历史的行程。）另一方面，这也导致我进一步提升自身的姿势水平尤其困难，就算累积的姿势水平差距能让我对技术水平可以毫无焦虑，但投入产出比例的不协调也是难以容忍的。这种玉玉你们能懂嘛，们能懂嘛，能懂嘛，懂嘛，嘛……喵？！

（所以这里也能看到早起步几年懂 PL 在这些困难领域上真没什么值得一提的资本。就像卷算法竞赛的多了，真能在算法研究上有一席之地的有存在感的，自信一定对得起高强度投入而无愧在科研角度上几乎算是一事无成的尴尬局面的，能有几个？）

如果觉得上面说的太天龙人、脱离平均水准（比如能靠专业技打工养活自己就算成功的观念）而难以理解，再提点别的、即便是外行应该也相对容易认知的：

• 不仅是 PL ，整个 CS 的专业教学质量都低得离谱。
  • 比如说，1 字节未必等于 8 位这种体系结构常识（会被认为是 8 位属于历史巧合，从未被普遍地正式定义），大部分 CS 科班出身的在组成原理课及格之后居然毫无印象，甚至都不知道 C 语言都支持 CHAR_BIT >= 8（嗯…… Java 确实不支持）。
  • 这种本该是第一节通识课而之后难以救药的内容很多，PL 更加重灾区，临时就能想到几个但懒得组织语言了，就复读一些以前的材料。
    • 严格地，专业 PL 的虽然误入歧途却也难以否认他们的确知道得更多一点——比如关于类型的本体论认识，好歹应该是能区分出所谓类型不止是数据类型的（虽然我觉得知道 void 是什么的应该都不至于没点 13 数但好像没接触 PLT 的多数都是分不清这个的鸟样）。然而这种半吊子认知实际上反而可能更加给整个学术界+工业界添乱，比如“类型越多越好”）。
    • 但以我的立场又没余裕去打击他们的自尊心（“知识越多越反动”），但又不能全然无视，就陷入了两难……于是最多引用科普内容避免在非历史问题上引用非权威 paper 。
• 技术上到处是外行，非技术上评价不靠谱也是普遍存在的。（以下很多都能给出 GitHub 内链查证，不过我懒……）
  • 像 yinwang0 这种程度，居然还能某月饼厂定级 P9 ？这真是榨干网红的剩余价值了。
    • 当年我给他的 ydiff 提 issue 指出他连一些语法都没弄对时他灰头土脸地关了 issue 的态度……这点基本的求是都做不到，就算他惯于自己打脸修正错误，生涯上限估计就这样了。
    • 后来果然他也理解不了 Rust 的 lifetime（虽然 Java 背景可能都吃亏罢，如果 C++ 用得不那么失败的话，都知道 unique 相比 shared ownership 到底作为静态性质有多大差距），不过连 const propagation 都评论不到点上，让我对他的自以为傲的 insights 更多了一些怀疑。
  • 轻视 spec 的惯例是业界通病；这种能应付 PL analysis 方面的工作，但做好 pure PL 是远远不够的。这更存在于成熟的工业项目中——Rust 和 TypeScript ，这俩货带头瞎搞（恰巧还又是 MS endorse 的，可见多外行了）。

实际上，绝对意义上，你绝少能看到真正尊重技术的氛围，以至于这些最基本的事实判断都没拎清楚的问题都能被普遍地无视。注意外行（以及不够内行的）指导内行本就是对从业者很大的不尊重了。如果爱好者也不能对此有所自觉，那么状况就更加恶劣。

不过再多榨干一下 yinwang0 的剩余价值吧：虽说他早就是魔怔人（比如反相对论的水平和我初中混相对论吧看到的差不多——记得那时候民科吧还是抛荒状态），仍然不得不承认至少 PL 还能算有些专业认知，曾经的一些观点仍然已经比绝大多数自称 PL 爱好者合格多了。

特别地，他曾鄙视过所谓“脚本语言”是伪概念。这对了解 PL 基本历史的，实在是很正常不过的结论，就像“数据类型”就算曾经存在单独设计的合理性，很大程度相比“类型”不值得一提一样。所以这里我就对 @Glomzzz 你燕国匕首了：明明 JSR223 说的只是 scripting 也没说背后的语言一定需要被归类，为什么你的 Asahi 还以“脚本语言”这样基本 not a thing 的东西作为定位呢？类似地更常见的扯淡比如 JLS 明明规定 Java 被编译，非得被一些 JVMS 都没概念的外行扯成“解释语言”，其实离谱程度是没差多少的。跟上面不知道 1 字节能有几个位类似，这些都是上面提到的所谓最基本的事实判断都没拎清楚的问题（虽然就字节是什么玩意儿的这个问题，能概括这个事实的依据可能不太正式，比如得参照 byte 的英文维基百科词条这种二手来源），实在很难忍啊。

按你自称，就一坤年不到的入门经历，但仍然会有这些不费几分钟就能修好的基本槽点，要我来看门都没怎么入，还卡在门槛上呢。（看代码不该是反思的重点，真的。）虽说在我看来像 James Gosling 和之类的 JSR 作者这种强行拎不清 variable 和 type variable 的也可以说卡在了门槛上，不过好歹也已经算是成功的工业界毒瘤了……

当然这里的批评算不上多积极，不过确实进度上你比这里的小朋友快一点（不至于文档里每几句话就是个槽点），而且没 yinwang0 那种老油条（偏执）到无可救药，因此可能值得我多几句话。

（还有 parser 这种开始玩儿的，最近才意识到要有 AST ……又一个编译原理受害者？）

要再有建设性点的话……因为很难准确评价你的理论姿势最欠缺的部分，就针对你引用的最后一段话吧：

fp ？如果说的是 functional programming ，还在方法论层次上都批判不了的水平，那还是别对“取经”抱有多大希望。能取回的经验，大致上都是设计完了的限制，而且发挥不出以这些限制作为代价能体现的价值，更无从理解绕过限制的其它手段，还容易被传染很低级的理解偏差和优越感（比如说，所谓 referential transparency 的在定义上就肤浅的自我感觉良好的理解……至于健全的理解……英文维基词条下有 paper 不过懒得贴了，记得我上次引用的时候就是个死链了）。

其实我是一向喜欢更具体的建设性沟通的，不过效果嘛……没办法，谁叫这行的从业者，几乎都是不大会反思历史的厚重的年轻人的水平呢。

以上评论作为新坑，择机收录 pl-docs 。

[Glomzzz]

被长文吓了一跳。

关于 Asahi

Asahi那个项目是2年前的就代码了，我上文也说到了asahi的源码槽点很多，我想重构，最近也正在重构。

两年前的我是个国内高一的学生，每天过着早6晚11的生活，哎，根本没有时间去系统性的学习PL，理解一下。

Asahi那个项目是从Pouvoir中分离出来的，也许Pouvoir中的Asahi版本更新，但Pouvoir那些我已经撂摊子1年多了。

所以 Asahi的代码水平不代表我现在的水平喵。。

关于 "什么是脚本语言"

说实话我没有搞清楚，也许Asahi应该叫dsl才对嘛。。

我最近刚开始拜读你的pl-docs（MikanAffine推荐的），也许我能从中找到我想要的答案

关于我的最近

我这两年一直在开发PL相关的东西，但没开源。

’最近在忙的是一个叫做 Asaka 的 JVM编译器后端。

这个项目说来话长了，我先是实现了一套 kotlin-compiler，但只有函数，没有类成员的支持

在和朋友( MikanAffine )讨论的过程中，我突发奇想，想开发一套UAST，分离编译器的前端和后端，思路大概如下：

• 前端把source解析到一个UAST上
• 后端基于UAST ( 以及后续IR )做优化，然后做各个codegen target的分发

之后发现已经有前辈们做过这件事了，比如 graalVM那边的truffle

我想先根据自己的感觉写出一个能用的成品（例如Asaka），之后再去系统性地学习。

截止到4月前，我都在开发Asaka，已经基本开发完毕，但4月后我开始忙学习，就再没有精力继续写项目了。

最近是学习的事刚结束，我终于有时间和精力继续编写了，哈哈哈。

哦，我现在把Asaka开源一下，但我记得我还没debug完，所以这目前只是个半成品。。。

关于我的未来

我学PL，写PL，不是为了就业，也不是为了赚钱，这是知识我的爱好，满足我的求知欲，我很好奇！

关于你

FrankHB，其实你算作我们年轻PL一代的老前辈了。

我3月多从朋友那了解到你的pl-docs，之后一直想读，可惜被接踵而至的学习事务耽搁了。

不过现在有时间读了。

关于你的建议

我的理论建设

我想加强自身理论知识的建设，也想学习更多知识，你的话戳中了我的内心，戳中了两年前那个好高骛远的我。

其实在这一年多和朋友们交流的过程中，我早已意识到自己的理论知识严重不足，我个人感觉是我根本没有什么理论知识。

比这里的小朋友快一点 / 要我来看门都没怎么入

哎，要我看来：

• 我真不一定有人家快。
• 我都不知道门在哪里。

关于从fp取经

其实我想从fp那里取的经， 我也不好说是什么，我只是从群友那边了解到 fp 这里也许有我想要的东西。

最近刚开始学 Haskell (Real world Haskell) , 抱歉截止目前我刚读到第三章（毕竟才第3天。。）

我觉得等我学完，也许可以得到一份让我满意的答卷吧，关于"我要取什么经"。

顺带一提

我目前没有找到中文互联网上有系统性的PL入门教学。

有多系统？

最起码来说，总结出来PLT中都有哪些领域，领域下都有哪些成果。

有个姓liu的朋友给我稍微罗列了一下，确实又多又杂，有几个领域甚至根本互相不沾边的。

有多入门？

以类型系统这个领域为例

• 从 lambda演算 开始（我目前甚至不确定这是算不算门。）
• 从 什么是类型 开始 （我见到pl-docs里有这部分）

我希望在我学习过程中，可以积累出来一些系统且入门的文档，供后人参考，为提高蓝星人PL素质的下限尽绵薄之力。

从哪里可以看到我的进展？

你可以从我最近的 contribution里看到我最近在忙什么。

我这几天在忙一个叫 Librorum 的项目，是一个静态文档站点生成器(markdown)

目前已经可以投入生产环境使用了。

过几天你就可以访问 glom.skillw.com 来观看我每天的日记和感想了。

哎，感谢FrankHB给我发的长评，好感动哦。。。

可以加一下我qq嘛，88595433，我想和你促膝长谈喵~

[Glomzzz]

开源了喵。 https://github.com/Glomzzz/Asaka

Asaka 目前只是一个半成品! 不建议投入生产环境, 甚至不保证可以正常使用!

[jellyterra]

（还有 parser 这种开始玩儿的，最近才意识到要有 AST ……又一个编译原理受害者？）

草，还真是，我就是编译原理受害者，初中想写一个 parser 写不完，结果中端一点没写（

[jellyterra]

@FrankHB 老师您好，读完整条 issue 我感到压力很大以至于失眠了，我想找您倾诉一下；然后可以求教些 PL 的门道和坑，然后就是工业界 PL 的糟粕设计有什么更好或者说专业的方案去替代、方便应用一些检查和优化。 电报同用户名，感激（

[Glomzzz]

哦 找到了门记得告诉我。

我目前是 not even nooooob 的状态。

[FrankHB]

被长文吓了一跳。

关于 Asahi

Asahi那个项目是2年前的就代码了，我上文也说到了asahi的源码槽点很多，我想重构，最近也正在重构。

两年前的我是个国内高一的学生，每天过着早6晚11的生活，哎，根本没有时间去系统性的学习PL，理解一下。

Asahi那个项目是从Pouvoir中分离出来的，也许Pouvoir中的Asahi版本更新，但Pouvoir那些我已经撂摊子1年多了。

所以 Asahi的代码水平不代表我现在的水平喵。。

能一直进步那再好不过。不过，大部分人，包括我在内，都会遇到瓶颈。考虑到我都会遇到这种情况，只能说问题本身难度就在那里了。

关于 "什么是脚本语言"

说实话我没有搞清楚，也许Asahi应该叫dsl才对嘛。。

我最近刚开始拜读你的pl-docs（MikanAffine推荐的），也许我能从中找到我想要的答案

这个问题没被强调过，可能值得单独科普，不过考虑到部分观点早就被提过，所以要点可以这里即答：

• 首先，反对“脚本语言”这个提法，纠正的是一些已经过于流行的系统认知的偏差，而不是否定具体的语言设计的目标和定位。不过，这里可能集中体现作者的局限性而应当被警觉。严肃的作者会避免这种不准确的说法。
• 第二，这个提法的直接的技术错误是把“脚本”的实现形式和语言捆绑在一起。实际上语言规范强行要求这个语言的实例只能被作为脚本实现毫无道理。日常被称为脚本语言的实例，如 shell 、Python 之类，其作为事实标准的实现都区分 REPL 和批处理的脚本模式，甚至 REPL 有时还更有用一些，直接称为脚本语言是基本的事实判断错误。作为正经用户能容忍这种指鹿为马都是很不正常的，更不用说语言设计者自己了。
  • 类似的还有“编译型语言”，虽然这个是可能写在语言规范里的，但跟流行的胡扯往往恰好相反。比如 C/C++ 被讹传为编译型语言，其实压根就不在乎什么编译，也有“解释性”的实现（Cling）；反而 Java 被日常讹传为“解释型语言”，事实 JLS 却是钦定了编译（成配合 JVM 的 bytecode ）。ISO C 和 ISO C++ 里叫 translation unit 的东西，在 JLS 里对应的是 compilation unit 。
  • 这些基本事实都能出现认知错误，只能说压根就没去看，纯纯态度问题。这就很容易判断出哪些用户是人云亦云的半桶水咣当响，即便看上去有本事设计语言的用户，也不例外。
• 第三，这个提法是对历史的无知和不尊重，重复错误的说法是在以讹传讹。
  • 合并指鹿为马，都是黄钟毁弃瓦釜雷鸣，毫无一点专业的态度和自觉。放在学术界横竖是个学术不端，放在工业界就商业互吹没人治了？
• 第四，上面链接里提过，对用户和整个业界也有深远的不良影响。

还是一句话：上梁不正下梁歪。要这么简单的常识性问题都没拎明白，好意思设计语言？鄙视这种层次的东西和鄙视一般民科的立场是差不多的，下游偏听偏信先不管，源头一定要遏制。

即便是非专业人士，不靠这个吃饭，也应该趁早划清界限；否则遇到更含糊微妙的问题，只会显得更加不专业，还要浪费别人资源来纠正免得继续祸害业界。

说成 DSL 一般技术上问题不大，尽管 D 有主观性。这方面反而是另一方面有个普遍的严重问题，太多所谓的通用目的语言，D 的成分都太高了而名不副实。有的是来自于系统偏差，比如 C 被认为是通用目的语言，但实际上本来也就是为了跨体系结构实现 UNIX 的 OS 实现的 DSL 而已，尽管它的特性能偶然涵盖其它领域，但根本上属于超范围挪用，且并不好用；另一方面，则是普遍的无能，导致实际上必须保守，比如 Rust 就因灵活性欠缺（比如不能通过参数化 unsafe 分离 memory safety 和 concurrency safety 单独配置检查）导致应用开发不那么好用而也就好意思自称系统语言，尽管它的很多设计其实是通用的。

关于我的最近

我这两年一直在开发PL相关的东西，但没开源。

’最近在忙的是一个叫做 Asaka 的 JVM编译器后端。

这个项目说来话长了，我先是实现了一套 kotlin-compiler，但只有函数，没有类成员的支持

在和朋友( MikanAffine )讨论的过程中，我突发奇想，想开发一套UAST，分离编译器的前端和后端，思路大概如下：

• 前端把source解析到一个UAST上
• 后端基于UAST ( 以及后续IR )做优化，然后做各个codegen target的分发

之后发现已经有前辈们做过这件事了，比如 graalVM那边的truffle

具体的设计我不是很有兴趣关心，不过这个 idea 倒是我在乎的研究重点了。

Truffle 的那套其实是有资格提出和源码混着用给开发者直接访问通用 IR 的，关键是它契合 Graal 的 partial evaluation 框架（而经典优化编译器的各种 inline expansion + constant fold + ... 优化实际上可以认为是其缩水版），几乎不会有比这更通用的对一般 PL 的优化实现方法了（有也是其它更没被研究过的 metacompilation ）。而这样的 IR 要蕴含源语言的递归语法，基本就得是个 AST（graph reduction 之类属于实现细节，而且至少不太容易跟写成文本形式的源代码直接对应而不好用）。

但 Java 味儿太重的东西往往胆子很小，步子也太小。虽然 JVM 这个 target 比起更一般的物理机有很多槽点（stack based 性能弱鸡啦），不过这里我要说的是源语言不够和 IL 层次上的语义显式共享构造，会大大损失可用性的想象力。

例如，Java 这样的静态语言，对不得不静态的特性，往往需要打补丁的方式处理，这种补丁通过限定静态集合付出运行时开销来缓解设计的局限——最主要的就是“反射”；再通用点的如 CLR 的 dynamic 支持。这些设计的共同点是能动态确定的部分还是受到静态设计的限制，不能任意推迟到用户而非语言设计者自己决策——除非用户自己修改语言规范——这就因为兼容性维护成本等现实问题导致几乎没有可用性了。而 Graal 的那套其实是足以把任何动态语言按需静态化的，根本不用考虑被反射的特性集合具体设计是不是会扯到蛋的问题，源语言在这里的限制是多此一举，阻碍了优化实现的发挥。

匪夷所思的是，Java 其实有局部地尽量动态过——成员方法默认可以被覆盖，反而要用户注解 final 提示语言实现可以优化的点。这其实比 C++ 那种 virtual 的 dispatch table 补丁这种 leady abstraction 原则上更通用。奈何用户习惯导致工程上自觉需要 final 不到位，性能白白挖坑给最终用户之类的负面影响太显著，于是 C# 又改回来了。而对更通用的语言设计，其实完全可以默认 virtual ，在库中再默认 final 然后允许用户卸掉的。为什么不把 virtual 和 final 作为库特性而非得集成进核心？只能说设计者想象力和技术水平太差。其实 class 之类所谓 OO 特性也不需要进核心设计中（否则另一方面 Smalltalk 的灵活性倒是可以提一下），因为理论上就更复杂且没有现实合理的变通来确保这不是多此一举，在最通用的目的上这个就是过度设计，怎么都比在 lambda 演算上直接扩展来得废话多（这就是我上面鄙视 Luca Cardelli 的直接理由之一）。

更一般的情形下，我在乎的非技术效果是确保定义何谓静态的权利能按需收归最终用户而非语言设计者。用户放弃了再反弹还回去是另一回事，但现有的语言就是没做到。这也导致静态语言原则上一定在可用性潜力上弱于动态语言而难以最一般地通用，因为一个一般意义上通用的动态语言加上库设施改造为动态语言，要比给静态语言擦屁股返工出伪劣的不完全的动态特性（比如反射）不论在技术上还是工程上都有显著的优越性。

关于这方面如何普遍地设计，之前链接里有提到 smoothness conjecture ；关键其实是在设计中完全取消了“静态”这个概念；可以注意到这和所有经典的要求静态推理的逻辑系统，包括类型系统的观念都冲突——于是这个意义上可以确定 Curry style semantics 比 Church style semantics 更普遍正确。如果用户需要类型系统，那么应该同样欧库的机制在非确定的 stage 中允许用户自行提供，这样的 stage 实质上添加了何为“静态”的定义。

这些就不用指望通过学习而不是被坑经验来体会了。没嫌弃过起草语言规范的破事多的用户，即便能想象得出这里的过程是最强力的 AGI 都难以解决而长期需要人力，仍然是夏虫不可语冰。绝大多数语言社区的成员仍然因为过于虚心、盲从权威和缺乏想象力等原因惯为牛马——虽然不是那么可替代的高阶牛马的确能带来一些成就感能让他们忍受得下去，但我可不干——有的是更有价值的事要我去做，短期也差不多只有我能做。成为牛马的门槛使这部分人仍然占绝对少数，这是为什么看起来鲜少有人关注这些问题的主要现实原因。

题外话：再往大了说，这种难度的差异是非对称性的一个实例。这种现象在其它设计决策上也比比皆是，例如去掉 GC 比引入 GC 同时维持设计的一致性会难得多、类型擦除比类型推断屁事更多。一个更重要的典型实例是封装允许一种接口对应多种实现这种可能性，在实践中也是极端普遍却鲜少被普遍正确地认知的（常见误区是封装性和访问控制有关，后者其实只是一种实现，其它还有如 JS 的 weak map 等根本不用关心 name resolution 的机制）。这种普遍的形而上的存在性是我坚持 PL（而非体系结构或者形而下的算法模型）作为 CS 在普遍的计算模型以上的最核心具体分支的主要理由之一。巧的是，当代物理学也在乎非对称性（或者说，对称性自发破缺）的人择后果（要是正物质和反物质的存在对称，那世界只有一坨光子了），从这个意义上 CS 不再像是应用数学的延伸（虽然计算模型这部分本就不是，而应当是数学中的数学基础），反而更像是自然科学（即便我不待见这个方向）。直觉上回答为什么存在非对称性（以及费马原理这样的最普遍的规律）同属第一推动力，是超越建立大一统理论的一系列终极问题之一，这已经被不少物理学家认识到（比如杨振宁就是成功混到这口饭吃的杰出代表人物，尽管其实也就是能成功提问，而没谁在回答上有什么实质进展）；遗憾的是，数学和 CS 在这里却比形而下的物理学（形而上学=metaphysics，物理学显然不meta）还落后，让我多少对当代数学家和所谓理论 CS 学家的格局的小器觉得有些不爽了。

我想先根据自己的感觉写出一个能用的成品（例如Asaka），之后再去系统性地学习。

截止到4月前，我都在开发Asaka，已经基本开发完毕，但4月后我开始忙留学事务，就再没有精力继续写项目了。

最近是offer刚下来，我终于有时间和精力继续编写了，哈哈哈。

哦，我现在把Asaka开源一下，但我记得我还没debug完，所以这目前只是个半成品。。。

这可能其实是你现阶段最合适做的，因为说实话，我不觉得 PL 有什么系统性能重复参照的顶层成熟知识体系……很多理解连形式化我都嫌烦，用人话说根本是罄竹难书，到位程度和你被坑了多少正相关，而对想象力不那么天选之人的用户来讲，实际做确实是最有效的积累原始经验而足够入门的办法。（找错门就另一回事了。）

关于我的未来

我学PL，写PL，不是为了就业，也不是为了赚钱，这是知识我的爱好，满足我的求知欲，我很好奇！

我很感谢我父母给我创造的条件，可以让我无忧无虑的探索这个世界，探索PL，不用担心就业问题。

这个是比我舒服多了，虽然我同样没这方面焦虑……

但是我有一点没法绕过去：要是不干出点只有我能做的，四舍五入不就是我比别人被坑得多了那么多了的不愉快体验，都白给了？（特别是给人科普半天鸡同鸭讲，结果只能当猴子的时候。）

年轻人就是好，但如果想要变强，可能迟早都是一条道走到黑，而且光是到我这样的程度，不献祭些什么东西的话都可能是小概率事件了。希望你能保持住好奇心。

关于你

FrankHB，其实你算作我们年轻PL一代的老前辈了。

我3月多从朋友那了解到你的pl-docs，之后一直想读，可惜被接踵而至的留学材料耽搁了。

不过现在有时间读了。

实际上吧，这仓库主要是重复了太多的废话观点的集合，顺便把体例搞得正式一些方便引用，所以对层次的水平不要有奇怪的预期，更别指望有多少系统性。

即便每次我都能毫无压力地长篇大论换法子保持要义不走样（而不是 yinwang0 隔了没几天就自己打脸了），DRY 也是必要的生产力。

关于你的建议

我的理论建设

我想加强自身理论知识的建设，也想学习更多知识，你的话戳中了我的内心，戳中了两年前那个好高骛远的我。

其实在这一年多和朋友们交流的过程中，我早已意识到自己的理论知识严重不足，我个人感觉是我根本没有什么理论知识。

比这里的小朋友快一点 / 要我来看门都没怎么入

哎，要我看来：

• 我真不一定有人家快。
• 我都不知道门在哪里。

大多数人是谁都不比谁更快。

门在哪主要看你的目的。这里绝对低级的民科并不那么常见，所以只是一个细分领域其实不会那么容易被误导。

但是，很多分支，如果没有实际需求，在更大的场景中可能就是缺乏长期意义的。更普遍的现象是局部的进展会被重复偶然地发现，新事物闹个大煋闻，未必就更先进。

举一个纯 PL 具体特性设计的（且有必要众所周知的）例子：因为解决不了 funarg proglem 这个实现问题，ALGOL-like 语言对函数这种构造做了很多限制，全然不管 1930 年代就有的 lambda abstraction 早就统一了基本设计，而 1954 年 SECD machine 的 closure 原则上就扫清了实现的障碍（如果配合 environment 的扩展，后面 OO 那些 class 都是多余的，所谓 class 的 object 一定程度上其实就是“带有符号表注释的”closure object ）——虽然 LC 并没有正经被作为 PL（John MaCarthy 都提过他其实都不太懂 LC ）而扩展 LC 作为 operational semantics 方面的工作直到 1970 年代才开始被开展，使实际的设计更贴近正式的模型，实在太后进了。结果到了 2010 年代前后（如 Java 和 C++ ）都还在搞什么 lambda expression ，后知后觉丢人不丢人？要是一开始就理清楚脉络，就没那么拖沓的事了。

更多炒冷饭，如 actor model 炒 continuations（的一部分）、coroutine（的另一部分）炒continuations（的另一部分）、algebriac effects 炒 delimited continuations ……在把这些不同表述都看过就知道多蛋疼了。

可能容易注意到 continuations 出现了多次（被炒）。这说明它始终欠缺主流用户的充分理解。作为外行对此理解困难就算了，作为 researchers 这么炒冷饭，就说明在系统归并知识结构上，整体做得很不够。

所以在缺乏系统知识体系的现成材料的情况下，我能给的可能鲜少被强调的经验是：注意主线，无论是历史还是具体的知识结构上。

• CS 的核心概念自然是计算。历史上定义计算的主线的标志性事件是 Church-Turing thesis 的确立，因为在这个元命题之前计算的概念是没法严格的，这框定了计算的范围，要再有疑问就是哲学问题。
  • 但还有个隐含的主线：计算涵盖逻辑，而不是反过来——存在偏可计算函数，而不存在有意义的偏证明。这又是一种非对称。
• CS 最重要的研究对象的主线是计算模型，而 PL 面对的模型是其中最直接普遍的一类研究对象，其它如体系结构模型和算法模型通常相对更加形而下，对整个 CS 结构的观念有一定作用。
• (UT)LC 是最重要的计算模型，没有之一，因为它衔接了多个 CS 子领域甚至外部的学科。
  • 其实最早发明 LC 的理由就是逻辑系统，甚至 Church 本人还魔怔了想继续砍成更纯粹的逻辑反而弱化了计算。而削弱的模型其实就是排除了偏可计算函数。
  • LC 引入了 Church-Turing thesis 的一端，事实上最早定义了计算。
  • LC 第一个被普遍研究的项重写系统（这本身作为演绎系统的实例，算是逻辑问题，但能不停机……就涉及完全体的计算了）。
  • 对 PL 来说，LC 是最重要的操作语义模型，因为它事实上定义了高级语言（有变量和函数抽象）。仅仅更简单了一点点的组合子逻辑，就是低级语言了。同时，strict evaluation 等很多 PL 中的共通特性的研究始于对 LC 的操作语义（LC 中很多效果没区别，但引入副作用就有区别了）。
  • 对扩展操作语义模型和直接通过扩展模型严格定义新语言，LC 是无可争议的起点（基本就没找到别的值得一提的相关工作）。
  • 对类型系统研究来说，UTLC 的直接扩展 STLC 是研究类型推理和类型系统设计的起点。Church style vs. Curry style 这样的普遍的元问题也是针对 STLC 。STLC 还是 lambda cube 和很多更复杂系统之间的初始原点。
  • 这是无可争议的主线核心，因为从各个领域来看，到处都会遇到，根本就绕不过去。这方面系统学习，有一本 Henk Barendregt 的通称为 bible 的书，不过过于强调逻辑侧其实并不都需要很深入。但对这些复杂知识网络的非线性章节的写作风格倒是值得留意。
  • 更普遍地，LC 可以替代公理集合论和作为严格的数学基础。它没有集合论需要外挂逻辑语言的缺陷，也没有范畴论过分强调对偶(duality) 而削弱非对称性的缺陷，没有 HoTT 这样强调具体个别数学分支而难以被非职业数学家接受的缺陷，在工程化上，是合并传统数学、CS乃至一部分分析哲学的公共基础的首选。
• 在抽象理论的基础上，我进一步猜想 LC 可能是满足上述许多组预期意义的唯一的解，而没有其它替代的非等价模型存在碰瓷的可能性；并且主线的有限性是能进一步添加条件扩展 LC 而严格定义的。当然以一整个带约束的形式系统作为解的问题远远超出现有蓝星数学水平了，我也不打算填坑……可能得基于这些理论的分析式（而非现在鼓吹的生成式炼丹）AGI 成熟之后才可能解决这些鸡和蛋的问题。

（完全新手要入门语言倒是有另外挖过坑……）

可以看到，门是可以强行定义出来的，但这个门肯定不是你要入的 PL 的门，而是现在几个最顶层学科都有很大优化空间的普遍问题。这也是你容易发现为什么那么稀碎的原因……因为 PL 在根本上确实广到能和这些学科都有一腿……

关于从fp取经

其实我想从fp那里取的经， 我也不好说是什么，我只是从群友那边了解到 fp 这里也许有我想要的东西。

最近刚开始学 Haskell (Real world Haskell) , 抱歉截止目前我刚读到第三章（毕竟才第3天。。）

我觉得等我学完，也许可以得到一份让我满意的答卷吧，关于"我要取什么经"。

Haskell 开开 PFP (purely functional programming) 的眼界可以碰，但不要信 pure 就一定更好的鬼话。

抛开大多数用户对引用透明的理解的肤浅性（简而言之并不一定需要 PFP 才能引用透明）这些具体旮旯，这里更涉及到更深层次的哲学（元数学）问题。PFP 移除了副作用，那么是不是 pure 就更基础，impure 就是扩展？

在我看来不是。因为不可分的同一性（这也就是上面唐突乱入的那部分分析哲学的核心），从实体上砍掉区分同一性其实是不那么难的（具体来说就是 interning ），但加回去就不那么容易了——理论上需要支持任意多种不确定的副作用，在扩展上其实是不可行的。先承认存在一种支持任意副作用的平凡极限作为基线，这才比较正常。注意，这又是一种非对称性。

而 Haskell 这样的 PFP 设计恰恰在原则上不可能解决这个问题。

另一个深层问题是，Haskell 引入 PFP 配合 lazy evaluation 才有用——而鲜少有人意识到这是为了做 equational reasoning ，即便这会使他们在压根没用上的时候也付出代价（比如浪费寄存器）。滥用 laziness 和滥用 AI 指望问题会自然消失在方法论上的谬误是相似的。实际上只有相当相当少数典型问题才方便忽略这种代价而更少有领域适合这么用（比如 nixpkgs 之类），因此 lazily PFP 语言注定只能是具有相当强限制的 DSL 。ML 系这样的 eager PFP 语言在这里问题就不那么显著。

顺带一提，能作为我 CS 精神导师的只有两位：提出 UTLC 的 Alonzo Church ，以及首先在系统化扩展 UTLC（在 lambda abstraction 上直接动刀而不是添加 operator 的小修改）并以此设计通用 PL 的 John Shutt 。后者同时是 adaptive grammar 的主要贡献者以及抽象理论的提出者。

关于后者，我是在我自己闭门造车得差不多的情况下才在 fexpr 的相关文献中看到有类似的东西，而且这是我生涯头一次遇到在我感兴趣到 all-in 的领域总进度比我超前以至于还能得到不少新 idea 的状况。

不过在这里提到，还有一个原因是他有一篇综述论文的第一部分比较适合入门 PL research 的 LC ，还集中引用了很多历史参考文献。虽然大都我都早就知道了，不过里面还是有很多不那么容易自己 get 的问题（比如 context 在一般意义上就是个 formal hole 之类）。可能链接有问题就 wayback time machine 一下吧……

顺带一提

我目前没有找到中文互联网上有系统性的PL入门教学。

不只是中文。你看了上面提到的主线普遍得离谱，就不可能知道存在单一的门（因为跨度太广，这是未决问题——甚至涉及到把整个数学形式化），而只会有碎片化的方向。

当然，或许也就是长期被碎片化的知识坑，所以我才对浪费的资源那么记仇，反而能因为抠门的反应和不需要为了 paper 挖恰好不大不小的 idea ，最终接触到比任何具体有名门师承的科班 PL 同学远远更广的视野（而不是我涉猎范围的具体深度差距，都不够我拿工业语言解决问题的经验爆锤的）。

有多系统？

最起码来说，总结出来PLT中都有哪些领域，领域下都有哪些成果。

有个姓liu的朋友给我稍微罗列了一下，确实又多又杂，有几个领域甚至根本互相不沾边的。

有多入门？

以类型系统这个领域为例

• 从 lambda演算 开始（我目前甚至不确定这是算不算门。）
• 从 什么是类型 开始 （我见到pl-docs里有这部分）

类型的部分，大概 TAPL 吧。不过实际上我基本都只看维基百科里的历史部分直接还原出来的。

真要看完整的历史就很麻烦了，毕竟类型本身是集合论填坑然后又被捡起来的东西。还有 nlab 上的不少比维基百科还要容易看着看着就走神到其它链接上的文章（过于数学警告）。

我希望在我学习过程中，可以积累出来一些系统且入门的文档，供后人参考，为提高蓝星人PL素质的下限尽绵薄之力。

在整个 PL 上系统且入门就别想太多了，因为 PL 整体确实是“反紧凑”的。

如果你能整理出靠谱的笔记那是大功一件。不过蓝星人关于 PL 的素质还有很大一部分是对工业语言的应用 flavor 和 taste 都实在太差，还喜欢迷信权威跟风。这就不好通过文献解决了。

从哪里可以看到我的进展？

你可以从我最近的 contribution里看到我最近在忙什么。

我这几天在忙一个叫 Librorum 的项目，是一个静态文档站点生成器(markdown)

目前已经可以投入生产环境使用了。

过几天你就可以访问 glom.skillw.com 来观看我每天的日记和感想了。

哎，感谢FrankHB给我发的长评，好感动哦。。。

可以加一下我qq嘛，88595433，我想和你促膝长谈喵~

因为是可能复用的公共信息，具体项目的 issue 里提话题要求更合适。

当然，挖坑肯定比填坑效率高，不保证填得完（

@jellyterra 不用担心，目测长期会处于我向业界怒送中指哀其不争的状况，可能少说一代人，你们运气好估计还是有机会打扫战场捡败者爆的金币的……

[Glomzzz]

受宠若惊。

我大概粗读了一下，有点困，但有个点我想先提一下。

另一个深层问题是，Haskell 引入 PFP 配合 lazy evaluation 才有用——而鲜少有人意识到这是为了 做 equational reasoning ，即便这会使他们在压根没用上的时候也付出代价（比如浪费寄存器）。

我居然意识到这一点了，在我刚入门Haskell，知道它的pure function与惰性求值后。

当时我给affine他说了这个想法，甚至准备作为经的一部分。

我想精读一下，但得拖到白天了（我明天还得搬到朋友家附近住段时间，现在得睡了。

---

2024.5.12 1:19

读完了，我有很多想说，但时候不早了，我明天得早起去看房（今天因为大雨没看成

我非常地感动，因为这是第一次有人对我这么有耐心，所以我一定要认真回复你。

这个issue的效果已经远远超出我的预期了，谢谢你，让此issue可以在未来不断地被回溯性建构出它的意义。

[ice1000]

PL 不适合没天赋的普通从业者玩，尤其是不适合作为第一爱好。即便是职业从业者，也不要指望这个星球上存在多少人有本事正确评价你的工作成果——至少这几十年内小圈子外的业界平均水平都不配。这类项目，不管是什么水平的，不管用什么许可证，在 pure PL（总结应用 PL 的普遍规律、研究设计新的语言）这个方向上大部分的净效果就是添乱，就算有商业赞助基本都是一样。所以，这类 PL 项目上在技术上受到可靠的恶评，都不能说明多少实质问题，因为能面向一般公众（GitHub 用户平均起来都是外行，这不会误伤），评价到点上能分清主次的绝对概率就太小。

确实。

[ice1000]

• 更普遍地，LC 可以替代公理集合论和作为严格的数学基础。它没有集合论需要外挂逻辑语言的缺陷，也没有范畴论过分强调对偶(duality) 而削弱非对称性的缺陷，没有 HoTT 这样强调具体个别数学分支而难以被非职业数学家接受的缺陷，在工程化上，是合并传统数学、CS乃至一部分分析哲学的公共基础的首选。

泪目，说的太好了。我想补充两点：

1. HoTT 作为 synthetic homotopy theory 的 DSL 是大家都接受的，只是作为数学基础大家不太接受而已（这个观点我问了很多人了）。
2. 我觉得 LC 上带类型是必须的，因为你需要抽象。

[ice1000]

个人希望帝球能在保持大量输出的同时能多和从业者交流，我也好想和帝球激情对线，但可能太久不用 QQ 了没什么机会跟帝球说上话。

[Glomzzz]

今天一整天都在搬家，很累。

---

关于非良定义词汇的滥用

这几天和朋友们讨论过这个问题，我深深地意识到了自己的错误。

lyzh：

水货的教育系统，搞出来水的概念都搞不清的人 市面上烂大街的三流知识到处流传

诶，水货，我是实实在在的水货。

感谢你们让我再次意识到这点， 在这之前我貌似根本没有彻底认清我说的某些词汇究竟代表什么。

现在我也非常讨厌非良定义的东西被滥用了。

看来我得重新好好地审视一下我自己了。( 我的态度有根本上的问题。 )

我会记住这段话的：

上梁不正下梁歪。要这么简单的常识性问题都没拎明白，好意思设计语言？ 鄙视这种层次的东西和鄙视一般民科的立场是差不多的， 下游偏听偏信先不管，源头一定要遏制。

关于我的学习

关于Asahi

我会改称为dsl的，脚本语言属实欠妥了，我了解到脚本语言这玩意就不是个良定义的东西。

（？）： 从某个角度来说，C++甚至也算脚本语言。

同时要给Asahi加的一些feat我会以issue的形式公开。 例如 PFP + lazy evaluation 是一定会引入的了。

另一条路

我这边有个4人团队（和我年龄相仿），正在画一个VM的饼(从4月开始)，这个饼的定位是比JVM更底层一点或者和JVM一致。目的和我的asaka一样，是为了学习。

有个很年轻的成员LizBing (Lei Zaakjyu) (github.com) 已经自己开始实现了。（用Rust + C）

关于Asaka

哎，不要期待这玩意，这只是我的练手玩具，用来进一步熟悉编译器后端的东西，目前和truffle比不了。

其实我想借项目实践学更多东西

可能要花费很长时间了。

IR

会接触更多层IR，不同的IR。

（当然target如果是JVM bytecode的话属实没这个必要，我是为了学习。）

IR Pass

预计会很复杂，目前Asaka的太乱了要被重构的。

Codegen Target

目前Asaka在计划内的target有JVM bytecode和LLVM。

target预计会再加一个我们的VM bytecode

And more...

• 新坑 - Partial Evaluation教程 (zhihu.com)
• GC
• JIT
• AOP
• ...

如你所说

实际做确实是最有效的积累原始经验而足够入门的办法。

自发秩序与建构秩序

后知后觉丢人不丢人？要是一开始就理清楚脉络，就没那么拖沓的事了。

我是个很喜欢建构秩序的人，我总觉得自发秩序的效率不如建构秩序。

我在各种方面都偏向建构秩序，例如经济上我更喜欢让有形的大手做点宏观调控（ （还有其他方面，但我觉得跑题了且有可能会引起意识形态对立，暂且不提了。）

当然建构秩序很考验建构的人的水平，但像上面那几位找错了门就很难绷了。

所以下面这句话很重要：

注意主线，无论是历史还是具体的知识结构上。

待学习/被坑

这边我删掉了一大段话，我觉得应该等我多了解一些后再去和你讨论。

• 确保定义何谓静态的权利能按需收归最终用户而非语言设计者
• Lambda演算
• Haskell
• and more...

（其实我觉得我应该单独开个项目，一个个提issue。）

抱歉，我的知识储备还不足在这些领域以和你展开酣畅淋漓地讨论。

我会加把劲的。

我每日所见所学所感所悟都会记录在我的博客上，欢迎关注。

[ice1000]

我每日所见所学所感所悟都会记录在我的博客上，欢迎关注。

https://blog.skillw.com/ 403 forbidden

Edit: 发现你的主页还有些别的问题，我写在 https://github.com/Glomzzz/Glomzzz/commit/ce3d0c4e14567704fd2b99b3050bf182e983566c 的评论区了

[Glomzzz]

ok，我最近在迁移服务器，还没整好

[Glomzzz]

抱歉最近生活中出现了点事情，可能得耽搁一段时间。

[FrankHB]

今天一整天都在搬家，很累。

关于非良定义词汇的滥用

这几天和朋友们讨论过这个问题，我深深地意识到了自己的错误。

lyzh：

水货的教育系统，搞出来水的概念都搞不清的人 市面上烂大街的三流知识到处流传

诶，水货，我是实实在在的水货。

考虑到标准化考试教育出来的高分低能者，会自己上 GitHub 说人话的相比起来（按比例算）应该是人上人了，所以大可不必妄自菲薄。

危险的是自满而不自知。这集中表现在具有实在话语权并有实力影响别人的人——比如学术权威和网红（虽然这么并列有些怪但并没错）——有多大水分没被公众认知而造成超额风险。这么一来，主要是得避免德不配位。没有影响力去误导他人，没有掌握大量资源进行滥用和浪费的权力，那么坏事做得再多，破坏也相对有限，即便作恶的性质和程度可以有质的区别，说到底无非也就是小鬼。也因此对开源项目的作者（特别是做了自我宣传的）的要求自然也是要高一些的。

感谢你们让我再次意识到这点， 在这之前我貌似根本没有彻底认清我说的某些词汇究竟代表什么。

现在我也非常讨厌非良定义的东西被滥用了。

看来我得重新好好地审视一下我自己了。( 我的态度有根本上的问题。 )

我会记住这段话的：

上梁不正下梁歪。要这么简单的常识性问题都没拎明白，好意思设计语言？ 鄙视这种层次的东西和鄙视一般民科的立场是差不多的， 下游偏听偏信先不管，源头一定要遏制。

关于我的学习

关于Asahi

我会改称为dsl的，脚本语言属实欠妥了，我了解到脚本语言这玩意就不是个良定义的东西。

（？）： 从某个角度来说，C++甚至也算脚本语言。

技术上是有可以算的情形。也可以看出这样一说这词其实就没多少现实意义了。

同时要给Asahi加的一些feat我会以issue的形式公开。 例如 PFP + lazy evaluation 是一定会引入的了。

另一条路

我这边有个4人团队（和我年龄相仿），正在画一个VM的饼(从4月开始)，这个饼的定位是比JVM更底层一点或者和JVM一致。目的和我的asaka一样，是为了学习。

有个很年轻的成员LizBing (Lei Zaakjyu) (github.com) 已经自己开始实现了。（用Rust + C）

你能找到搭子这相比我就是人生赢家。

关于Asaka

哎，不要期待这玩意，这只是我的练手玩具，用来进一步熟悉编译器后端的东西，目前和truffle比不了。

其实我想借项目实践学更多东西

可能要花费很长时间了。

IR

会接触更多层IR，不同的IR。

（当然target如果是JVM bytecode的话属实没这个必要，我是为了学习。）

IR Pass

预计会很复杂，目前Asaka的太乱了要被重构的。

Codegen Target

目前Asaka在计划内的target有JVM bytecode和LLVM。

target预计会再加一个我们的VM bytecode

And more...

• 新坑 - Partial Evaluation教程 (zhihu.com)
• GC
• JIT
• AOP
• ...

兴趣多至少在入门阶段不算坏事，但是作为过来人需要警告一下：你填不完坑。什么都半途而废就没意义了。

不过，半途而废其中一些并不算没有意义，虽然有什么意义非常依赖具体问题。

一个具体的实例：很多年以前我是准备搞类似 nanopass 的东西的，但是后来仔细一想，注意（注意力惊人过程略，这里至少省略了如何注意到 nanopass 自定义语言的先进性以及在这里为何不必要，留作习题）到 pass 这个概念本身说白了也就是 pipe filter 这个 architectural pattern 的一个应用的实现细节，为什么不化整为零呢？因为传统的 pass 的 global 性质其实并没什么技术上的必然性——几乎从不被源语言规范这样的需求明确要求；局部存在的任何类似 callback 或者 handler 这样的 buzzword 的东西都可以实现相近的“干活”的目的。实际上，pass 这个概念虽然一开始是在编译器这个领域的实现套路上简化问题（因为 pipe stage 单独抽象至少相对 resolve 掉所有依赖得到一个复杂的图结构是简单多了的），但之后存在的必要主要体现在减少大型项目的模块化设计复杂性和沟通成本（4 个人不太容易体现；GCC 那种几百个 pass 如果不分组而是泛化成一般的图，怕是几百号人瞬间就 hold 不住而都得卷铺盖）。考虑最优的原型设计和有生存能力的工程项目这两个角度其实是冲突的，而且光是折中就很吃工程经验，所以这里的决策难做却不太涨经验。因为我不指望别人来干活，所以后来干脆就取消 global passes 了，也没碍着我什么。如果不是削尖脑袋到现有编译器项目中打工（我不缺这种履历），这个思考的过程，可能比实际参与编译器项目的收益更大。（要能有资格决定现有架构横竖都得是个 principal architect 往上，四舍五入就是自己搞个 LLVM 类似物……）

另一个具体的实例：不是作为接口公开的 IR 很大程度没有必要。反过来，成功的 IR 多数都有刚需，比如 LLVM IR 是连接前后端的 lingua franca ，考虑到前后端都理解的人力太难找，引入 IR 公开作为中间层的核心在工程上非常有效且近乎必要。另一方面，公开 IR 又会阻碍演进，JS 运行时的 IR 很多都不怎么公开所以方便做 tradeoff 调整不同 layer/profile 的 JIT compiler 。可以看出如何引入 IR 这个问题的水非常深，也同样取决于你打算多少人陪你一起挖坑。（具体思路和过程可以当作作业自习。）

但与上面不同的是，“尽量避免引入 IR ”这个决策远不只是工程上具有重要性：考虑到的极端情况——那就是纯粹 PL 理论上困难而未决的有趣情况了（源语言设计的光滑性，又导向到了我的研究兴趣）。可见，失之东隅，收之桑榆。

如你所说

实际做确实是最有效的积累原始经验而足够入门的办法。

自发秩序与建构秩序

后知后觉丢人不丢人？要是一开始就理清楚脉络，就没那么拖沓的事了。

我是个很喜欢建构秩序的人，我总觉得自发秩序的效率不如建构秩序。

我在各种方面都偏向建构秩序，例如经济上我更喜欢让有形的大手做点宏观调控（ （还有其他方面，但我觉得跑题了且有可能会引起意识形态对立，暂且不提了。）

当然建构秩序很考验建构的人的水平，但像上面那几位找错了门就很难绷了。

所以下面这句话很重要：

注意主线，无论是历史还是具体的知识结构上。

这就涉及意识形态的屁股问题了，不宜深入。

不过挖掉屁股，可以换个更有建设性的说法：设计 vs. 演化。

我更偏向于人为设计，因为自然演化很难符合有明确目的性的需要。这个语境下倒是比较接近你说的建构秩序。

重点是，PL 这个领域本来就是人为设计占主导和核心地位的，有些问题的答案就是“不为什么，一开始就是这么设计的”。所以不少时候并不能流于信仰遵从本能了。如果不认同这点，克服思维惯性需要有额外的代价。所以恭喜你，最基本的天赋是正的……

（数学很大程度也是设计，理论物理大多也是而且越玄学的设计成分越大，但实验科学不是。）

顺便，从这里的立场可以导出很多其它的很自然的偏好，比如我不喜欢 NLP 因为对象就是充满随机演化不断需要没完没了地逆向（瞎）设计（蒙）的，我也不认为现在堆算力的黑箱大模型能狗屎运地自然接近 AGI ，等等。

[Glomzzz]

刚从同济大学出来，在回家的路上看到你又发了长文。

---

中午和 mhyyyy 吃了顿饭，聊了聊家庭和我的人生规划

下午和同济的朋友共度了段美好的时光

这两天主要在忙这些，回到家后明天我会先把网站部署好。

---

应试教育

应试教育的弊端是这样的，高分低能者

无论是高考还是高考后的卷绩点。

兴趣颇多与半途而废

兴趣多对现在的我来说是很好的事， 我觉得半途而废里的途是由我这个主体定义的

打个比方我的目标是开发出来一个很简单的pl应用场景，例如给Asahi那个dsl加上purely function与lazy eval（不止加，我得把整个项目都重构一下，现在的样子太难看了）

当然我的目标实际上是更远一些的，例如Asaka真正实现完并在某游戏开发领域落地，vm基本实现并衍生出配套vm实践课程等

建构秩序与自发秩序

看来我分析得很对，你确实很喜欢建构秩序。

其他

对于德不配位的看法与堆算力的黑箱堆不出良好的agi，我的观点与你一致

[Glomzzz]

写了一天文章，忘部署了，可以先去我仓库看。

https://github.com/Glomzzz/Logosnous

不过目前只有一些日记什么的，PL内容几乎没有。

我昨天从朋友那得知了一个23年暑期课，讲类型系统的，还是从lambda演算开始讲的，我很喜欢，准备从这里开始。

[Glomzzz]

已经部署好了，https://glom.skillw.com/

但目前刚换了DNS，所以可能得等24小时左右才能用

好奇的话，可以先试试这个。。 http://43.128.71.32:19197/

---

靠，我被某个 nginx + luajit 的东西坑了。

现在在维护中。。

前几天朋友刚和我吐槽完lua，没想到这么快就掉进去了。

[Glomzzz]

经过一个小时的维护，已经全部整好了。

欢迎：https://glom.skillw.com/

腾讯云真的草台班子啊。。。。