My History With Forth And Stack Machines | Hacker News Reader

My History With Forth And Stack Machines

yosefk.com

95 pointssehugg11 comments

I've been using Forth for a while to write small video games, and honestly I find the process delightful. The extreme simplicity and flexibility of the language lend themselves well to the kind of special-case explosion that often occurs as I tinker with game logic, and puzzling out the cleanest way to express complicated ideas is very intellectially satisfying. Working on a simulated game console with no underlying operating system and unrestricted access to memory seems to be an ideal case for the language.

If anybody's curious, all my development tools and forth code are on github: https://github.com/JohnEarnest/Mako

Looks pretty neat! I've been thinking of using FORTH in the same way; I'll be really interested to read through your sample games.

(I played around with GraFORTH on the Apple ][ back in the day, and I remember it was wicked fast, and kinda fun)

Thanks! There's a few things about my dialect of Forth that are unusual if you've worked with Forth before, mainly just the fact that it is a "static" subroutine-threaded forth which lacks the ability to define new immediate words and it has some special-case syntax for string constants and the like. I do have a quick-start manual available: https://github.com/JohnEarnest/Mako/blob/master/docs/makoBas...

Thanks for sharing your VM & games -- I've been reading through the docs & source and finding them both interesting & inspirational.

I took a look at the sample games and the code looks.. interesting, though I admit I understood close to none of it ;-) Though I understand the constructs (I played with Forth and Factor in the past), I find it hard to keep a mental model of the stack in my head. I do have a soft spot for concatenative languages though so I love seeing stuff like this - great work!

Around 1980, while still a Stanford student, I used Laboratory Microsystems' PCForth to write a editing/publishing system for SAT math preparation, complete with embedded figures and equations and animated answers. The 'aha' at the time was to store the graphics not as bitmaps, but as a stream of parameters that were interpreted, allowing my system to save hundreds of quiz questions on a single floppy. That vector approach also made editing objects and layers trivially simple. Got the attention of ETS and Addison Wesley, both of whom flew me out to demonstrate how I did it.

But when I started building my own software product to sell and support, adding things like one of the first networked learning management systems and a homemade graphics windowing system (schools were MSDOS or Apple II in the day, if you wanted a GUI you built one) I switched everything over to C even though that meant teaching myself C and re-architecting everything from scratch.

Creating and working with abstraction layers was critical to that project's success, and simply not doable in Forth. So I've always thought of Forth as kind of like a first girlfriend - maybe not "The One" but a delightful and important phase that helped me learn what was important to me.

http://factorcode.org/ may be of interest to you.

I wrote a whole FORTH interpreter[1], and I have to agree with the article, in part. I don't think it's a good language for large scale engineering, and I don't think if I was a great FORTH programmer I'd change my opinion of it.

[1] http://git.annexia.org/?p=jonesforth.git;a=summary

I've known two "great" FORTH programmers in the last 30 years. They were both very pragmatic individuals, good engineers who made good decisions and good products.

I've also known a number of FORTH enthusiasts. In general I've not been impressed with their efforts, or their insistence that FORTH is the Universal Language, and everyone not using it for everything is missing out big.

I think it'd be fun to hack on one of Moore's multiprocessor systems. But I don't think I'd want to program one for a living.

old comments :

http://news.ycombinator.com/item?id=1680149

that was an absolutely fascinating (and very well written indeed) article. for those of you who tl;drd it, this bit towards the end was particularly insightful:

-----------------

Why pay this cost? Because I don’t do algorithms, other people do, so I have to trust them and respect their judgment to a large extent. Because you need superhuman abilities to work without layers. My minimal stack of layers is - problem, software, hardware. People working on the problem (algorithms, UI, whatever) can’t do software, not really. People doing software can’t do hardware, not really. And people doing hardware can’t do software, etc.

The Forth way of focusing on just the problem you need to solve seems to more or less require that the same person or a very tightly united group focus on all three of these things, and pick the right algorithms, the right computer architecture, the right language, the right word size, etc. I don’t know how to make this work.

My experience is, you try to compress the 3 absolutely necessary layers to 2, you get a disaster. Have your algorithms people talk directly to your hardware people, without going through software people, and you’ll get a disaster. Because neither understands software very well, and you’ll end up with an unusable machine. Something with elaborate computational capabilities that can’t be put together into anything meaningful. Because gluing it together, dispatching, that’s the software part.

So you need at least 3 teams, or people, or hats, that are to an extent ignorant about each other’s work. Even if you’re doing everything in-house, which, according to Jeff Fox, was essentially a precondition to “doing Forth”. So there’s another precondtion - having people being able to do what at least 3 people in their respective areas normally do, and concentrating on those 3 things at the same time. Doing the cross-layer global optimization.

Reply on news.ycombinator.com