Examples of very concise Forth applications? [closed]

Question

As it currently stands, this question is not a good fit for our Q&A format. We expect answers to be supported by facts, references, or expertise, but this question will likely solicit debate, arguments, polling, or extended discussion. If you feel that this question can be improved and possibly reopened, visit the help center for guidance.

Closed 8 years ago.

In this talk, Chuck Moore (the creator of Forth) makes some very bold, sweeping claims, such as:

1. "Every application that I have seen that I didn't code has ten times as much code in it as it needs"
2. "About a thousand instructions seems about right to me to do about anything"
3. "If you are writing code that needs [local variables] you are writing non-optimal code. Don't use local variables."

I'm trying to figure out whether Mr. Moore is a) an absolutely brilliant genius or b) a crackpot. But that's a subjective question, and I'm not looking for the answer to that question here. What I am looking for are examples of complex, real-world problems which can be solved in "1000 instructions or less" using Forth, and source code demonstrating how to do so. An example showing just one non-trivial piece of a real-world system would be fine, but no "toy" code samples which could be duplicated in 5 or 10 lines of another high-level language, please.

If you have written real-world systems in Forth, using just a small amount of source code, but aren't at liberty to show the source (because it is proprietary), I'd still like to hear about it.

Answer 1

You need to understand that Chuck Moore is a little different than you and me. He was trained in an era when mainframe computers consisted of 16 KB or its equivalent in core memory, and he was able to do quite a lot of things with the computers of the time. Perhaps the biggest success for Forth, outside of his OKAD-II chip design package (that's not a typo), was a multi-user multi-tasking Forth system responsible for concurrently controlling data acquisition instruments and data analysis/visualization software at NRAO on a fairly modestly sized computer barely able to compile Fortran source code on its own.

What he calls an "application", we might consider to be a "component" of a larger, more nebulous thing called an application. More generally, it's good to keep in mind that one Moore "application" is more or less equivalent to one "view" in an MVC triad today. To keep memory consumption small, he relies heavily on overlays and just-in-time compilation techniques. When switching from one program interface to another, it typically involves recompiling the entire application/view from source. This happens so fast you don't know it's happening. Kind of like how Android recompiles Dalvik code to native ARM code when you activate an application every time today.

At any given time, OKAD-II has no more than about 2.5 KB of its code loaded into memory and running. However, the on-disk source for OKAD-II is considerably larger than 2.5 KB. Though, it is still significantly more compact than its nearest competitor, SPICE.

I'm often curious about Chuck Moore's views and find his never-ending strive for simplicity fascinating. So, in MythBusters fashion, I put his claims to the test by trying to design my own system as minimally as I could make it. I'm happy to report he's very nearly spot-on in his claims, on both hardware and software issues. Case in point, during last September's Silicon Valley Forth Interest Group (SVFIG) meeting, I used my Kestrel-2 itself to generate video for the slide deck. This required I wrote a slide presentation program for it, which took up 4 KB of memory for the code, and 4 KB for the slide deck data structures. With an average space of six bytes per Forth word (for reasons I won't go into here), the estimate of "about 1000 (Forth) instructions" for the application is just about spot on to what Chuck Moore estimates his own "applications" to be.

If you're interested in speaking to real-world Forth coders (or who have done so in the past, as it increasingly seems to be), and you happen to be in the Bay Area, the Silicon Valley Forth Interest Group still meets every fourth Saturday of the month, except for November and December, which is the third Saturday. If you're interested in attending a meeting, even if only to interview Forth coders and get a taste of what "real-world" Forth is like, check us out on meetup.com and tag along. We also new stream our meetings on YouTube, but we're not very good at it. We're abusing inappropriate hardware and software to do our bidding, since we have a budget of zero for this sort of thing. :)

Answer 2

Forth is indeed amazingly compact! Words without formal parameters (and zero-operand instructions at the hardware - e.g. the GA144) saves a lot. The other main contributor to its compactness is the absolutely relentless factoring of redundant code that the calling convention and concatenative nature affords.

I don't know if it qualifies as a non-toy example, but the Turtle Graphics implementation for the Fignition (in FigForth) is just 307 bytes compiled and fits in a single source block! This includes the fixed point trig and all the normal turtle commands. This isn't the best example of readable Forth because of trying to squeeze it into a single source block with single-character names and such:

\ 8.8 fixed point sine table lookup
-2 var n F9F2 , E9DD , CEBD , AA95 , 7F67 , 4E34 , 1A c,
: s abs 3C mod dup 1D > if 3C swap - then dup E > if
  -1 1E rot - else 1 swap then n + c@ 1+ * ;

0 var x 0 var y 0 var a
0 var q 0 var w 
: c 9380 C80 0 fill ; \ clear screen
: k >r 50 + 8 << r> ! ;
: m dup q @ * x +! w @ * y +! ; \ move n-pixels (without drawing)
: g y k x k ; \ go to x,y coord
: h dup a ! dup s w ! 2D + s q ! ; \ heading
: f >r q @ x @ y @ w @ r 0 do >r r + >r over + \ forward n-pixels
  dup 8 >> r 8 >> plot r> r> loop o y ! x ! o r> o ;
: e key 0 vmode cls ; \ end
: b 1 vmode 1 pen c 0 0 g 0 h ; \ begin
: t a @ + h ; \ turn n-degrees

Using it is extremely concise as well.

: sin 160 0 do i i s 4 / 80 + plot loop ;

: burst 60 0 do 0 0 g i h 110 f loop ;

: squiral -50 50 g 20 0 do 100 f 21 t loop ;

: circle 60 0 do 4 f 1 t loop ; 
: spiral 15 0 do circle 4 t loop ;

: star 5 0 do 80 f 24 t loop ; 
: stars 3 0 do star 20 t loop ;

: rose 0 50 0 do 2 + dup f 14 t loop ;

: hp 15 0 do 5 f 1 t loop 15 0 do 2 f -1 t loop ; 
: petal hp 30 t hp 30 t ; 
: flower 15 0 do petal 4 t loop ;

(shameless blog plug: http://blogs.msdn.com/b/ashleyf/archive/2012/02/18/turtle-graphics-on-the-fignition.aspx)

Answer 3

What is not well understood today is the way Forth anticipated an approach to coding that became popular early in the 21st century in association with agile methods. Specifically:

• Forth introduced the notion of tiny method coding -- the use of small objects with small methods. You could make a case for Smalltalk and Lisp here too, but in the late 1980s both Smalltalk and Lisp practice tended toward larger and more complex methods. Forth always embraced very small methods, if only because it encouraged doing so much on the stack.

• Forth, even more than Lisp, popularized the notion that the interpreter was just a little software pattern, not a dissertation-sized brick. Got a problem that's hard to code? The Forth solution had to be, "write a little language", because that's what Forth programming was.

Forth was very much a product of memory and time constraints, of an era where computers were incredibly tiny and terribly slow. It was a beautiful design that lets you build an operating system and a compiler in a matchbox.

Answer 4

An example of just how compact Forth can be, is Samuel Falvo's screencast Over the Shoulder 1 - Text Preprocessing in Forth (1h 06 min 25 secs, 101 MB, MPEG-1 format - at least VLC can play it). Alternative source ("Links and Resources" -> "Videos").

Answer 5

Forth Inc's polyFORTH/32 VAX/VMS assembler definitions took some 8 blocks of source. A VAX assembler, in 8K of source. Commented. I'm still amazed, 30 years later.

I can't verify at the moment, but I'm guessing the instruction count to parse those CODE definitions would be in the low hundreds. And when I said 'took some 8 blocks', it still takes, the application using that nucleus is live and in production, 30 years later.