Slashdot Mirror
Forth Application Techniques
Who & What
Elizabeth D. Rather, president of Forth, Inc., would appear to be the second Forth programmer in the universe. This distinction came about in 1971 when she was brought in at the Kitt Peak NRAO to maintain code written in a quirky language developed by Chuck Moore. Running on a DDP-116 and a H316, this code was responsible for controlling the telescope, data acquisition, and graphical display. After a few years, Moore and Rather, along with Edward K. Conklin, formed Forth, Inc. to attempt commercialization of the language.
Forth Application Techniques attempts to provide a comprehensive introduction to the language for the neophyte Forth programmer. I would say that it pretty much succeeds as such, quietly plodding away through each primitive and feature. It is written in workbook style with various sample problems for the reader to complete. You might not be a Forth coder after reading the book cover to cover; however, you will have a working knowledge of the language and should be able to walk through legacy code with a minimum of difficulty.
If I might step aside from my role as unbiased book observer for a moment, I would like to make a few comments about the state of programming languages in general. It seems that quite often we take for granted essential, but practically invisible, tradesmen such as plumbers and garbage collectors. (Fire your janitor and your web designer -- guess which one you will miss first. Guess which one will still be employable 15 years from now.) Yet, without their services, our daily quality of life would certainly fail to meet our expectations.
Likewise, Forth seems to be an invisible language. No flash, no e-commerce, and no glamour. Such is the nature of embedded systems -- even though every Federal Express delivery driver carries a Forth-based device on his belt. This appears to have resulted in a dearth of quality books dealing with Forth. Search your favorite online book retailer and note the dozens of Forth books that are no longer in print.
While Scheme is from the ivory tower and Forth might be said to be from the machine shop, they do have something in common that is a possible deterrent to the popularity of Forth. Like Scheme, you either get Forth -- or you don't. Stack-based languages leave some programmers dazed and confused. And, as with most languages, it is possible to write some truly obfuscated code. Any language that will allow you to define the number 4 as a word that places the number 3 on the stack can be a frightening weapon in the hands of the contrary.
KudosForth Application Techniques can be commended on its consistency. Careful attention has been given to typefaces to distinguish interpreter output from user input. All primitives and defined words are covered in a clear and unambiguous manner. The book is spiral bound in a plastic binding, and this lay-flat binding is great when using it at your computer or while eating lunch.
QuibblesThe same lay-flat spiral binding that is such a boon when working at the computer can be somewhat of a nuisance when when attempting to hand-hold the book -- the book tends to flop about and feels very insubstantial.
While Forth Application Techniques is very complete and accurate, it is also extremely passionless. You might compare it to a biology textbook discussion of sexual reproduction with no mention of romance. There is no discussion or examples of using Forth in ways that will bring enlightenment. To be fair, in the preface it states that the purpose of the book is to support Forth classes taught at Forth, Inc. This is something that is not entirely clear when examining online retailers' display of the book.
Also of note is that there are occasional features specific to Forth Inc.'s SwiftForth product documented in the book. I would not consider this a real issue as all instances are clearly denoted with an icon. With the exception of chapter 9, which is entirely Forth Inc. specific, the readability is not affected in any way.
CrimesForth Application Techniques has no index. With its workbook styling, most will not consider this to be a tragedy. All the same, it would be convenient to look up primitives and defined words.
ConclusionsShould you buy this book? That depends on your desired end result. It is adequate for a quick introduction to Forth. If you are intending to write production code I believe Forth Programmer's Handbook (from the same publisher, review forthcoming) would be a better choice. If possible, I would supplement either with a used copy of Leo Brodie's Starting Forth -- an out-of-print classic.
Where I foresee this book to be a great benefit is in ordering a half-dozen copies for your programming team prior to taking on a legacy project or when considering Forth as a new development platform. The members of your team that "get it" can then enlighten the others with this invisible language.
Table of Contents
- Preface: About This Book
- Introduction
- Simple Forth Primitives
- Structured Programming In Forth
- Data Storage
- Strings And Characters
- Number Conversion
- Vectored Execution
- Advanced Concepts
- Multitasking
- Style Recommendations
I received a review copy of this book from the publisher. Thus, my loyalties and opinions may be completely skewed. Caveat Lector.
Forth Application Techniques is available from Forth, Inc. and from some online merchants like Amazon. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Every time I read about Forth it takes me back, I had a Jupiter Ace as a kid. Sad to say that it was easier to get my ZX81 to do cool stuff so it got kind of neglected. Shame.
Maybe it's time to google up an emulator and indulge in a bit of notsalgia.
Reginald Molehusband. Edinburgh, Scotland
This was my first home computer - and it ran Forth. I won it in a competition in Popular Computing Weekly back in 1982. I never quite figured out how to program it, because my ZX-Spectrum 48k arrived the next day. Maybe if my sinclair had been delayed I would have taken the time learning how to write Forth, and perhaps by now I could have programmed my own Radio Telescope (which has to be the ultimate way to cheat at SETI@home) :-)
FORTH is an incredible language!
I ran Miller Microcomputer Forth on a TRS-80 back in the day and it was amazing.
Forth is totally stack oriented. It is difficult to determine where the OS ends and the language begins.
It is naturally recursive.
DONE RIGHT you can do a LOT in a few lines.
You can shoot yourself in the BULLET with Forth.
And Spiderman would code in Forth because...
It's Christmas everyday with BitTorrent.
Fortran used to let you do that, but usually by accident.
Parameters were *always* passed by reference (var in pascal or & in C++), so you couldn't pass a number constant. Compilers would create a table of constant values, though, and pass the address into the table. However, if the function modified the value, it modified the number "constant" entry in the table.
Forth is still great when resources are very limited... Palm OS programming, for instance. I've used it there and in several embedded systems projects without an underlying OS, and managed to run circles around a team coding for 8051-based systems in PL/M (I think that's the name of what they were using, but I'm not 100% certain).
.NET's CIL. And nothing I've seen teaches factoring better than Forth (too bad Brodie's "Thinking Forth" is out of print).
I also tried a version of Forth-83 for Windows by Ray Duncan's company, LMI. I tried to code up a DDE server, and while it worked, it was painful. I've come to believe that Forth is more trouble than its worth when interfacing to APIs designed for C. Such APIs are often poorly factored (relative to how you'd solve a problem in Forth), and take too many parameters of different sizes as arguments. Even with the Palm you jump through some of these hoops, but in that environment it's often worth the effort.
The underlying principles of Forth are worth knowing no matter what language you program in... there's a lot of simplicity at its core, and it'll help you understand how to program for other stack based languages such as
...unfortunately, it's got it's own acronym, MUF, short for Multi User Forth. It's used on a sub-set of on-line Multi User Dungeons known as MUCK's, specifically all those based on the FuzzBall variant, which at this point includes a couple of notable ones such as ProtoMUCK.
As a quick pair of references, check out the ProtoMUCK and FBMuck projects on SourceForge.
Apple's OpenFirmware also uses forth. Hold down Command+Option+o+f at startup and you are thrown into a Forth shell. How's that for a BIOS?
It's entirely possible to make money working on free software -- that's what I've done for the last two years.
That said, the parent poster is indeed an idiot. Much commercial software is worth buying, and not all products can be economically written and supported as open source.
Incidentally, I interpreted the "give you nothing in return" thing a bit differently wrt Sun -- their machines really don't have the same value proposition as many others (Intel-based systems on the low end, IBM's big iron on the high end), and I took the (great?) grandparent to be painting a somewhat exagerated carciature of that.
In the late '80s, there was a sweet Forth implementation for the Mac called Mach 2. It produced native 68000 code -- unusual because most Forths produced an interpreted byte-code, but possible because of the 68000's stack orientation -- and was cheap (about $50).
While it wasn't the easiest thing in the world to use for building complete GUI apps, it was a great experimental tool because it was essentially an interpreted assembler/disassembler! You could experiment with OS traps that were recently published but hadn't made it to other compiler implementations, and see what machine opcodes would do the job minimally.
You could then take those opcodes and drop them into, say Turbo Pascal (which was barely supported by Borland) as inline machine instructions. Way cool.
The other place where Forth came in handy was a couple several years later when learning PostScript: as a stack-based language, PostScript was a cinch to pick up. Of course, if you've been using RPN calculators, it shouldn't be too bad either.
Forth may be a little low-level in these days when Perl and Python provide such abstract data types, but it makes you think closer to the hardware. When hardware control is an issue (in devices like telescopes, barcode readers, etc.), Forth beats programming in assembler by a long shot.
Design for Use, not Construction!
set/read variables
conditional, branching and looping constructs
call functions
I see very little difference between:
Lisp/Scheme's
(my_function (+ a b))
C/C++/C#/Java/Javascript's
my_function(a + b);
Forth/Postscript/other postfix languages
a b + my_function
or assembler:
push a
push b
add
jsr my_function
It just boils down to syntax and ease of typing.
It's interesting to note that C-style syntax seems to have won the popularity contest, though. Code is written in any of PHP, Perl, C, C++, Objective C, C#, Java, Javascript are easily understood by anyone versed in any language in the set.
Most languages are stack based, but a few like Lisp and Javascript support the notion of closures. But even closures can be emulated in C of course via heap allocated memory and function objects. Indeed, you can emulate any computer language construct in any other computer language (with varying degrees of efficiency, of course).
In the end, the computer language is usually chosen based on:
popularity (because this implies support for the language and longevity for your system)
ease of coding
execution speed
Too bad there does not exist a universal computer language compiler system whereby one could code in the computer language they prefer and check the code in and the next guy could check out the code in the language they prefer.
while it's true that PostScript and Forth use Lukasiewicz (Reverse Polish) notation, the former bears little resemblance in syntax to the latter. PostScript's a lovely and subtle language, but gets interesting when you're debugging an 800MB imposed printing plate ...
I keep seeing mentions of Forth being an interpreted language, but that's just an implementation choice. Most modern Forths, such as iForth, VFX Forth, and Forth Inc's own SwiftForth, generate machine code and do optimization to varying degrees. iForth and VFX Forth analyze stack operations and replace them with register operations where possible. Benchmarks have shown that iForth generates better floating point code than Microsoft's Visual C++ compiler (which already generates better floating point code than gcc).
So why don't you hear about Forth much? A couple of reasons:
1. Forth doesn't have much in the way of standard libraries, so you'll almost certainly get more bang for your time writing quickie applications in Perl or Python than Forth. Try writing a Forth program to read in a file of strings of arbitrary length and sort them, for example. This is a one liner in Perl.
2. Forth has always been geared toward simplicity, but modern desktop environments (Linux, Windows, MacOS) are hugely complex. Forth arguably isn't the best match for such complexity. Embedded systems are different.
3. Forth is best viewed as an interactive alternative to C or assembly language. Certainly from the interactivity alone Forth is a better choice for incrementally building a application than assembly language. This is why Forth gets a lot of use in embedded systems. But with desktop computer speeds being insanely high, it's hard to justify working on that kind of level under, say, Linux or Windows.
(I fully expect this to be followed by "Not true!" rantings from a Forth zealot or two. But you really do have a hard time pointing to compelling applications written in Forth for modern desktop OSes. Python is a good language, so you see some amazing applications written in it (e.g. Zope), but despite all the religion surrounding Forth, you never see much to show for it on the desktop.)
Er, I did.
:) . And that the unplayable example song getting a life of its own in the GuitarTeX manual!
Back in the day (crikey was that really 8 years ago???) I wrote PSTab, a guitar tablature typesetter, in postscript. I'd been downloading tab for songs from the (defunct?) OLGA, and wanted to print some for use at home. However, ascii tab looked crap and took lots of space on the page; if you tried to shrink it to use less paper it just left blank space at the sides.
We had an old Apple II laserwriter on the corridor, and I had written simple EPS diagramming tools for my thesis in awk (copy and paste programming)... so armed with borrowed copies of the red, green & blue books, I learned PS properly and wrote a typesetter that you could use as a header on simple input files (I'd spotted this was how the windows PS driver worked). Once I got to the stage I could wrap ascii-tab up to make *nice* output pages my itch was scratched[1].
Best thing about it was getting an email from a guy in NZ who used it to produce camera-ready copy for a book of banjo music - there wasnt anything else out there that could handle 5-stringed instruments
-Baz
[1] I know there are bugs. Some of these didnt show up until I saw the output on a higher quality printer. Bah.
For some boring stats course we had a programming assignment "in a programming language of your choice".... big mistake
:-)
since it was basically a simple statistical experiment + graphical output, I wrote it in PostScript.
Kinda cool, it was a report with the statistical experiments embedded, so if you printed it twice, all the graphs were different
Speaking of Wizardry, one of the authors (Greenberg, I believe) prefers Smalltalk. You can go to the Squeak mailing lists at Yahoo and read his regular postings. I think he's a lawyer now.
sean
% Save this as dragon.ps for 15 pages of
% fractal iteration -- commented even!
% define constant of 1/sqrt(2)
/Scalefactor 1 2 sqrt div def
% Define Fractal subroutine
% usage: lvl Fractal stroke
% Examples below are as if called with a level of 5
/Fractal { % 5
dup % 5 5
0 eq % 5 false
{
% True condition: draws line segment
pop 300 0 rlineto % -
}
{
% False condition: recurse routine
% set the scale factor
Scalefactor dup scale % 5
% On alternate iterations, level is set negative. When negative, reverse the angles
dup -90 exch % 5 -90 5
0 lt % 5 -90 false
{ neg exch neg exch } if % 5 -90 false
% Recurse one level lower
dup 2 div % 5 -90 -45
rotate exch 1 sub % -90 4
% Actually call myself again
dup Fractal % -90 4
exch dup neg % 4 -90 90
rotate exch neg % -90 -4
% Call second time for second stroke
Fractal % -90
2 div % -45
% set things back to the original scale and rotation
rotate % -
1 Scalefactor div dup scale % -
}
ifelse
} bind def
% Loop to iterate 15 pages of fractal
currentlinewidth 4 div setlinewidth
0 1 15 { 200 400 moveto Fractal stroke showpage } for
Design for Use, not Construction!
Once apon a time the first language for any new machine was Forth. But then again it's been a long time since we've seen any really new machines.
The reviewer is correct, someone groks forth or they don't.
Being a person who groked it from the second he saw it in 1978, I can't understand anyone not getting it.
Sure RPN notation is hard for some (apparently most) folks, and boolean logic just doesn't seem to be natural for most people, and then the stack just knocks them in the head, but these are three of the four pillars of what makes forth great.
The fourth pillar of forth is that you can change it to be anything you want, most languages have to be learned, forth is a language that you can teach to learn you... If RPN is just intolerable you could redefine it and still leave the core alone for pre existing words (functions for the non forth crowd).
Leo Brodie's "Starting Forth" and "Thinking Forth" books are great and it's a shame that Brodie no longer has an interest in the language.
As a long time forth user I'm not thrilled with the complexity added in C. Moore's latest version colorForth, it seems to add a new layer of complexity, but then again I may just be unable to Grok it.
Personally I'd love to see Forth brought to the GUI era and don't understand why it hasn't been.
I find it interesting that so many people comment that Forth is meant for embedded environments and has no place in a "modern" GUI system. But PostScript is similar to Forth in flavor, and its original embedded target was printers... and now OS X uses "Display PDF", more or less a superset of Display PostScript.
Just because a tool like Forth is traditionally used by a single programmer in a very cramped system doesn't mean it couldn't have applications in other places. There are many things I wouldn't write in Forth... and there are many times I find myself writing GDI calls and wishing for a more Forth-like interface.
Java: the COBOL of the new millenium.
I remember a story I read in the famous German "c't" magazine many years ago:
;-)
Sometime in the 80s (Germany was still a divided country then), a competition was held for university students from all over Germany. The goal was to write a program to control a robot to perform some predefined tasks, with the team who took the shortest time to finish the program being the winner.
The teams from West Germany used their butt-kickin' (for the time) Intel-based systems (DOS, C, Pascal, harddisks and whatnot).
The competition, however, was won by the only team from East Germany. They used an U880 (a GDR Z80-clone running at 1 or 2 MHz) based Robotron computer which had maybe a tenth of the power of the other teams' computers, and Forth as a programming language.
Yep, it's not the size, it's how you use it
"There are already a million monkeys on a million typewriters, and Usenet is NOTHING like Shakespeare." - Blair Houghton
Euskera, the native language of the Basque people, has a basic structure that is reminiscent of Forth. Whereas English speakers are used to a caseless prepostional system, Euskera speakers are used to a case-based postpositional system that leans mostly toward a "reverse" sequence of sintagms. Here are some examples in my (now rusty) dialect:[1]
Well, I could go on, but I think you get the point.
You can think of a case postposition (of which there are quite a few and which confer great functional specificity) as a sort of type marker, which makes Euskera a sort of object-oriented, reverse-notation language.[2]
__
[1] Any euskera batua fascists reading this can send their corrections of my grammar and spelling to /dev/null.
[2] Well, reverse for English speakers in any case, ha ha.