Forth Application Techniques

oxgoad writes "Sun Microsystems, Federal Express, the National Radio Astronomy Observatory -- what do they have in common? All have used, or are currently using, the programming language Forth in critical subsystems of their products or processes. 'What is this language Forth?' you ask. Forth has been called 'One of the best-kept secrets in the computing world.' Read on for a review of the book Forth Application Techniques authored by Elizabeth D. Rather." Forth Application Techniques author Elizabeth D. Rather pages 148 publisher Forth, Inc. rating 5 reviewer oxgoad ISBN 0966215613 summary A concise introduction to the Forth programming language.

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.

Kudos

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

Quibbles

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

Crimes

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

Conclusions

Should 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

1. Introduction
2. Simple Forth Primitives
3. Structured Programming In Forth
4. Data Storage
5. Strings And Characters
6. Number Conversion
7. Vectored Execution
8. Advanced Concepts
9. Multitasking
10. Style Recommendations

Disclosure

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.

Comments

Re:Sun OpenBoot sucks

[Anonymous Coward]

No, it expects to find a some forth-like bytecode. The interpreter's part of OpenBoot. The market is stupidly stratified, by the way.

OpenFirmware is defined for the X86 architecture too - just motherboard manufacturers stick with proprietary PC-BIOS clones like PhoenixBIOS and AmiBIOS instead of OpenFirmware, so card manufacturers keep putting x86 assembly language into their BIOS blocks instead of OpenFirmware code.

Remember, the PC-BIOS and x86-architecture is a massive kludge! Why would you expect a Sun architecture to be able to run, AT BOOT TIME, x86 BIOS drivers?

Re:Religious experience to "get Forth"?

[Anonymous Coward]

Once you understand how to use the CREATE/DOES> construct effectively, you have a great deal of flexibility in expressing a programming solution. Most languages allow you to add new functions; Forth allows you to extend the compiler, using whatever syntax your imagination can conjure up --- one tailored exclusively for solving the problem at hand.

This power is often what someone refers to when they talk about "getting" it. Forth has also been criticized by some, ironically for that very strength. Why?

At the high levels of your application, you're no longer coding in Forth, but in the language you've designed to solve the problem. Reading that code requires a newcomer to understand that new language, in much more depth than they'd need for something like a C program. When designed by a competent Forth programmer, this code can be quite readable, at least in a general sense, by anyone who understands the problem domain. But a novice Forth programmer, particularly one who thinks in terms of writing a program in Forth (rather than extending Forth to solve the problem), can create a very unreadable mess.

With power comes responsibility (a phrase that predates Spider-Man, by the way :). Forth has no training wheels, but once learned, it is a very useful tool. "Getting it" is worth the effort.

Re:Computer languages are all the same

[AB3A]

Let me guess: fasteners are all the same, so let's use a hammer to pound in a screw.

Most languages have a focus toward a particular aspect of programming. Some are very good for Object orientation. Some are good for low level hardware I/O. Some are designed to parse input in optimal fashion. Others are designed for terse code.

They all have a purpose. That's why we have software tool chests with lots of languages and tools which can be used in so many ways.

Forth is good for low level I/O work. It's often used in Robotics and control systems. It is a minimalist language and it generates very fast, memory efficient code. These are good traits when dealing with embedded processors. But once you try scaling it up to do more complex tasks, you discover its limitations. That's when higher level languages start to shine.

Re:Still Worth Learning

[Waffle Iron]

It's also worth learning just because it's one of the few languages that is simple enough that you can actually understand the implementation top-to-bottom. You could write a simple Forth interpreter in assembly language in a couple of days, just to educate yourself on how languages work. (I did this once for 16-bit X86s about 15 years ago).

Forth is also an excellent example of "emergent behavior". Even though the language implementation is simple, the dynamic behavior can quickly becom mind blowing. I still have a hard time completely understanding the way some of the compiling "words" (which dynamically add syntax to the language similar to Lisp macros) work in Forth.

If nothing else, Forth will teach you to factor your code into small procdures, because making a function longer than about 5 lines quickly becomes unreadable :).

Fabulous language, but for an uncommon situation

[dwheeler]

FORTH is truly a fabulous language when you need to be able to interactively develop a program, where both the programming and execution must run on a very tiny machine (e.g., 2-48K RAM and 1-10MHz), and you still need the program to run quickly. Not only can you write code quickly, and get lots of interaction, but many Forth implementations are extraordinarily small, so you can actually read _every_ line of machine/assemly code that's executed on your equipment if you need to. I remember some absolutely magical programs being written on Apple II and Atari 800 computers (32-64K RAM, 1MHz 6502 chips).

The problem is, the situation that FORTH is great in is becoming increasingly rare. Most FORTHs still require programmers to constantly think about how to juggle the stack if they receive a number of parameters (yes, there are some extensions). FORTH has essentially no type-checking, and the combination of these two factors means that it's extremely easy to (1) make a mistake and (2) for that mistake to have nasty consequences.

Many program language implementations generate intermediate stack-based code (think Java class files, Python, Perl, etc.); in FORTH, you're writing the stack-based code yourself, so you are essentially writing in an assembly language for a simulated stack-based system. FORTH thus has some of the similar properties as assembler: fewer development system resources are required, but it's more work for the programmer. This isn't completely true; FORTH is definitely much higher-level than the typical assembly language program, but many programs take more work to implement in FORTH than, say, Python (which is also interactive, and it executes a stack-based program, but lets people express code in a more Algol-like way and then TRANSLATES that code into a stack-based approach).

I do think Forth is a good language to learn, because many systems are built on stack-based intermediate languages (Java, C#, Perl, Python), and being able to directly interact with a stack-based language helps to learn how they really work.

An implementation of Forth for 6502 is freely available.