miniblog.

← Back to all posts
Jan 16, 2023 at 09:54
I feel like in-code docs are an underexplored design space. Do you use comments or string literals? Before the function (e.g. JSDoc) or inside it (e.g. Python)? Which is best? Which is the easiest to write, has the easiest tooling, or the most readable (code/HTML) artifacts?

Related Posts

Mar 29, 2026 at 13:54
1
The author of rust-analyzer discussing how language features help or hinder fast IDEs. If you allow `from m import *` you can't analyse files in isolation, and it's even harder in Rust.
Against Query Based Compilers
Query based compilers are all the rage these days, so it feels only appropriate to chart some treacherous shoals in those waters.
Mar 20, 2026 at 12:02
223
Excellent series on Self, both the programming model and the tool chain. I love how opening an inspector on a value (e.g. nil) then shows a link to all occurrences of the value in other open inspectors!
Environment and the programming language Self (part one; environment)
Environment and the programming language Self (part one; environment)
I bring you a message about a language that has been at the birth of many others, but almost no one knows it. A rumor of a graphical environment offering options like no other, but almost no one using it. I also bring information about a virtual machine supporting reflection almost to infinity, reaching almost half of the operating power of C in numerical calculations in its time, yet today forgotten.
Jan 23, 2026 at 00:09
1
Futhark's design is deliberately trying to stay simple to keep long term design sustainable. The author also has an interesting discussion of relative versus absolute paths in import syntax, and how relative paths can make local analysis easier.
Designing a Programming Language for the Desert
A high-performance and high-level purely functional data-parallel array programming language that can execute on the GPU and CPU.