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.
Not that forth is dead by any means, but it has sort of lapsed into obscurity.
:)
Nice to see recent development is still happening,
as forth always has been the best for what its designed for, controlling stuff. Probably always will.
Plus its sooo cool
---- Booth was a patriot ----
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) :-)
If you have any questions for Elizabeth Rather, she can be found on Usenet. When I asked for an "introductory book for modern Forth" I believe she recommended her own book! :-)
Threaded Interpretive Languages (TILs) such as Forth have very elegant inner workings. I even wrote one as a kid. And I actually used it for a few months. Although my Forth-inspired TIL was limited to 16 bit integer math (on an 8086 I think it was), I still managed to get it to draw 3d wireframe graphics in real time on a PLUTO graphics card :-)
RB
Until I see a decent Language to switch to I'll stick to my punchcards.
Be you Admins? nay, we are but lusers!
Back in the days of yore, when the world was still mostly in black and white, and strange man-eating beasts wandered the land, a small British company brought out a cute little computer called the Jupiter Ace.
It was basically a Sinclair ZX-80, but with Forth in ROM, instead of BASIC. It was a fun little thing to play with.
I may still have mine in a box in the attic. Must go check.
668: Neighbour of the Beast
review forthcoming, eh? what a mad little punster you are. ;)
Postscript is based on Forth. You can "program" Postscript...
Don't know why a non-printer driver person would want to, but you can...
-LG
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.
"Best kept secret" is actually a review for Forth, not the problem. If I'm going to have to deal with a stack, it should have butter and syrup on it.
$you = new YOU;
honk() if $you->love(perl)
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
Forth is still in heavy use, actually, as the language for Apple's Open Firmware (IEEE-1275) implementation:
:-)
http://developer.apple.com/hardware/pci/
Oh, huh? I was supposed to make a point? Whoops.
-/-
Mikey-San
Mikey-San
Karma: +Eleventy billion (mostly affected by watching Celebrity Jeopardy)
...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.
Trolling using another account since 2005.
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?
Yep. Sun use Open Firmware, as do Apple Macs. Open Firmware (or IEEE-1275 - those wacky IEEE names) uses Forth. Even if the rest of the machine is hosed you'll still be able to use forth. Err - great :-/
Slashdot looked deep within my soul and assigned
me a number based on the order in which I joined
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.
I just went through amazon.com web site and I regret that most (if not all) Forth books written by Leo Brodie are out of stock...
I remember waiting until 4 months to get a copy of "thinking forth", by the way.
Now, if you want to learn forth, there seem to be the gforth manual, at least...
Trolling using another account since 2005.
Some of Moore's trial runs for Forth ran on Burroughs mainframes and were actually implemented as card decks.
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?
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!
Hey, you just rebooted my machine ...
HI and HELLO in forth (depending on flavor) reboot.
Can't wait to get my hands on the new book, we are heavy forth users.
TastesLikeHerringFlavoredChicken
She now works with Forth, Inc. Check out forth.com. They have an excellent history of the language here. BTW, there are free Forth interpreters for just about every platform out there. It's a cool language.
Chuck Moore's own site is here
Alison
"It is a miracle that curiosity survives formal education." - Albert Einstein
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.
:). Forth has no training wheels, but once learned, it is a very useful tool. "Getting it" is worth the effort.
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
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.
... And I certainly remember the joke about how in Forth you "Foot in yourself shoot."
I did my Forthing many years ago (far, far too many). The usual thing, embedded systems work, but I actually did the programming on an IBM PC (original) using a Forth boot floppy (it had its own environment/OS). Then someone else did integration with the embedded system.
It was a truly weird language, and it made it far too easy to create 'write-once' unmaintainable code. But it was my first introduction to many concepts, including a language that was truly 'cross-platform'. And it led to a short job at Aldus because I already understood stack-based languages, so Postscript wasn't a shock to me.
In many ways Charles Moore is a seriously twisted genious. I have always rooted for him, despite the fact I prefer to use a cleaner, more readable language. (Can we say 'Python'? I knew we could.)
So, in the end, I cannot say I think Forth should be in everyone's toolkit. For that reason I expect this review will be of limited use to most of us. (Attn. Moderators, notice how I managed to get this post on-topic in the last sentence. Now you have to mod me down as 'flamebait' or 'boring' or something.)
Jack William Bell
- -
Are you an SF Fan? Are you a Tru-Fan?
If you want to fool around with FORTH
on your own and for free, take a look at
Phil Burk's
public domain pForth
Wait a minute. Didn't I say that on the other side of the record? I'd better check
Chuck Moore's home page:
http://www.colorforth.com
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.
Nearly fifty percent of all graduates come from the bottom half of the class!
Leo Brodie's is one of the best books to learn Forth with. And the cartoons in it are the funniest/best in a manual that I have seen since the first Wizardry Manual!
ttyl
Farrell
CAN-CON 2019 - Ottawa's only book oriented Science Fiction Convention! October 18-20, Sheraton Hotel, Ottawa, Canada h
FORTH IF HONK THEN
Did anyone own one of these? It was a wacky ZX81-like computer with a membrane keyboard and 4k. of memory. Instead of programming in BASIC you wrote in Forth. Needless to say it didn't catch on!
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.
- David A. Wheeler (see my Secure Programming HOWTO)
Most people who were weened on HP RPN calculators like Forth's postfix notation. I find it a bit unnatural but I was a FORTRAN man for a long time.
"player 4 hit player 1 with 0 stroms"
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.
As you point out, Forth is not a language for writing GUI applications. It's for things like controlling stepper motors in telescopes. It's an embedded systems language for low-level machine conrol. And for those purposes, it's superb.
I, for one, appreciate its simplicity. The modern C/C++ implementations make my head hurt. I don't want a language where there are countless libraries with which I have to remain familiar. It's astounding to see how many C/C++ programmers believe that various Borland/Microsoft libraries are an inherent part of the language.
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 see very little difference between:
[deleted]
Apparently you don't look very hard. There are significant differences even in the examples you have presented. First of all the LISP/Scheme code support introspection (you can determine the contents of my_function with other LISP/Scheme code) which is impossible in the C (and that won't work in C anyway) or assembler model. Secondly the issue of type safety is unaddressed especially in the assembly and C code (what are you adding integers? Reals? Complex values? Inquiring compilers want to know). Finally to paraphrase Larry Wall states a language should make the easy things easy without making the hard things impossible which is the driving impetus behind programming language creation. There are real and fundamental disagreements over what is/should be easy and what's impossible.
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.
That desire seems to express much of the design behind the .NET CLR. In principle it should be possible to disassemble CLR code into a language other than its original implementation, however the disconnect in features (just how would you disassemble a LISP closure into C code? Or worse yet the entire Smalltalk environment?) makes this less feasible than your simplistic assumptions would indicate.
Or maybe it was URTH, which I think stood for University of Rochester forTH. I seem to remember using this language once upon a time as a co-op back in about 1982, but the net, even Google, seems to retain little memory of it. I say "seem" to remember because I can't recall which exact FORTH or FORTH-like language we used, but I'd like to know because I'd like to find a similar version.
--Jim
All computer languages rehash the same concepts:
set/read variables
conditional, branching and looping constructs
call functions
Let's see: the FORTH textbook I own didn't include anything on variables, as it considered them unnessecary. (Which, to a large extent in FORTH, they are.) Lots of Lisp ('pure' Lisp) doesn't use branching or looping constructs, using recursion for everything. APL is comparitively normal - but looping isn't well supported, instead you do everything in parallel on vectors.
XMLDataNode xdnLoginRsp = new XMLDataNode("LoginRsp");
xdnLoginRsp.addAttribute("Result", strResult);
WebPacXMLUtils.addNotNullChild(xdnLoginRsp, "SessionID", strSessionID);
return new XMLDataDOM(xdnLoginRsp);
The only good weather is bad weather.
This comes up from time to time.
But computer languages vary greatly.
It just boils down to syntax and ease of typing is just nonsense...
how about:
declarative vs procedural
portability
extensibility
testability
formal provability
code compactness
interactive vs. compiled
static vs dynamic memory models
object orientation
???
It is a lot more than syntax.
Forth happens to be very unusual as a language. It is extremely extensible (it is trivial to redefine the meaning of "if" should you want to). It is based on a dictionary concept. It has a compiler and interpreter that together can be written in about 3 lines on an 80 column wide screen (if you don't do pretty-print formatting). It is highly portable because, like LISP, it starts with a very small set of primitives that need to be ported, and then builds itself out of them. Creating an application from it simply continues that extension process.
When you write an application in Forth, the high levels of your application look almost like english text optimized to express your algorithm. It doesn't even have to be recognizable as "Forth." Charles Moore (http://www.colorforth.com/), who invented Forth, is a brilliant and iconoclastic guy who made a real contribution by creating a number of original language concepts.
One thing that is very tricky in Forth is cross-compiling. Because there is no difference between compile time and execution time, cross-compiling is inherently undefined. In order to make it work, you have to play some pretty subtle and head-breaking tricks.
The only good weather is bad weather.
If you look only at the code the machine actually executes at the CPU level, I suppose one could make an argument that all HLLs are the same, since the code they compile into looks much the same for any given task. The difference, of course, is in what tasks the language lends itself to from the programmer's point of view. People use HLLs because they abstract concepts from implementations; different languages abstract different concepts differently, making some tasks easier to accomplish - from the coder's point of view, of course. The computer doesn't care.
Or, you can look at it another way. There's a vast universe of things a computer can do. At the one operation per instruction level, all those tasks have a probability proportional to their number of operations, given a random program. HLLs, however, group implementation tasks (moving data from memory to a register and back, adding data from one register to another, comparing the contents of two registers, etc.) into logical tasks (square roots, screen repaints, file output), where one instruction means many operations. Hence, a random program will achieve more complex tasks - the probability of any given task occuring will depend upon what sets of operations the HLL generates with one line of code verses multiple lines of code. This means different HLLs will tend to generate programs in different volumes within the total universe of possible programs. This translates into different types of programs being easier to conceive and implement in different languages.
I mean, really: who writes device drivers in VB? Who writes word processors in assembly?
Reality has a conservative bias: it conserves mass, energy, momentum...
The Lisp and C styles are based on expressions to be evaluated. Their natural mode is to operate on multiple input values to produce a single output value. Workarounds, to handle multiple outputs, always feel clumsy, and generally require creating more named temporary variables. Furthermore, people naturally have a bias towards this preference, and consider it poor style to modify the machine state mid-expression (regardless of how efficient this is), preferring only to assign the result.
The Forth style is different. Each token is an instruction to be executed in strict order, and performs its function by modifying the machine state in some way. You don't tell the machine, "I want you to find the answer to this problem," you tell it "do this, then that, next this," and in this way you get to know exactly what it's doing. "Returning" multiple values, or making multiple changes to the machine state, is easy and natural. You don't have to put in silly kludges where your return result is a proper answer in some cases and an error code in others, or resort to the absurd COMEFROM of exception handling. There is no limiting syntax to trip over, your own constructs can be as expressive as the ones that are built in.
You don't need to understand algebra to learn Forth. As Chuck Moore says, it should be taught some time after counting and before long division.
In short, Forth is the truly general purpose programming style. It's based on the way computers really work, not some idealized model of how we'd like computers to work. This makes some things a little harder, and makes some things much, much easier.
That said, I don't use Forth much. Everybody uses C, or C-based tools. All the system interfaces are designed and documented for C programmers, and if you want to use them, you have to deal with the workarounds for C's shortcomings regardless of what you actually use. Since interfacing with system libraries is often the biggest and most painful part of a project, this negates the advantage of moving to Forth. Even the processors are designed for C code. Stack machines aren't any less efficient than register machines, but by the time you take advantage of a large register file, your beautifully-simple Forth compiler/interpreter is as monstrous as a C compiler.
Compromise systems, such as ANS Forth, neatly combine the disadvantages of C with the disadvantages of Forth.
And so, Forth ends up restricted to situations where you'd have to build up the kruft yourself if you wanted to use C. Still, I want a T-shirt that says, "I'd rather be programming in Forth!"
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 used to work for a company that deals with real time equity market data web sites: all runs on a custom Forth back end and web application server. CNBC ran on Forth for a year. Fortune Investor, Citibank, American Expresss -- all ran on Forth. www.wallstreetcity.com -- still running on Forth. Reason
All computer languages rehash the same concepts:
# set/read variables
# conditional, branching and looping constructs
# call functions
1. Most functional languages don't include the concept of setting a variable; reading a variable is also very different from Algol-like languages. Forth isn't functional, but doesn't have much use for variables; the closest thing it provides is essentially direct memory access.
2. Many languages truly do no more than imitate what Fortran finally discovered so many years ago -- but there are also many more which go much, much further, starting with the simple concept of recursion and stretching onward to continuations and preemption. Although anything we know now can be implemented through continuations and preemption, many languages automate some smaller and easier to work with (or optimise) subset, such as Icon, Sather, or J/K/APL. Forth has some really interesting things to contribute here, thanks to the fact that a 'continuation' in Forth is just a single pointer.
3. Finally, you imply that all languages call functions in the same way. You probably only know language which work in the same way; but there's more out there. Consider the differences between the parameter passing styles: C is applicative, Haskell is curried, J is combinatoral and Forth is concatenative. In other words, C depends on lambda theory; Haskell depends on curried lambdas; J depends on dataflow around functions; and Forth depends on dataflow within a stack passed and returned from composed functions. Most modern languages are lambda-based, so more like C; a few are starting to become curried, since that's a very simple change which gives a lot of power and flexibility in parsing.
So no, language can't simply be swapped without regard.
-Billy
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
In many ways Charles Moore is a seriously twisted genius. I have always rooted for him, despite the fact I prefer to use a cleaner, more readable language.
Amen to that. A lot of Chuck's work, especially his new ColorForth, borders on the bizarre, but it's never drooling-in-the-corner bizarre -- it's always mad genius bizarre.
That being said, Forth is a lot of fun to work with even if you never do anything remotely useful with it. The underlying dynamics of a Forth environment are simple enough that you can roll your own very quickly, which is not something you're going to do with C or C++ or Java. Ultimately, that's what probably kept Forth from becoming more popular: the temptation to create new Forth-like languages was easily satisfied by Forth programmers. Case in point, of course, is Chuck Moore himself, who apparently despises the standard version of Forth and who has never stuck with one version of the language for very long.
Using Forth and building your own Forth environment is still a fascinating way to gain insight into interpreters and virtual machines, and the kind of thinking required for using Forth well is quite an enjoyable exercise. If you do want to use Forth for "real" work, it is worth bearing in mind that some very complex systems have been built very, very quickly by seasoned Forth programmers -- including air traffic control systems -- and the mode of bottom-up programming used in Forth basically ensures continuous unit testing, so Forth programs tend to require less debugging late in the development process.
Proud member of the Weirdo-American community.
I think I had the same cartridge. Why would anyone want to use a write-only programming language today? Why not use APL while your at it?
Seriously, Forth had solid advantages when RAM and processor cycles were at a premium. But these days few people have to develop for a 4k environment.
Clear, Dark Skies
So, uh, does anyone have a Fourth "Hello World" program yet?
Preferably one that has email built into it.
I really hate Dan Patrick.
ah, MOPS was beautiful. a few bugs here and there, but any language that is free and comes with all of its source - so that you spend hours trying to work out just how it does something - is a joy.
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.
Yes, I had NEON running on my Mac SE 'way back then. It was a cool implementation, but the drawback (as with everything Mac) was the learning curve of the Mac architecture.
Still, I have the Brodie book and even published an article in Forth Journal. The elegance of the language is amazing. I like the way that you don't so much program, as extend the compiler to include new words for what you want to do. Eventually, the compiler is so close to your problem domain that a few words in this new language will solve your problem.
I miss it.
Actually, it is java.
And it was a mistake to post it.
I was having trouble posting, due to DNS propagation times due to the slashdot move, and had saved my post on the clipboard. I decided to try again, pasted it and hit submit. Oops... I had snatched some Java onto the clipboard by mistake.
Oh well, at least it wasn't my bank account number and PIN or something!
The only good weather is bad weather.
The best Stupid Forth Trick I ever learned was changing the number based from octal, decimal or hex to an arbitrary number like 128 or 256 (decimal).
Every single printable ASCII character becomes a number. Any language that allows you to define cntrl-G as a valid number you can compute with has to be on a hackers list of all-time favourites.
Of course, changing it back again may be a bit of a challenge. For some reason, all my compiled words keep ending up on the stack...
-- clvrmnky
All n-complete languages will share certain similarities in how they handle discrete requirements. How the entire language is used to express solutions to problems will not be the same in all cases. This is probably what most of us respond to when we say we do or do not like a particular language for a given solution (or at all).
A more accurate test would be writing a solution that toggles a bunch of motors on, off and changes direction and speed in any arbitrary combination. Another good test is a word processor or desktop publishing app.
Is your solution expressed well in the language? Does it allow you to build upon previous work? Can you abstract the various small problems well enough to decompose them into small easily tested chunks?
One of the best parts of real-world FORTH is the ability to incrementally build your app, and to build unit-testing and full test-harnesses right into an application. Once the product is shipped, these can be left in (or not, depending on how you want it) with almost no impact on overall performance.
Note that I am not saying this cannot be done in other languages, only that FORTH makes it trivial to develop these handy tools right alongside your regular development activities.
-- clvrmnky
Someone did :)
-- clvrmnky
Paradoxically enough, that is true. While Forth is a completely unsafe, ridiculously simple to implement, machine near-language, Common Lisp is a big and complex language, trying to abstract away from the underlying machine as much as possible. Yet, they share this unique strength together, although in very different ways.
It was fun. But RPN is not a way to run a whelk stall.
I disagree wholeheartedly. While it's true that very many languages don't differ in anything but syntax (e.g. C, Pascal), the interesting differences are the semantic ones (e.g. C++, Prolog, Scheme, Forth, ML, Haskell, Mozart, Perl, M4, Icon). While many features superficially look the same, the meaning of two programs with similar-looking syntax or structure can be radically different. Syntax matters little beyond the initiall "sell".
But I really haven't seen a new concept in computer languages in 20 years.
Interesting. I find new interesting concepts in new languages every day. But I haven't been here for 20 years, and to some degree I believe what you are saying (if you are talking of major new concepts!). Few of the languages on the list above are very young. On the other hand, I guess template metaprogramming and constraint programming are both pretty new.
Forth and Postscript share that both use RPN (reverse polish notation), and as a consequence have some similarities for stack manipulation. So do HP calculators and the Java virtual machine. Beyond that, however, the languages couldn't be more different. Forth is a low-level language with no runtime safety and no dynamic typing. Postscript is a dynamically typed language with garbage collection. Except for the use of RPN notation, Postscript is really closer to languages like Lisp.
But that is probably its main virtue. Once you move development "off board" and use a batch compiler, you might as well use a compiler (C, Modula-2, etc.).
I wrote a decompiler that produced compilable Forth code from competitor's ROMs (and we had loads of laughs looking at their inept examples of programming, such as "1 = if 1 else 0 endif" which basically did nothing at all), and I also managed to squeeze in a 4K bytes ROM an insurance rate table with 10,000 integer entries (the second derivative did fit in three bits or something silly like that).
Forth is used as the backend scripting language for the 3D animation software Realsoft 3D. Realsoft also also happens to be my favorite dark horse candidate in the highly competitive 3D animation marketplace, notable because it runs on Linux.
When you think about it, a low level language like Forth is ideal for such an application. Realsoft strives for realtime OpenGL animation playback, with physically correct simulation, particles, deformation hierarchies and tons of geometry thrown at the screen. Forth is fast enough to solve custom animation expressions without getting in the way.
I'm sorry but I have a lot of trouble with FedEx being cited as the second "credible" company on this list. I know for a fact that FedEx's call centers are running programs written in FoxPro on DOS. Does that make FoxPro a great language? Even the author of the program (who wrote it in college in his free time while working there) would wouldn't agree to that, despite the fact that they're still paying him to support an app that they refuse to pay the money necessary to replace.
I also know that FedEx still has huge monolithic apps written in COBOL on IBM mainframes, since I get nice descriptions of them from my professor on Monday and Wednesday nights (he works there during the day). COBOL, people, COBOL.
I'll make a blanket statement as a Memphian who knows entirely too many people who are either employed by the company or serve as vendors to it: FedEx is a big slow giant that made a lot of decisions in a hurry that it doesn't want to pay to take back. For example, they just built a nice new world headquarters that consists of some of the most modern buildings in this part of the country (ok, not saying a _whole_ lot, but still) and what do they furnish them with? Yup, the furniture they bought in the '70s and '80s.
So when someone says "FedEx uses ____" I tend to ignore that fact and move on. Not every decision they've made is bad, but very few have anything to do with the technical merits of the choices given.
For these situations its more of an issue of scalability. COBOL scales well on a single machine. But when you're running the biggest box IBM makes and you're barely able to keep up (IE, you have 24 hours to work in and you're using all of them) you're running into problems. Also the fact that it wasn't designed in an object oriented manner causes issues, because when they change any piece of code they have to retest the entire program.
Have you worked in the software industry or are you just talking out of a random orifice? I won't argue with COBOL as a language (I've used worse), but more as an environment for solving large scale business problems.
My argument was not against COBOL, but FedEx for using antiquated practices that risk not solving their problems reliably to save a few bucks here or there in the short term, ignoring the long term repercussions of their actions.
For example, if they had bit the bullet and bought new furniture 5-10 years ago, they would have saved money. They are paying a lot more to refurbish their old furniture than they would invested in new furniture that would not require work today. I know this because I used to do tech support at the company that sold and refurbished the furniture.
Or take my friend's application. FedEx put out a bid for new software. My friend and other companies put their proposals out on the table. Sure, some of the solutions were terrible (required private hard networks across the country, etc.) I saw well designed, light weight, easy to manage proposals. Would have required an initial investment, but would have saved a fortune in support costs over the long term. But because of political issues, etc. they stuck with what they had. Then again, I'm happy about that one because my friend can sit happy for the next few years, despite any economic problems elsewhere in the industry.
For those of you here who own a Mac and want to experiment with a little bit of Forth, there's a built in Forth interpreter in the Mac Chipset (also on some SUN machines). OpenFirmware, the Mac Firmware engine, uses forth and you can do some command line dicking with the stacks etc by pressing Command-Option-O-F at boot, which will take you into the Forth commandline environment.
Have fun and be careful because you can seriously damage your Mac with some careless forth scripts.