As you learn Forth, it learns from you (1981)

There have been some great responses that cover the gist of it, but to add a couple more mundane specifics:

- Build up the thinnest abstraction that lets you express a solution in the problem domain.

- Allow the API user to express their intent, and not be focused on mechanics they don't need to understand to get the job done.

- Focus on getting the interfaces right before the implementation is perfect.

- A clean interface will allow you to make drastic changes to the implementation without the API consumer becoming aware.

Not the OP, but for me one of the main lessons from Forth is that the boundary between high and low level code can be as thin as you make it. With Forth, you can define high level words using low level primitive words. You then weave these low level words together at a high level. After you have written a correct solution at a high level, bottlenecks can be optimized out by introducing new low level words. It's like you are solving a problem by designing an instruction set specifically for that problem. But unlike a hardware ISA, you can add new instructions tailor made for the specific problem you are presently solving.

Paul Graham has described lisp as a tool for writing fast programs fast (that's the gist at least). IIRC, he clarifies that each fast is a phase. Lisp allows you to write a fast, high level, prototype that might have poor runtime performance and then you refine the prototype so that the compiler can generate fast machine code.

Forth is similar but feels closer to the machine than Lisp because of the stack based threading model. In Forth, you often don't need manual memory management _or_ garbage collection and you can easily extend the system with new low level words. But it does require you to think differently about your program design so that it fits the stack based vm model.

Historically, Forth has been implemented in assembly but you can write a Forth that targets any host. The truly mind expanding thing is that you, an individual, can write a Forth compiler and you can also write it in such a way that it has multiple targets. For example, you can generate native, jvm and js targets from the same underlying source. Usually this can be done by translating the forth generated AST to source code for another high level language. This allows you to write a fast high level language quickly without getting bogged down in writing, say, fast x86 codegen or a garbage collector. To get started, you just target the host language with the best high level properties that you need (which will be problem and context specific). I don't enjoy writing c, but I have no problem translating to c if I need to for performance or for syscall access.

To illustrate the practical power of this. Suppose that you have an important subcomponent of your system that was written in, say, Node.js. It turns out that this is a critical bottleneck that cannot easily be optimized in javascript. You don't want to rewrite the whole system, but you do want to rewrite that component and have it seamlessly interoperate with the existing system. You could write a small Forth DSL for that subcomponent. This Forth will target javascript initially. You translate the subcomponent into Forth and reuse all of the existing tests (that were presumably also written in javascript). Then you rewrite the tests in Forth so that the entire subcomponent is now written in Forth. Now you write a new backend that translates to say, c or rust with node bindings. You can run the native implementation against a native implementation of the test suite since they're both written in high level Forth at this point. Then you can flip the switch between the native or javascript implementations and be confident that both implementations are identical because they have the same high level description.

Once you start seeing things this way though, you start realizing that you can write Forth style code in any language (and the reverse is also true). Forth is as much about a process for solving programming problems as it is a specific, concrete language. This is also why there is the old adage "once you've seen one Forth, you've seen one Forth."

They just said it was like the LSD of programming languages. Your question is kind of like "What are your main takeaways from LSD? Can you summarize?" which realllly misses the point.

At the same time, disassemblers were handy tools for figuring out how things were done. Could be very learnful. Then they mysteriously went away for some reason.

Thanks for the view back into history. I was kinda under the impression that this side-hustle thing was new. Apparently its not only old, but was an essential part of the technological progress we've had since then.

i agree that we should have a better model as a society to produce things like compilers, but having a direct retail relationship with a closed source provider was pretty nasty.

because of tooling, large code bases, and weak standardization they had a huge amount of lockin. and only a single narrow funnel in which to address deficiencies.

and while certainly on a lower tier than EDA seats, werent super cheap. they usually had limited platform support. while they did optimize better for their targets, otherwise they were poorer systems than gcc, with all its warts.

Eh, the ones made by one or two people working part time and selling them as shareware weren't necessarily better than what we have available now. They may have been good enough for their time, but probably wouldn't cut it today.

And the ones made by corporations were prohibitively expensive. As a teenager wanting to learn, or a hobbyist making programs for fun, would you really pay $4500 for a compiler to tinker with projects in your spare time? There's one reason hardly anyone uses Delphi anymore. By the time they finally released a Community Edition, there was no community left that had grown up learning Pascal.

Oh man, those were fun times. I started with a Model 15 TTY (for ham radio). When I got my first 8080 machine (statuc RAM was an expensive extra), I learned a lot by making a PC board to convert 45bps (5-bit characters) to 110bps Baudot (using 2 crystals). Then teaching the 8080 to table-convert baudot to ASCII (from a 'ring buffer' filled using interrupts).

The good old days, before layers of 'protection' got baked in (Apple II vs Mac).

For only 1600 pounds.

I'm not a Forth programmer, but I used to be a Sun sysadmin. From what I recall, the Forth code on a SPARCstation is interpreted and pretty slow.

These docs support that: https://docs.oracle.com/cd/E19455-01/816-1177-10/816-1177-10...

The system supports FCode, which is processor-independent byte code. This allows expansion devices (like a card or peripheral) to bring with them their own platform-independent device drivers, which is pretty cool. So you could make a disk controller card and then any system that you plug it into could boot off it, no matter the CPU architecture.

Anyway, the point is, since it was mainly used for booting and diagnostics, I don't think they put much effort into performance. For it to be an actually good Forth environment, I think you'd want to have some way to run Forth programs as native code, either by adding the option to JIT the FCode instead of interpreting it or by adding a compiler that compiles Forth source to native.

Also, I believe the old PowerPC Macs (like G3, G4, and G5) used Open Firmware, so if you wanted this Forth experience, you have that option in addition to Sun workstations.

Mitch Bradley was the author of a great deal of that Forth; his CForth is on GitHub : https://github.com/MitchBradley/cforth

(It might be easier than finding an old Sun machine)

There are Forths with richer types than just that -- it's not just one language, after all. I've never heard of statically typed Forth; the stack is a filthy pile, after all. But nothing stops you from writing an allocator, container types, etc..