larsbrinkhoff

This says PDP-7. https://www.reddit.com/r/westworld/comments/56tkt8/what_prog...

Then maybe also give a nod to the LINC, showing DEC a small 12-bit computer could be made.

BASIC was developed on GE mainframes.

Chaosnet was inspired by the experimental 3 Mbits/s Ethernet in use at Xerox PARC at the time. Experimental Ethernet has a 8-bit node address; Chaosnet has 16 bits, of which 8 is network and another 8 is the node. The Chaosnet data rate is 4 Mbits/s.

On top of the hardware protocol, Chaosnet also defined the higher-level transport and session layer protocol. Applications are addressed by a name string rather than a port number; e.g. "TELNET" instead of 23. This protocol was retained when the NIC hardware was replaced with stock Ethernet.

Chaosnet in active use, mostly on emulators: https://chaosnet.net/

Lispm, PDP-10, PDP-11, VAX.

Yes, and in Ethernet frames as EtherType 0x0804.

"Her barbell is a special women's barbell."

FYI, it was probably just a regular women's weightlifting barbell. They are somewhat lighter, and have a thinner grip. Maybe she's serious about her weightlifting training.

https://en.wikipedia.org/wiki/Olympic_weightlifting#Barbell

By the way, I also coded a QR symbol generator in PDP-10 assembly language.

https://github.com/PDP-10/its/blob/master/src/lars/qrcode.8

I hand drew this on a whiteboard. It was a lot more work than I anticipated.

http://lars.nocrew.org/tmp/qr.png

The LINC minicomputer operating system LAP6 came with a 4x5 font, but it didn't have lower case.

It's built into the Unix terminal driver. Control-U is the default, but it can be changed with e.g. "stty kill". Libraries like readline also support it.

Just type Control-U once.

https://twitter.com/Jonathan_Blow/status/2028903268265672728

Jonathan Blow: "It’s about a compiler written in Python FFS."

https://www.sbcl.org/history.html

https://cmucl.org/doc/cmucl-history.html

https://en.wikipedia.org/wiki/Spice_Lisp

SBCL has been in the works since 1980.

Source: "The Invention of Forth", by Chuck Moore. https://colorforth.github.io/HOPL.html

Emacs is needed because it provides Emacs Lisp.

Forth was invented before Moore worked at NRAO. Granted, it was gradually expanded from a very small interpreter, so it's hard to say exactly when it became "Forth" as we mean it today.

Sorry, I don't know anything about Emacs graphics. Some people confuse me with larsi, but I'm not that guy.

Lisp dialects have diverged quite a bit, and it would be a lot of work to bridge the differences to a degree approaching 100%. 90% is easy, but only works for small trivial programs.

I say this, having written a "95%" Common Lisp for Emacs (still a toy), and successfully ran an old Maclisp compiler and assembler in Common Lisp.

https://github.com/larsbrinkhoff/emacs-cl

https://github.com/PDP-6/ITS-138/blob/master/tools/maclisp.l...

Having read that, I'm even less convinced it's not more than a toy.

I don't see how unexec would help with "decoupling the core from Emacs" since the core is written in Emacs Lisp.

I think misinterpreting the "el" as Spanish is fun. In that vein, your game could be called ElCiudad.

Portability across Lisp dialects is usually not a thing. Even Emacs Lisp and Common Lisp which are arguably pretty close rarely if ever share code.

You could make a frontend for dialect A to run code from dialect B. Those things have been toyed with, but never really took off. E.g. cl in Emacs can not accept real Common Lisp code.

I'm not arguing against the idea, I'm just curious how it would work because I see no realistic way to do it.

How would it be run without Emacs?

You might point out that there are things like elisp.lisp that purports to run Emacs Lisp in Common Lisp, but I'm not sure that's viable for anything but trivial programs. There's also something for Guile, but I remain unconvinced.

I wrote a VT52 hardware simulation: https://github.com/larsbrinkhoff/terminal-simulator

In my mind, taking your toy Forth from implemented in C, assembler, or what have you, to metacompiled is transformative. I struggled at first, making a few abortive attempts. But when I finally did it, it was a revelation.

I emailed this to Lee. I guess it can go here too.

---

I have been fortunate to have worked professionally with Forth recently. It was so fun! But I still struggle to point out exactly why I like Forth, and why and how it's different. Your essay is fresh take, which is good.

To me, maybe the most important lessons are.

1. Eschew complexity (sometimes to a fault), and 2. Improve the code by redefining the problem. Look at things from another angle. (I hate to say it, but think out of the box.)

Much of Forth falls out from these principles. E.g. people are quick to point out Forth is a stack based programming language. Which is true enough, but to me it's kind of beside the point. The point is the language does away with local variables (redefine the problem) to lay the ground for a much simpler implementation (eschew complexity).

Yes, there's REPL. But why? Because Forth is (or can be) a programming language, operating system, compiler, and command line rolled into one. Heaps of layers and components done away with.

File system, virtual system, code structure, documentation? Blocks!

The list goes on. Once you internalize this, the veil falls from your eyes, and you see how much needless complexity stands in your way in most other languages, operating system, tools, apps, ... it's everywhere.

He should have ended this essay mid-sencence, because that would