It seems a bit off target, though. It's not entirely wrong; it's true, for example, that Uxn doesn't lend itself to writing an efficient implementation easily. It's also true that the existing implementations are all on hardware that still requires a substantial amount of power, 2000 milliwatts or more, as well as being fairly inefficient in absolute terms.
On the other hand, on my laptop, the Left text editor running in Uxn (with SDL!) still uses less energy than Emacs does, despite the interpretation overhead. And you can run it on a GameBoy Advance, so it's definitely a step in the right direction if you're looking for a frugal write-once/run-anywhere platform. It's the first attempt at the problem that's good enough to criticize, and it's something you can download applications for today.
It's easy to see ways to improve it, but to my knowledge the critiquing savage in question has not written a better system yet, although their critique is indeed informative.
To be clear, I don't have any interest in shitting on a hobby of any sort, be it low-energy computing or whatever. I do lots of stuff that's completely for the joy of it, and has no logical benefits.
It can probably run emacs, too. At least, I have, in my life run emacs on a computer less powerful than that ESP32. And, we should acknowledge emacs is not a hard target to beat :)
The main point, that tens to hundreds of thousands of man years going into optimizing compilers, combined with maybe millions of man years of silicon design and production beats a hobbyist for efficiency, I'd say he demonstrates right in the essay by handwriting assembly for uxn and comparing it with sane-to-simple C code and showing it's 100s of times faster in C than uxn.
I also take a little of his snide asides for those who know to heart; as he alludes, calling it a forth-like without the ability to compile immediate words is giving up a lot; forth is like bare metal programmability of the compiler.
Anyway, I do a lot of coding in go and (sadly) javascript, and not much in Forth, even though I like to hold the idea of the simple days of yore in my mind; we've each got our own thing. But I think he's probably right that this will always be a boutique thing which is mostly for aesthetics.
Having written a sort of Forth compiler without immediate myself, I agree that uxntal is not very Forthlike. I like Golang, JS, and Forth.
Your link is broken, but https://hackaday.com/2021/07/21/its-linux-but-on-an-esp32/ documents someone getting Linux running on an ESP32-S3 under a software emulation of RISC-V with an MMU. That's not obviously more efficient than a simple Uxn emulator and seems likely to be worse. People have also gotten ucLinux running directly on ESP32-S3 with uclibc, which seems unlikely to be able to run Emacs or GCC, though not, as you say, because the CPU is too slow or the RAM is too small. I'm not sure I've run Emacs on a machine with less than 16MiB of RAM but I'm sure it's possible.
1500 milliwatts is still several orders of magnitude more power than I think a personal computer needs, and 16MiB is obviously a couple of orders of magnitude more RAM.
Emacs is actually surprisingly efficient. We remember it as being slow and bulky in part because 30 years ago it was among the bigger resource draws on the machines we used at the time and in part because it actually was slower then. Current Emacs compiles elisp to machine code.
It turns out that it's actually pretty common for a hobbyist to be able to beat tens to hundreds of thousands of man years going into optimizing compilers, as you know if you follow the demoscene at all. Proebsting's Law explains why. The silicon design and production are equally at the disposal of GCC and the hobbyist. But the current applications codebase can easily consume all that surplus computational power.
I agree that if you were to rewrite your applications in sane-to-simple C code, compiled with a good compiler, it would come out faster than Uxn, though only by about 10×. But nobody has done it. Vaporware always beats shipped code because vaporware doesn't have bugs or scope/schedule tradeoffs.
I think it's possible to do much better than Uxn. But I also am not convinced that anybody has.
> 1500 milliwatts is still several orders of magnitude more power than I think a personal computer needs, and 16MiB is obviously a couple of orders of magnitude more RAM.
So, your idea is a computer with less than 200 kiB of RAM? So, devices like a PC AT 286 or Amiga A2000, with their whole 1 MiB RAM, are hopelessly overpowered, and the right kind of a machine is something like a Sinclair Spectrum?
Fair! These guys run Quake on an Arduino Nano [1], with only 274 kiB of RAM. But they have to jump through a lot of hoops.
Running e.g. Emacs the same way is likely unrealistic, and I find Emacs a great example of software that the user can actually inspect and personalize. I would like most user-facing software tools be like that. (In an ideal world I'd love my personal machine to have a terabyte of Optane memory, but currently such hardware is but a fantasy.)
>the Left text editor running in Uxn (with SDL!) still uses less energy than Emacs does, despite the interpretation overhead
This would work better if your example text editor wasn't an operating system. Does it use less energy than vi?
I'm no expert in Emacs stuff, but AIUI the main selling point is Emacs Lisp's decades of packages, which is both amazingly valuable and also a huge blocker on optimisation, because nobody is willing to break compatibility with all the old packages in the name of performance.
emacs is a really bad comparison, given that it has million of functions and is infinitely customizable. It's slow performance has been subject of many jokes back in the 1970's [0] ("EMACS: Eight Megabytes And Constantly Swapping")
You should at least compare it to "nano" editor, or even better, it's predecessor "pico".
On the other hand, on my laptop, the Left text editor running in Uxn (with SDL!) still uses less energy than Emacs does, despite the interpretation overhead. And you can run it on a GameBoy Advance, so it's definitely a step in the right direction if you're looking for a frugal write-once/run-anywhere platform. It's the first attempt at the problem that's good enough to criticize, and it's something you can download applications for today.
It's easy to see ways to improve it, but to my knowledge the critiquing savage in question has not written a better system yet, although their critique is indeed informative.