miniblog.

← Back to all posts
Sep 27, 2019 at 15:48
Unison is exploring the idea of storing source code by the hash of its AST, which allows some interesting refactoring and testing designs: https://www.theregister.co.uk/AMP/2019/09/26/unison_programming_language/

Related Posts

Mar 9, 2025 at 23:24
1
https://tigerbeetle.com/blog/2025-02-27-why-we-designed-tigerbeetles-docs-from-scratch/ has an interesting distinction between "physical" and "logical" hash of a tarball. By storing the hash of the decompressed tarball contents (i.e. the logical hash), they can verify the validity of files without needing to keep the tarball around.
Why We Designed TigerBeetle
Why We Designed TigerBeetle
Insights, updates, and technical deep dives on building a high-performance financial transactions database.
May 4, 2023 at 06:52
On storing ASTs in flat arrays for performance, and the relationship with bytecode interpreters:
Flattening ASTs (and Other Compiler Data Structures)
Flattening ASTs (and Other Compiler Data Structures)
This is an introduction to data structure flattening, a special case of arena allocation that is a good fit for programming language implementations. We build a simple interpreter twice, the normal way and the flat way, and show that some fairly mechanical code changes can give you a 2.4× speedup.
Sep 20, 2020 at 01:33
I really like the one-module-per-file model of JavaScript or Python. If you're storing code in files, you might as well leverage file boundaries. If modules are a separate abstraction (e.g Rust, OCaml), it's harder to learn and choose how to organise code.