[pushfoo]

TL;DR: You may be right about LISP issues, but my intent was show how IO and social factors seem key to platform success

I'll skip discussing Python for the moment because I think there are a lot of things wrong with it. If I try, we'll be here forever, but they mostly come down to not enough consistency and it being pointless to discuss for reasons which will become clear below.

Whatever the nature of the cause/effect of the LISP ecosystem, I see Octo's issues as similar in result:

1. There is no way to load and persist useful data in any popular CHIP-8 variant

2. Once people get a taste, the lack of IO means they do one of two things:

   * leave

   * become emulator or assembly developers

3. They few who stay in Octo or CHIP-8 are interested in writing their own tools, libraries, and ISA variants

Keep in mind, I still see this as success. This is based on my understanding of the Octo author's post saying farewell to running OctoJams[1] and my time as a participant. It got me interested in assembly and has helped many other people learn and begin to use low-level tools.

Compare this to Uxn:

* Although flawed, it has useful IO capabilities

* People have built applications which they use to perform real work every day

* An already-familiar ecosystem of tools exists to cater to the interests of similarly-minded people

> 40 years ago lisp was vastly more capable than the alternatives, along many axes. smalltalk was an exception, but smalltalk wasn't really available to most people. both as a programming language and as a development environment, lisp was like technology from the future, but you could use it in 01984.

Yes, I think that's getting at what I mean. One of the motivating factors for 100r was that Xcode is bad fit for people who live on a boat with solar-powered computers. So are Visual Studio or PyCharm.

Although the Uxn ecoysystem is far from optimal, it's still better than those heavy IDEs. Better yet, it was already mostly here a few years ago. Even to this day, it feels like it's from some point(s) in a better timeline where the world wasn't full of leftpad/polyfill/AI or whatever the next ridiculous crisis will be.

In other words, Uxn is a pidgin[2] of ideas "solarpunk" or even just small, understandable computer types like. At the same time, it does this without too much purism holding it back:

* Simple enough and familiar enough mish-mash of forth and low-color, plane-based display

* Low enough power that its cheaper than Xcode to run without more effort

* Enough IO capabilities to get things done

Since it already had all of this as of a few years ago, it's had time for social effects to take off. For example, you can share a picture, a music track, or text made using Uxn-based software. Those files will still work even if the Uxn spec evolves in backward-incompatible ways again. Its design choices are also inherently good for (or limited to) producing art aligned with the aesthetics of the creators. That seems to be part of a self-reinforcing popularity loop at this point.

Although it's theoretically possible to make similar things using CHIP-8 based tools, nobody bothers. Even if you record the output of music sequencers which have been written for it, you can't really save your work or load in data from elsewhere. In theory, there's the 16 bytes of the persistent state registers in XO-CHIP which could be repurposed from a calculator-like thing into IO, but the fact I'm mentioning it should underline the main issue in that community: purity concerns. Those limit it more than having "real" 16 buttons do. Yes, you could do some interesting multiplexing or even just bit-shift every other button press to make a pretend terminal-like keyboard, but the purity focus inadvertently kills interest more than silly function pointer syntax.

Decker is the complete opposite of Octo in this. It also goes even farther than Uxn in giving up purity concerns. Sure, it's complicated and inefficient, but it is inherently built around sharing widgets with others in a mishmash of HyperCard and Web 1.0 revival spirit:

1. You can make gifs with it, and this is probably its most popular use in the form of Wigglypaint[3]

2. When asked "um, can I borrow source from it?", the answer is "Absolutely!"[4]

This is why as much as certain Python projects frustrate me, I'm not trying to fix their inherent Python-ness right now. I just accept they're what they are. As you pointed out, it's better than the alternatives in many cases. Before you ask, I won't go as far as calling JavaScript is good, but I'll admit it's shareable. :P

[1]: https://en.wikipedia.org/wiki/Pidgin

[2]: https://beyondloom.com/blog/octojam.html

[3]: https://internet-janitor.itch.io/wigglypaint

[4]: https://itch.io/post/10183760

[kragen]

yeah, the chip-8 design is less ambitious than the uxn design and can only really handle very limited programs. on the other hand, it does run on much smaller hardware

i wouldn't go so far as to say uxn is flawed; that suggests it's fundamentally unsound. as far as i know, it isn't; it's a perfectly workable design, and it's better than anything else so far for frugal write-once-run-anywhere. i think a different design would be better in important ways, but vaporware is always better than actually implemented systems

> One of the motivating factors for 100r was that Xcode is bad fit for people who live on a boat with solar-powered computers. So are Visual Studio or PyCharm.

that's true, but you're damning uxn with faint praise here. i suspected that if you benchmarked left¹ (which, incidentally, does do syntax highlighting) against a default configuration of vim or gnu emacs, you'd find that left is the one that consumes the most power

but then i tried it, and also compared an extremely minimal editor called `ae`, and left seems to use a third as much power as emacs, but five times as much as vim and 300 times as much as ae

ae and left could plausibly run on the zorzpad. vim and emacs cannot; they need far too much ram. ae and left also have in common that they both lack undo, but left is dramatically more capable and easier to use

— emacs power usage —

