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.
Forth should be considered a family of languages; Anton Ertl took its picture some time ago [1].
Chuck Moore agrees I think with the idea [2]:
That raises the question of what is Forth? I have hoped for some time that someone would tell me what it was. I keep asking that question. What is Forth?
Forth is highly factored code. I don't know anything else to say except that Forth is definitions. If you have a lot of small definitions you are writing Forth. In order to write a lot of small definitions you have to have a stack. Stacks are not popular. Its strange to me that they are not. [...]
What is a definition? Well classically a definition was colon something, and words, and end of definition somewhere.
: some ~~~ ;
I always tried to explain this in the sense of this is an abbreviation, whatever this string of words you have here that you use frequently you have here you give it a name and you can use it more conveniently. But its not exactly an abbreviation because it can have a parameter perhaps or two. And that is a problem with programmers, perhaps a problem with all programmers; too many input parameters to a routine. Look at some 'C' programs and it gets ludicrous. Everything in the program is passed through the calling sequence and that is dumb.
Somebody somewhere suggested doing a clone of Tropico called ElPresidente, which is even cooler.
Btw, Lars, you have endlessly more experience in Elisp than I do. Do you maybe have any ideas/directions on how to make the graphical mode look... A bit more decent and snappy?
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.
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.
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.
you could make a standalone executable. I was assuming that people didn't want to start emacs to run it. if its just because...emacs is just morally offensive and one doesn't even want it running under the covers, I dont how to help you.
If you used Emacs as a stand-alone game engine, at least it could make it claim it was "Reticulating Splines..." for a few minutes while it started up.
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.
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.
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.
Was there any particular reason they did that, or was it just a random coincidence (that was the team that wrote it and the hardware they had access to was that particular machine and that particular machine ran MDL, otherwise, it would have been MACLISP)? Was there anything about MDL that helped with writing an adventure game?
reply