larsbrinkhoff

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

Because Zork was written on the MIT Dynamic Modeling PDP-10. MDL was an important part of the software ecosystem on that computer, but Lisp wasn't. On the other MIT PDP-10 computers, Maclisp reined.

Approximately, DEC-10 = PDP-10.

What happened to

1. Sun's JavaStation, 2. ARM's Jazelle, ??? 3. Profit!

See also:

Amiga romantics.

8-bit romantics.

PDP-10 romantics.

Let them stay. Let them romantizice. <glasses tint="rose">

Yes, but also. OpenGenera was ported to x86 some time ago.

Check here https://www.tuhs.org/Archive/Distributions/Research/

They were able to get an even earlier set of UNIX sources running on the SIMH PDP-7 emulator. SEVEN.

Better yet, I think, there are files comprising the new editor in it's fledgling infancy from November 1976. Some source code, and binary files that can be run on a PDP-10 emulator.

This was the first EMACS clone, following shortly after the original TECO based editor. It was written for the nascent Lisp machine.

I read a comment on /r/Forth the other day from someone at NASA, implying that Forth was still actively used for something.

I imagine - though I don't know - it might have some similarities with GOAL, see https://en.wikipedia.org/wiki/Game_Oriented_Assembly_Lisp and https://opengoal.dev/docs/intro/

The Motorola 68000 was already available before the Bellmac-32. The 68000 programming model was mostly 32-bit, although internally it was limited to 16 bit data and 24 bit addresses. This was fixed by later models in the family.

> introduced modern demand paged virtual memory

Didn't Multics, Project Genie, and TENEX have demand paging long before the VAX?

In fairness, there's an over abundance of toy Forths. And I say that as a fan and professional Forth programmer.

Some of those other computer resources were at University of Washington.

You're not an idiot. I have transcribed several listings manually. I also tried OCR. In my experience, fixing OCR mistakes take at least as much work as just typing the whole thing.

I recruited a team to transcribe a particularly important document, and I had us type each page to catch typos.

This has now reached the masses with the sale of over 9000... I mean 800 PiDP-10 units. Oscar is kind of pushing ITS as the premier PDP-10 operating system.

FM synthesis was developed by John Chowning on the Stanford AI lab PDP-6 and PDP-10.

These two tutorials explain the error code calculations:

https://www.thonky.com/qr-code-tutorial/error-correction-cod...

https://dev.to/maxart2501/let-s-develop-a-qr-code-generator-...

I built an implementation in PDP-10 assembly language a while back:

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

There seem to be two mistakes here.

First, the SAIL PDP-10 didn't run TENEX. SAIL maintained their own operating system based on the PDP-6 Monitor, called WAITS. I guess you could say its closest relative might be TOPS-10; certainly many programs could easily be ported over back and forth.

Second, as noted here, TENEX was not "later called TOPS-10". It also wasn't called TOPS-20. DEC took TENEX, and with extensive modifications and updates produced TOPS-20. Meanwhile TENEX continued to be developed and maintained separately at sites that elected not to switch to DEC-20 machines.

I understand Scribe also started as a set of PUB macros.