š¾ Archived View for friends.riverside.camp āŗ ~clarity āŗ wiki āŗ computers.gmi captured on 2024-08-31 at 11:50:51. Gemini links have been rewritten to link to archived content
ā¬ ļø Previous capture (2024-05-10)
-=-=-=-=-=-=-
Probably computers were a mistake. But here we are.
Gemini is a smaller and kinder way of sharing documents over the internet.
Plan 9 is not a product, it is an experimental investigation into a different way of computing. The developers started from several basic assumptions: that CPUs are very cheap but that we don't really know how to combine them effectively; that good networking is very important; that an intelligent user interface is a Right Decision; that existing systems are not the correct way to do things, and in particular that today's workstations are not the way to go.
These lecture notes use Plan 9 from Bell Labs to teach a first (practical!) course on operating systems. The system is easy to use for programmers, and is an excellent example of high-quality system designand software development. Studying its code reveals how simplicity can be more effective than contortions made by other systems.
Using Plan 9 from Bell Labs, by Francisco J Ballesteros
Forth is a procedural, concatenative, stack-oriented programming language and interactive development environment designed by Charles H. "Chuck" Moore and first used by other programmers in 1970.
Forth is my current programming language obsession these days. I'm still new to it but am getting rapidly addicted to the power.
When I write system-level code these days it usually tends to be in Zig. I'm not married to the language but I've gotten comfortable working in it and appreciate the overall laid-back & friendly vibe of the community.
Uxn is a little forth machine with 32 instructions. It was designed with an implementation-first mindset with the goal of targeting salvaged computers, the distribution of Uxn projects is akin to sharing game roms for any classic console emulator.
I was making a little game in Uxn to explore how it feels:
Uiua (wee-wuh) is a general purpose, stack-based, array-oriented programming language with a focus on simplicity, beauty, and tacit code. Uiua lets you write code that is as short as possible while remaining readable, so you can focus on problems rather than ceremony. The language is not yet stable, as its design space is still being explored. However, it is already quite powerful and fun to use!
We present egglog, a fixpoint reasoning system that unifies Datalog and equality saturation (EqSat). Like Datalog, it supports efficient incremental execution, cooperating analyses, and lattice-based reasoning. Like EqSat, it supports term rewriting, efficient congruence closure, and extraction of optimized terms.
We identify two recent applications--a unification-based pointer analysis in Datalog and an EqSat-based floating-point term rewriter--that have been hampered by features missing from Datalog but found in EqSat or vice-versa. We evaluate egglog by reimplementing those projects in egglog. The resulting systems in egglog are faster, simpler, and fix bugs found in the original systems
Better Together: Unifying Datalog and Equality Saturation
Inpla is a multi-threaded parallel interpreter of interaction nets. Once you write programs for sequential execution, it works also in multi-threaded parallel execution. Each thread is managed on each CPU-core with POSIX-thread library.
"Strand" is an open-source implementation of the identically named parallel Prolog dialect as described in the book "Strand: New Concepts for Parallel Programming" by Ian Foster and Stephen Taylor. Strand represents a very elegant and concise notation for expressing concurrent and distributed algorithms using only a small number of fundamental language constructs and a very simple execution model.
[Imp is a] live environment for working with structured data across multiple devices, blurring the lines between database and programming language.
For some time now I've been telling people about a little hack I use for understanding strange codebases. When I am interested in learning about a new codebase, I skim its git log until I find a tantalizing tag or commit message, like say "version 1". Invariably version 1 is far simpler than the current version. The core use cases haven't yet been swamped by an avalanche of features and exceptions. The skeleton of the architecture is more apparent. So I focus on this snapshot, and learn all I can. Once I understand the skeleton I can play changes forward and watch the codebase fill out in a controlled manner.
But relying on the log for this information is not ideal, because the log is immutable. Often a codebase might have had a major reorg around version 3, so that reading version 1 ends up being misleading, doing more harm than good. My new organization lays out this time axis explicitly in a coherent way, and makes it available to change. The sequence of features is available to be cleaned up as the architecture changes and the codebase evolves.
A new way to organize programs
LineDrive was developed by Maneesh Agrawala, Chris Stolte, and Christian Chabot at Stanford University, and they describe their system in a 2001 paper if youāre interested in the details. What is most interesting to me is the creatorsā inspiration for LineDrive: hand-drawn route maps. While most online mapping services were, and still are, patterned after paper road atlases, LineDrive was designed to look like what you might quickly sketch on a napkin.
Names must be human-readable in order to be widely used. Unfortunately, while DIDs and Tor .onion addresses are decentralized and globally unique, they are not human readable. How can we build user interfaces that real users might actually use? In this paper we provide an overview of petname systems, a way of mapping human readable names to cryptographically secure names.
Petnames: A humane approach to secure, decentralized naming
GNU Emacs / N Ī N O is a set of configuration files for GNU Emacs such as to provide a nice and consistent look and feel. It is based on design principles I described in the article "On the design of text Editors" that is available on arXiv.
There is a playful way to study the architecture of computers of the past. Find a piece of software you know well and try to find out how it was ported to these machines you don't.
A good choice would be DOOM. id Software's 1994 mega-hit has been ported to everything. It is designed around a core with no layering violations. It is usually easy to find and read the implementation of its six I/O sub-systems.
An other choice would be Eric Chahi's 1991 critically acclaimed" title "Another World", better known in North America as "Out Of This World" which also happens to be ubiquitous. I would argue it is in fact more interesting to study than DOOM because of its polygon based graphics which are suitable to wild optimizations. In some cases, clever tricks allowed Another World to run on hardware built up to five years prior to the game release.
So you want to write a Lisp interpreter? Welcome!
The goal of the Make-A-Lisp project is to make it easy to write your own Lisp interpreter without sacrificing those many "Aha!" moments that come from ascending the McCarthy mountain. When you reach the peak of this particular mountain, you will have an interpreter for the mal Lisp language that is powerful enough to be self-hosting, meaning it will be able to run a mal interpreter written in mal itself.
The title of the course is āA modular approach to audio programmingā. I know itās silly, but it pretty much describes the goal of each lectureāwe try to understand the complex theory of digital audio as a progression of independent minimal working examples. Instead of building a monolithic application, we write multiple small, standalone programs in C that can possibly interact with each other.
Ī¼, A modular approach to audio programming
Computer people are fine human beings, but they do a lot of harm in the ways they "help" other people with their computer problems. Now that we're trying to get everyone online, I thought it might be helpful to write down everything I've been taught about helping people use computers.
How to help someone use a computer
This is a book on the functional paradigm in general. We'll use the world's most popular functional programming language: JavaScript.
Professor Frisby's Mostly Adequate Guide to Functional Programming
You come upon a function argument at a fork in the road. If it takes the left road, itāll evaluate itself and then be passed to its function. If it takes the right road, itāll pass itself to the function to be evaluated somewhere down the road (š„š). Letās bet on which road will be faster.
[...]
Levyās ā99 paper Call by Push Value: A Subsuming Paradigm introduces a third option, Call-by-Push-Value (CBPV), to the CBV/CBN spectrum. ā99 is basically the Cretaceous era if weāre releasing JavaScript frameworks, but itās quite recent for releasing research. CBPV has just started to penetrate the zeitgeist, and itās by far the most promising approach to calling-by.
Thunderseethe āĀ I'm betting on Call-by-Push-Value
Iād like to design a language, more specifically implement a compiler for a programming language Iāve made up. This is not the first time Iāve wanted to do this. In fact, Iāve had the itch quite a few times before . I canāt tell you why I keep returning to this venture when Iāve failed at it so many times. What I can tell you is why I always fail. Every time I begin a sparkly new project with fresh eyes and quickly whip together a lexer.
[...]
So how do I overcome my parsing problem? Iāll simply not write a lexer or parser. I canāt get stuck writing a parser if I donāt start writing one. I can come back later and add a parser once Iāve designed more of the internals of my language. My hope is having the other steps (Type Checking, Code Generation, etc.) will provide a guiding hand for what my parser should look like when I do eventually write one. The goal of writing a parser is to produce an AST. But we donāt have to parse our AST out of text during prototyping, we can design an AST and then construct it ad hoc where we need it. Then the question is, if weāre not starting with lexing/parsing, then what step do we start with? The answer is type inference [...]
Thunderseethe āĀ Designing a Language without a Parser
This textbook provides a gentle introduction to assembly language programming. What makes this introduction "gentle" is that it assumes the reader is already comfortable with C or C++ coding. We use this assumed knowledge to bridge backward towards the low level ISA (Instruction Set Architecture).
We drive home a very sharp point:
Assembly language is nothing to be scared of!
A Gentle Introduction to Assembly Language Programming
This article is an attempt to describe my experiences with concurrent logic programming languages, a programming paradigm that has been largely forgotten but has a number of interesting properties that make it worthwhile to explore. Especially today, where CPU designers have run out of ideas and have settled on throwing more and more processor cores at us, parallel and concurrent programming remain the areas where performance gains seem still be achievable, yet, our programming models are not at all suited to this - coarse-grained processes with shared state is still the most widely used strategy and parallelizing application remains hard and error prone.
The Joy of Concurrent Logic Programming
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Written January 28, 2021, last changed August 26, 2024