Today I was in couple good threads on programming/metaprogramming and on the design of universal…

John Ohno on 2018-09-21

Today I was in couple good threads on programming/metaprogramming and on the design of universal undo. I feel blessed by the awesome folks who argue about computers with me on mastodon.

The first thread is longer and has more drift, but it’s worth digging through, because it’s mostly a meditation on what kind of language we might want (what kind of facilities and attributes we might want) for small computing (i.e., for exploration, prototyping, and a composition-friendly general computing environment).

My take on it is that we want: 1) homogeneity — all mechanisms should be in the same language and be equally easy to edit (rather than having distinct domains like compiled c programs vs shell scripts, or having separate privilege levels like kernel vs user space); because this is a small-computing environment, neither security nor performance should take priority over flexibility 2) support for an agglutanative / syntax-lite style — the need to produce boilerplate & declarations, explicit types, and any constraints that require conceptually similar things to be visually very different all get in the way of iteration, while the likes of lisp, forth, rebol, bourne-style shells, APL, and io all present a style more well-suited to long-term iteration on a persistent interactive REPL-like environment 3) both function-like, message-like, and pipe-like code composition — different kinds of data flows and different kind of modularization have different patterns of behavior that are convenient for them 4) backtracking and pattern matching as a built-in facility — constraint programming is rare as a feature in imperative-style languages, but a declarative style is a very powerful tool for rapid iteration, because it means that not-yet-implemented code can literally run so long as the requirements for that code are well-defined

In the second thread, the idea of system- or vm-level backtracking exposed as both a mechanism for capabilities-based security and fast constraint solving in user code is explored. My take is: 1) if we combine copy-on-write with the parallelism supported by the underlying host system, we can get fast and easy constraint solving for the whole system 2) this is completely compatible with global forking undo on the vm level 3) it can be conveniently implemented in terms of a journal and a vm image