

My History With Forth And Stack Machines - sehugg
http://www.yosefk.com/blog/my-history-with-forth-stack-machines.html

======
RodgerTheGreat
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>

~~~
sehugg
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)

~~~
RodgerTheGreat
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...](https://github.com/JohnEarnest/Mako/blob/master/docs/makoBasics.md)

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

------
pardner
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.

~~~
jacquesm
<http://factorcode.org/> may be of interest to you.

------
rwmj
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>

~~~
kabdib
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.

------
pella
old comments :

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

------
zem
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.

