uvm

o say, "Don't put lies in your database." The "data oracle" (which again is more-or-less just a git repo) provides bytes given a three-tuple of (hash, offset, length). These are immutable, so you can cache the results of (pure) computations over them (e.g. a predicate like "is valid UTF-8" is true/false for all time, yeah?) This replaces the filesystem. I was working with Prof. Wirth's Oberon RISC CPU as a basis, but a couple of days ago a fantastic new 64-bit vm went by here on HN and I'm going to use that going forward. https://github.com/maximecb/uvm https://news.ycombinator.com/item?id=34936729

you could have obviously gone with some more traditional and familiar choices but you went with something more esoteric that doesn't have any clear value added. IMO it's a bit like when it comes to terminology. If there's a commonly accepted way to refer to something, use it. Don't make up your own nomenclature, you'll just create extra confusion for no reason.

ities and performance of your machine. Another difference is that IMO, UVM is more approachable. UXN's assembly language is fairly esoteric IMO. It doesn't look like any other assembly language I've ever seen. That doesn't make it bad, but it does potentially make it harder to learn and harder to leverage an existing base of programming skills. UVM's assembly is designed to not be surprising if you've ever programmed in assembly and know the basic ideas about how a stack machine works. I also have a WIP C compiler that's already usable to write simple programs. See my little snake game for a fun toy example: https://github.com/maximecb/uvm/blob/main/ncc/examples/snake... Assembly syntax example: https://github.com/maximecb/uvm/blob/main/vm/examples/factor... I'll point to the fact that there is almost no boilerplate necessary to start drawing some pixels on a 2D canvas, which IMO makes it a fun platform to develop for. Like I said, it's immature, but I'll iron out all the bugs I can find and keep making it better.