编程与软件工程petevilter.me
用 Datalog 把 IDE 翻个底朝天
Turning the IDE Inside Out with Datalog
2020 — 2022，它一次次回到首页
黑点是上首页（≥ 50 分）的那次投稿，空心点是没冲上去的投稿，点越大分数越高。
导读
这篇文章介绍一种把 IDE 架构「翻过来」的思路：把代码、类型信息等表示成 Datalog 数据库中的事实与规则，让类型检查、跳转、补全等 IDE 功能都变成对该数据库的查询，而不是用命令式代码各写一套。作者以自己实现的原型为例，展示用逻辑查询驱动类型检查的可行性与好处。
为什么经久不衰：它把一个经典而有生命力的想法（编译器/代码库即数据库）讲得具体可操作，如今 Rust 的 Chalk、Polonius 和 Meta 的 Glean 都在生产或半生产环境中验证了这条路线。
HN 评论精选
Datalog 的语法相等统一太弱，且远离源码会让报错质量下降。
Niko Matsakis 在一篇类似文章（也就是本文引用的那篇）里有一个很有洞见的观察：传统 Datalog/Prolog 通过语法相等来统一（unification），这种方式对于表达 Rust 等语言所需的相等关系来说过于简单。你当然可以在 Datalog 里表达，但越偏离源码，错误信息的生成质量就越差。
sriram_malhar查看英文原文
Niko Matsakis had an insightful observation about this approach in a similar post (which is referenced by OP): http://smallcultfollowing.com/babysteps/blog/2017/01/26/lowering-rust-traits-to-logic/ The key observation to me was that the traditional Datalog/Prolog way of unifying is through syntactic equality, which is a bit too simple to express the kind of equality needed in Rust and elsewhere. You can express it in Datalog, but as it gets farther away from the source, error-generation suffers.
Rust 已用 Prolog 版 Chalk 和 differential-datalog 的 Polonius 实践此思路。
在 Rust 生态里，下一代 IDE 支持已经开始吸收类似思路，不过用的是 Prolog 而非 Datalog（我也很想了解两者差异）。这个逻辑库叫 Chalk，为 Rust 设计成完整的 trait 求解引擎（trait 求解是类型上方法补全等功能的必要步骤）；rust-analyzer 已经用了很久，也在逐步并入 rustc 本身。当然，还不至于把整个 IDE 建立在查询之上。Rust 项目还用本文提到的 differential-datalog 库来支撑第三代借用检查器 Polonius。
kibwen查看英文原文
In the Rust ecosystem, I believe the next-generation IDE support is already beginning to incorporate some ideas like this, although I believe it uses Prolog rather than Datalog (I'd be interested to learn more about how they differ). The logic library is called Chalk ( https://github.com/rust-lang/chalk ), and it's designed to be a full trait resolution engine for Rust (trait resolution being a necessary step to e.g. autocomplete methods on types); rust-analyzer has been using it for quite a while now, and it's slowly being incorporated into rustc itself. Not as impressive as basing the entire IDE on queries, of course! The Rust project is also using the differential-datalog library mentioned in the OP to underlie their third-generation borrow checker: https://github.com/rust-lang/polonius
真实大型代码库中，IDE 增量性受构建系统制约，很难做到理想。
IDE 增量化的最大挑战（我说的甚至不是增量解析）在于你要受制于某门语言的构建系统，以及它在数百万行代码库上的行为。靠大量人力硬啃可以逼近不错的增量效果，但绝非易事。Visual Studio IDE 历史上有过许多次「IDE 增量性」的尝试，大多失败了；成功留下的那个（我参与过一阵）在用户体验上仍有怪问题——用户明明「知道自己想要什么」，却仍被「还在初始化」打扰，补全列表里也未必有想要的东西。这总比旧行为好（旧版要先加载所有上下文才放开 UI，有些用户要等十多分钟的开屏）。但这套系统本质上是有缺陷的。
phillipcarter查看英文原文
The biggest challenge with incrementality in the IDE (I'm not even talking about incremental parsing or whatever) is you're subject to the whims of a given language's build system and how it behaves on multi-million LoC codebases. With sufficient human suffering thrown at the problem, you can approximate decent incrementality, but it ain't easy. It's not written about anywhere, but there is a long and storied history of trying different takes on "IDE Incrementality" for the Visual Studio IDE, all in service of making it a more palatable experience for people working in utterly massive codebases. Most failed, and the one that stuck (which I worked on for a bit, yay!) still has some weird issues with the experience where an end-user "knows what they want" and get bothered by the fact that stuff is still getting initialized, and they may or may not get what they want in a completion list. It's better than the legacy behavior, where the IDE loads context for all things up front before freeing up the UI (which would mean 10+ minute IDE loading screens for some users). But it's an inherently flawed system.
Meta 的 Glean 就是这条路线的大规模生产级实现。
Meta 在生产环境中使用了非常类似的东西，开源在 https://glean.software/ 。
phyrex查看英文原文
Meta uses something very much like this in production. It’s open sourced at https://glean.software/
历次讨论
同类还值得读
开源应用架构
The Architecture of Open Source Applications
《开源软件架构》（AOSA）是一本在线免费书，邀请知名开源项目的作者亲自剖析其内部设计，涵盖 SQLAlchemy、LLVM、Audacity、Apache、Bash 等系统。
编程与软件工程上首页 9 次 · 2011–2024aosabook.org编辑精选编程语言简史：简短、不完整且多半错误
A Brief, Incomplete, and Mostly Wrong History of Programming Languages
一篇以戏谑、故意不准确的方式回顾编程语言史的博客文章，用夸张轶事和讽刺定义串起 Lisp、C、C++、Java、JavaScript、PHP 等语言。
编程与软件工程上首页 8 次 · 2009–2021james-iry.blogspot.comSQLite 是如何测试的
How SQLite is tested
SQLite 官方文档页，系统介绍 SQLite 的测试体系：多种测试方法（TCL 测试、模糊测试、回归测试、静态分析等）和海量测试用例，展示了这个小型开源项目如何靠极致测试获得…
编程与软件工程上首页 8 次 · 2009–2025sqlite.org编辑精选高级编程语言（2009）
Advanced programming languages (2009)
Matt Might 的经典文章，按用途推荐“高级编程语言”：如果追求就业就选主流语言，如果追求表达力、学术研究或创业，则推荐 Haskell、OCaml、Scala 等函数式语…
编程与软件工程上首页 8 次 · 2009–2022matt.might.net我的 Forth 与栈机器经历
Yosefk - My history with Forth & stack machines
作者以亲身经历回顾了使用 Forth 语言和栈式机器的历程：既赞叹其简洁优雅、代码量小、可自举的优点，也坦率指出栈操作在实际编程中的痛苦，以及 Forth 社区文化中的问题。
编程与软件工程上首页 8 次 · 2010–2024yosefk.com编辑精选