20 random bookmarks

2025-06-26

124.

The plan-execute pattern

mmapped.blog/posts/29-plan-execute.html

I feel uneasy about design patterns.
On the one hand, my university class on design patterns revived my interest in programming.
On the other hand, I find most patterns in the Gang of Four book to be irrelevant to my daily work;
they solve problems that a choice of programming language or paradigm creates.

My litmus test of a good design pattern is its cross-disciplinary applicability.
I’m more likely to accept an idea that pops up in fields beyond software engineering.
And the most convincing patterns are the ones that help me in everyday life.

This article describes a universal pattern that billions of people rely on daily, but software engineers rarely discuss—the plan-execute pattern.

2025-06-17

119.

Debugging tricks for IntelliJ

andreabergia.com/blog/2025/06/debugging-tricks-for-intellij

I have been using IntelliJ Idea at work for a decade or so by now, and it’s been a reliable companion. JetBrains IDEs have a bit of a reputation for being slow, but their feature set is incredible: powerful refactoring tools, a great VCS UI (though I like magit even more!), a huge number of supported frameworks, integration with just about any testing library for any language, code coverage tools, powerful debuggers, etc.

2025-05-28

114.

SAT Live!

localhost:4000

2025-04-29

106.

No-engine gamedev using Odin + Raylib

zylinski.se/posts/no-engine-gamedev-using-odin-and-raylib

Games can be made in many different ways. Many games are made using big, general purpose game engines such as Unity and Godot. I enjoy using the Odin Programming Language combined with Raylib.
Odin is a C-like programming language and Raylib is library for drawing graphics, checking input and playing sounds. So it’s just a program that uses a simple library, no engine!
There are no objectively best ways to create games.

2025-04-04

104.

Pitfalls of Safe Rus

corrode.dev/blog/pitfalls-of-safe-rust

When people say Rust is a “safe language”, they often mean memory safety.
And while memory safety is a great start, it’s far from all it takes to build robust applications.
Memory safety is important but not sufficient for overall r…

2025-01-07

96.

Write your own tiny programming system(s)!

d3s.mff.cuni.cz/teaching/nprg077

2024-09-25

78.

in which interactive development saves the day

technomancy.us/189

2024-09-02

70.

Parsing awk is tricky

www.raygard.net/awkdoc/pages/awk_parsing_is_tricky.html

A somewhat compact implementation of the awk programming language

2024-08-15

67.

Writing a C Compiler

nostarch.com/writing-c-compiler

A fun, hands-on guide to writing your own compiler for a real-world programming language.

2024-07-03

59.

Announcing wcurl: a curl wrapper to download files

samueloph.dev/blog/announcing-wcurl-a-curl-wrapper-to-download-files

2024-06-27

56.

plainweb

www.plainweb.dev

plainweb is a framework using HTMX, SQLite and TypeScript for less complexity and more joy.

2024-06-24

51.

Deriving Dependently-Typed OOP from First Principles -- Extended Version with Additional Appendices

arxiv.org/abs/2403.06707

The expression problem describes how most types can easily be extended with new ways to produce the type or new ways to consume the type, but not both. When abstract syntax trees are defined as an algebraic data type, for example, they can easily be extended with new consumers, such as print or eval, but adding a new constructor requires the modification of all existing pattern matches. The expression problem is one way to elucidate the difference between functional or data-oriented programs (easily extendable by new consumers) and object-oriented programs (easily extendable by new producers). This difference between programs which are extensible by new producers or new consumers also exists for dependently typed programming, but with one core difference: Dependently-typed programming almost exclusively follows the functional programming model and not the object-oriented model, which leaves an interesting space in the programming language landscape unexplored. In this paper, we explore the field of dependently-typed object-oriented programming by deriving it from first principles using the principle of duality. That is, we do not extend an existing object-oriented formalism with dependent types in an ad-hoc fashion, but instead start from a familiar data-oriented language and derive its dual fragment by the systematic use of defunctionalization and refunctionalization. Our central contribution is a dependently typed calculus which contains two dual language fragments. We provide type- and semantics-preserving transformations between these two language fragments: defunctionalization and refunctionalization. We have implemented this language and these transformations and use this implementation to explain the various ways in which constructions in dependently typed programming can be explained as special instances of the phenomenon of duality.

2024-06-17

37.

Sqlc: 2024 check in — brandur.org

brandur.org/fragments/sqlc-2024

2024-06-13

24.

Category Theory in Context

math.jhu.edu/~eriehl/context.pdf
22.

API Tokens: A Tedious Survey

fly.io/blog/api-tokens-a-tedious-survey

Comparison between types of API tokens.

17.

Arena allocator tips and tricks

nullprogram.com/blog/2023/09/27

2024-06-12

13.

My experience crafting an interpreter with Rust

ceronman.com/2021/07/22/my-experience-crafting-an-interpreter-with-rust

Last year I finally decided to learn some Rust. The official book by Steve Klabnik and Carol Nichols is excellent, but even after reading it and working on some small code exercises, I felt that I …

2024-06-11

8.

gamja: Simple IRC web client

sr.ht/~emersion/gamja

2024-06-10

3.

On Dependency Usage in Rust

landaire.net/on-dependency-usage-in-rust

Rust and Node aren't bad for encouraging dependency use -- your favorite language's tools just suck.

2024-06-09

2.

Piku

piku.github.io/index.html

piku, inspired by dokku, allows you do git push deployments to your own servers, no matter how small they are.