i've been running my current emacs process for a week and (not counting cpu time used by the x server) it's used 34 minutes and 15 seconds of cpu, which is about 0.3% of one core of this amd ryzen 3500u. if we estimate that the cpu draws 29 more watts from the battery when running full-speed than when completely idle, and can run about 3 instructions per clock per core on each of 4 cores and 3.1 gigahertz working out to 36 billion instructions per second, emacs is consuming about 90 milliwatts and running about 100 million instructions per second on average

that's a lot higher than i expected, and possibly actually higher than left (i haven't tested) but it's certainly not in the same league as vscode. (this is emacs 28.2, and somewhat to my surprise, system-configuration-options tells me it's built --with-native-compilation, so perhaps it's not using the inefficient old bytecode interpreter.)

as a more precise test, to test emacs's built-in ide functionality rather than gtk and my proliferation of elisp packages, i ran `valgrind --tool=cachegrind emacs -q -nw --no-site-file` and wrote this c program in it:

    #include <stdio.h>

    int main(int argc, char **argv)
    {
      char buf[256];
      printf("What's your name? ");
      fflush(stdout);
      fgets(buf, sizeof buf, stdin);
      for (char *p = buf; *p; p++) if (*p == '\n') *p = '\0';
      printf("Oh, hi, %s!  Lovely to meet you!\n", buf);
      return 0;
    }

syntax highlighting was enabled, but -nw runs it in the terminal. i compiled it, fixed bugs in it (at first i didn't have any but i wanted to ensure i was doing a fair test), jumped to error message locations, jumped to system header files, looked up manual pages in it, ran a unix shell in it, and ran the program in the unix shell and interacted with it

this took about four minutes and 8.8 billion instructions. (just starting up emacs and shutting it down that way takes 595 million, but i wanted to get an estimate of the steady state.) this is about 30–40 million instructions per second, not counting the instructions of the compiler, shell, terminal emulator, and x-windows server; so 100 million per second with a more elaborate configuration and larger files seems like a plausible estimate

— ae power usage —

i wrote the same program again in anthony howe's 'ant's editor' from 01991⁰, which is about 300 lines of c in its non-obfuscated form, and is roughly the simplest programming editor you can actually use; the user interface is a stripped-down version of vi where you exit insert mode with control-l, write the file with capital w, and exit with capital q. this took about 7 minutes (i kept hitting the wrong keys) and 39 million instructions, of which about 0.8 million were startup and shutdown. that's about 90 thousand instructions per second, or 100 microwatts: a thousand times faster than emacs, and within the capabilities of a commodore 64 or apple ][. of course that again doesn't account for the window system, compiler, and terminal emulator, but it does account for ncurses computing the minimal updates necessary to the screen, so it's most of the work needed to avoid redrawing unchanged areas

38 million instructions divided by 278 bytes of output is about 137000 instructions per byte, but of course moving around in a larger file takes longer

— uxn left power usage —

running uxnemu left.rom in the same way from https://rabbits.srht.site/uxn/uxn-essentials-lin64.tar.gz takes 481 million instructions to start up and shut down. writing the same c in left.rom took about 5 minutes and 3.4 billion instructions; 3 billion instructions over 5 minutes is about 10 million instructions per second. this suggests that it uses about a third as much power as emacs and 110 times as much power as ae

10 million interpreted bytecode instructions per second is really pushing the limits of what the zorzpad can do. also its window is by default 684×374, about 33% bigger than the zorzpad's two screens put together, and it doesn't seem to be resizable (which i assume means it's not designed to be able to handle being resized)

— vim power usage —

finally, i did it again with vim in a terminal emulator, with syntax highlighting and manual page lookup, and vim took 680 million instructions, exactly one fifth of what left took. it took me less time, but i don't think vim does any background computation. as with ae, vim's time includes the time to compute minimal screen updates (confirmed with `asciinema rec vimtest`)

______

⁰ http://canonical.org/~kragen/sw/dev3/ae.c

¹ https://wiki.xxiivv.com/site/left.html

[kragen]

aha, i finally figured out that yes, indeed, my elisp code is being compiled to native code and saved as shared library files in /usr/lib/emacs/28.2/native-lisp/28.2-e4556eb6. the functions have names like F76632d63616c6c2d6261636b656e64_vc_call_backend_0@@Base (the hex string decodes to 'vc-call-backend'), and all the calls are indirected through registers, but `objdump -d` can decode it into recognizable amd64 assembly language, with function prologues and epilogues, nop-padding to 8-byte boundaries, tests followed by conditional jumps, that kind of thing. so emacs doesn't really have an excuse for being so slow

i thought that maybe the earlier version of left in c would be more efficient, so i git cloned https://git.sr.ht/~rabbits/left, checked out 4f127602e4e9c27171ef8f6c11f2bc7698c6157c, and built the last c version of the editor. a simple startup and shutdown cost 407 million instructions, and writing the same c program in it again in more or less the same way took 2½ minutes and 1.8 billion instructions. 1.4 billion instructions in 150 seconds are about 9 million instructions per second, which is surprisingly about the same as the version running in uxn. but just leaving it open for 2¼ minutes also used only 424 million instructions, so maybe it makes more sense to compare the 1.4 billion against the 8.8 billion of emacs, the 0.039 billion of ae, the 3.4 billion of uxn left, and the 0.68 billion of vim, since it seems to grow primarily with activity rather than just time open