Forth sucks. I know that statement is going to churn up a lot of hate mail. Forth's advocates are as passionate about their baby as Windows-haters are about Microsoft. I've never seen a language that has such passionate devotees, astonishing when you remember we're only talking about a computer lingo.
Forth is a very satisfying environment for a programmer. It's totally interactive. The interpreter – which is generally quite small – lives in your target system. It's a bit like working with old-time Basic – change something and immediately test the new code. There's no compile, link or download. Adherents crow about how productive they are working with a tool like this that imposes no delays on their work.
Sure, it's fast. And fun. But let's get real: interactive development has no impact on requirements analysis, specification, software design, documentation, or even test. Fast tools make for fast debugging, nothing else.
How much time do we spend debugging: 80% of the project? I sure hope not. A well-designed, carefully coded system should consume no more than 20% of the schedule in debug. Healthy software organizations need less.
How many changes will you make to the code per day? Hundreds? If so, the system is neither carefully designed nor coded.
Forth lets us build code incrementally. Write a “word” (the Forth-ism for a function) and run it. Work out the bugs and move on to the next one. This is the very model of a modern development strategy, at least as promulgated by some gurus. But, again, how much time do we really save? Suppose your average function is 50 lines of code. Averaged over the long haul few developers write more than 50-100 lines of code per day, a couple of functions. Most create considerably less when you factor in all of the real aspects of engineering – meetings, breaks, working with colleagues, etc. Forth's intrinsic, and admittedly very cool, interactivity only pays off by saving us a couple of compile/downloads per day. Minutes, max. This presupposes, of course, that we design the function rather than having it haphazardly grow via sufficient pounding of the keyboard.
Forth's interactive nature tends to obliterate documentation. Where do those comments go when (if) you enter them? Down to the target, of course, into the limited memory typical of resource-poor embedded systems. That's the nature of interpreters. Worse, even the best people tend to get sucked into a change/test frenzy using any interpreter (Forth, Basic, you name it). Documentation slows us down when we really just want to try something, so is inevitably neglected.
It is possible to have well documented Forth. But that's very rare. I've looked at a lot of Forth code, and it's almost uniformly doc-free.
Forth is also a write-only language. The language is simple with few keywords. Developers essentially extend it by writing the “words” which each do more complex things, each of which then become inherent language keywords. We're sort of extending the language as we write our program. Though there's a strong parallel to C's use of functions, somehow the average Forth program becomes much more quickly a mess of cryptic definitions only the original programmer understands.
There is no better environment for figuring out hardware, though. When we're confronted with a peripheral with 50 programmable registers, most probably poorly documented, we've got no choice but to sit down and play with the device. Though it's possible to use any debugger to issue specific port input/output commands, Forth shines as we can try something simple and then enshrine it as a “word”, which gets reused as we learn more about the device.
But any language is just a tool. Sure, use Forth for hacking the hardware. Then discard it and pick a more appropriate tool for crafting maintainable and efficient code.
Jack G. Ganssle is a lecturer and consultant on embedded development issues. He conducts seminars on embedded systems and helps companies with their embedded challenges. He founded two companies specializing in embedded systems. Contact him at His website is .
Well, now when this all is over, I want to tell you that thisarticle definitely was a joke. IMO.
Even if we suppose that the use of crude wordsis ok in a serious writing,
> Suppose your average function is 50 lines of code.
This is too much for any language. The word “average” meansthat some functions are *many* times longer.For good Forth the average size of a word is 7 words insidea definition (and punctuation marks also count as “words”).
> no more than 20% of the schedule in debug.> Healthy software organizations need less.
> … when you factor in all of the real aspects of> engineering – meetings, breaks, …
Probably this is the best place.Indeed, the more people are involved in the project,the less efficient each one's work is.
Most Forth companies are not so big (BTW, this is what “healthy”means), and people are not paid for breaks there. 🙂
And BTW when the project is over, its meetings (and breaks)stop as well.
> Where do those comments go when (if) you enter them?> Down to the target, of course, into the limited memory> typical of resource-poor embedded systems.
I cannot believe that the author really believes thatForth keeps comments in the target memory. BTW, he does notstate that explicitly.
But why people did not take this article as a joke?Because one has to know Forth to understand this joke.Given that most people do not know Forth, distribution ofsuch articles is anti-education.
You see, Forth is exotic, in the same way as UK pound is an exoticcurrency. Forth sort of has an ANSI/ISO standard, and UK poundis sort of hard currency. But ask anybody at any exchange officeoutside UK what 25 pounds banknote looks like, and in at least 95%of cases you will find out that they have never seen one.
I'm using Forth for 11 years for DOS/Windows (financial and internetsoftware) and embedded development. Before that I few years used C/C++,Pascal, Assembler, Lisp, Smalltalk. I select Forth, because it gives mepossibility to do my work quickly, so less expensive for customers. And itmakes strong code… Forth code don't need to be extensively documented,because it is self-documented. Where you've seen “50-lines function”? Mostof Forth functions – 1-2 lines. It is impossible to make an error in suchfunction, so coding is highly modular, reliable, stable and reusable.Forth code reliability is enough for writing high-performance internetservers. For example, some our web-servers (www.forth.org.ru,www.eserv.ru, www.etype.net) are “powered by Forth”, i.e. web-servers,ftp-servers and mail-servers on these computers are written in Forthlanguage. You can see source code of our Forth web-server athttp://acweb.sourceforge.net/. It is written using SP-Forth (it also open source).
[Sorry for my poor English].
Anyone who claims that: “a well-designed, carefully coded system shouldconsume no more than 20% of the schedule in debug” hasn't worked in thereal-world for quite some time. This is buffoonery! A more realisticvalue would be about 50%. Remember, you're NEVER simply debugging code -you debugging requirements and design, as well as code!
As far as Forth is concerned, I've used it and would use it again. Theinteractive value of a TIL (thread interpretive language) should NEVER bediminished – for both coding and debugging. And that's what gives Forthit's advantage over: C/C++, Ada, and their ilk. As far as Java isconcerned, I'm afraid the overhead of the JVM is simply prohibitive.
Title: Senior Software Engineer
FORTH SUCKS? C sucks, C++ sucks, Assembler sucks, Fortran sucks, Adasucks, JAVA sucks, Perl sucks, Ruby sucks, for the same reasons. It's thedesigner/programmer not the tool that makes the difference. I thoughtthis article was an interesting approach to finding out just how muchFORTH hasn't fallen by the wayside like Pascal.
Company: IFR Systems
Forth does not “suck”. It is my language of choice because :
- I can get programs working quickly
- I can get hardware debugged easily
- I can express concepts succinctly
- I can understand other peoples ideas easily.
I do not understand why some people don't like Forth – perhaps its not foreveryone.I use Forth for embedded applications, as well as under Windows/DOS on a PC.
Inventio Software Ltd
As a software developer for the past decade, I have coded in a widevariety of languages. I've seen and worked on a lot of code written byothers. The issues raised by this article are not unique to Forth. Anyprogrammer can undocumented code which is difficult to understand. Anyprogrammer can write well-documented code which is easy to understand. Ifind badly written Forth code to be no more or less readable than badlywritten C or Perl code. The problem isn't the tool, but is how the toolsare used. I've developed a number of PalmOS applications in Forth lately,and other than getting re-accustomed to the stack-based way of doingthings that I used to use on my HP-48, I've not found the adjustment to bea difficult one. I do comment my code, extensively, and that's a goodthing no matter what language one uses.
Another poster in this thread wrote that Forth “instills bad design fromthe very onset of a project that tends to follow it till it's slow painfuldeath”. In my experience, if you have a bad design, it doesn't matter whattools you implement it with. If you're willing to take the time, you canwrite well-designed software in most any language.
“Forth sucks?” Is that what passes for thoughtful analysis thesedays? (sigh)
Maybe it would be useful to look at the objections to Forth that promptedsuch a strong response:
1. Forth has “passionate devotees.”2. Forth speeds debugging (but not other phases of development).3. Forth comments use up target memory space.4. Forth code Jack has looked at is often undocumented.5. Forth is unsurpassed for figuring out hardware.
Comment number 3 is just plain false. I'm not sure where that notion camefrom. Comment number 4 is true of *most* code I've seen on the internet,and doesn't seem to be specific to Forth. Production quality code isn'ttypically as freely shared, regardless of source language, and I suspectJack just hasn't looked at any production Forth code. As for 1 and 2,they aren't really specific to Forth either. Is there any computerlanguage ever used which doesn't have “passionate devotees?” Assemblylanguage, C++, Java, and even Visual Basic each have their “passionatedevotees” but is that really a reason for more objective people to rejectthe programming language? After all, “any language is just a tool.” Thelast “objection” of course isn't an objection but a reason that one would*want* to use Forth.
On balance, it's hard to see why one would conclude Forth “sucks” any morethan C sucks or assembly language sucks or programming sucks. Maybe Jackneeds to retire or just go fishing for a while, if things seem to”suck.” After all, it's just a tool, right?
We find Forth quite useful for initializing new hardware, diagnostics, andas an interactive debugging environment requiring comparatively fewhardware resources. As suggested by OpenBoot's Mitch Bradley, politicallyForth is tougher to sell than to actually use. Some posotive and negativeForth observations came up in a recent Embedded Systems Conference paneldiscussion on programming languages where the consensus had suitableapplications for Forth, Basic, and Assembly language-but no one owned upto any “silver bullet.”
Curiously, seasoned developers spoke most highly of (now rarelyused)Pascal and Ada when considering the complete life cycle of anembedded systems product. Regarding combinations of code anddocumentation, a fair amount of research centers on “literate programming”ranging from Donald Knuth to Forth(Peter Knagge). UML seems an extensionof Object Oriented Design where Class Diagrams and State Charts (BubbleDiagrams) provide design documentation that a tool like the Visual StudioClass Editor or iLogix Rhaphsody translates to source code. IMO high leveldesigns are not the same as documentation for source code.
Embedded & Mobile Systems Inc.
The author simply does NOT understand Forth!
If you give someone a length of rope and they hang themselves with it, youcan hardly blame the rope. If someone's Forth code is unreadable,ineloquent or unstructured, the fault is theirs–not Forth's.
I've been programming in Forth for 17 years. For embedded systemsapplications, you just can't beat it.
Steven R. Commer
Senior Systems Analyst
Whether you like Forth or not, you should at least get your technical facts straight before misleading your readers. A few factual corrections:
* Although some Forths include a target-resident interpreter, most modern Forth development systems for embedded targets are cross-compilers that use a few hundred bytes in the target to provide the interactive testing environment that we love. The host system (normally a PC) can provide a powerful development environment with an optimizing compiler, full assembler, and extensive debugging aids in additional to Forth's natural interactivity.
* Forth encourages source comments, and most systems I know are extensively commented. I never heard of a Forth that put any trace of comments in the compiled code!
* Although Forth has a very simple set of rules (virtually no syntax, parentheses, precedence, etc.), its command set is quite rich: there are over 350 words in the ANSI Forth required wordset, plus several hundred optional words, so an engineer has a strong basis to start from. Naming conventions are flexible, and can lead to extremely readable code. Although Forth looks strange to people who don't know the language, Forth professionals can read each others' code with ease. We maintain complex applications written by others regularly, as do our customers.
I do agree with your statement, “interactive development has no impact on requirements analysis, specification, software design, documentation, or even test.” Responsible project managers insist on all the phases, when using Forth as with any other language. But Forth does tend to bring code in the picture early, as it's often easier to model design ideas in code and try things, so the early phases are facilitated by “successive prototyping.” And the coding and debugging phases can be shortened by weeks or even months.
Please let me know when you'll be in Southern California, and I'll be happy to show you what modern Forths look like.
Elizabeth D. Rather
I'm a 7-year or so reader of your columns in ESP. I usually flip to the back of each issue as soon as I get it and read your stuff first. Please keep up your great articles! But I want to speak out on your critique of Forth.
Forth's advocates are not just passionate about the “lingo” of Forth. Forth advocates are also advocates for a very incremental, iterative development process that spans from analysis to design to development to testing. It appears that Forth's inventor, Chuck Moore, desired to have one tool that could span all phases of development. Switching from an analysis language to a design language to development language to a test scripting language to an operating script/control language is inefficient and error prone! (If you don't like my use of 'language' above, substitute 'tool'.) When used carefully, Forth can address all these uses.
It is true that Forth does not enforce much discipline. But a competent and reasonably disciplined software engineer can write very readable, maintainable code in Forth. It takes some practice, just as with any collection of tools.
I don't know what prompted you to stir up the Forth “wasp's nest,” but I am disappointed that you, an author I have respect greatly, seem to be taking a cheap shot at Forth and its users for no reason other than some people use it badly.
By the way, I am quite familar with C/C++ (I was an MS-certified instructor until recently) and have written much code C as well as Forth.
Vice President, Core Technology
American Systems Technology, Inc.
Your arguments against Forth sound like you are concerned that its interactive convenience allows programmers to be lazy. Maybe we should not be allowed to have upholstered chairs either.
Your assertion that there is no better environment for figuring out hardware reassures me that I would gain little from becoming proficient in C. I am an embedded software contractor and have programmed with Forth for over 10 years, writing 3 or 4 applications a year, each with 20-30K bytes of compiled code. Since every project involves a signicant investment of time in figuring out hardware, it sounds like I am already using the best tool for the job. I have learned enough C to translate example C code into Forth a few times, and each time the Forth compiled code has required less code space, so I am not sure why you disparage Forth's efficiency. No Forth I have ever used compiles comments.
Graham Automation, Inc.
Your comments were pretty funny. Yeah, I played with FORTH back in the mid 80s, but eventually dumped it due to the lack of comments. At the time, FORTH also had that atrocious “blocks” concept instead of real I/O, although my Forth-fanatic friends tried to convince me blocks were far better than files. I understand this has since be changed… good!
Let's face it, the worst part is plain unreadable code. No matter how “nice” people tried to make it, the code looked like a jumble of random characters. If I look at most languages I don't know, I can pick up the flow of the program and figure out what a lot of it does. Not forth. Then again, this could be due to the lack of comments.
Should Forth be wiped from the planet? NO WAY! I've played with it many times since going C, and it's still a great language to study. However, it's not my language of choice.
Senior Software Engineer
Jack – You forgot to mention that Forth also saves the cost of a debugger. I currently have a $4000 MMDS from Motorola and a $9000 Hitachi emulator on my desk.
So Forth eliminates expensive emulators, and simplifies test of hardware and software.
What it doesn't do is force you to write well documented, structured code. I'm afraid this argument suffers from a small flaw. “C”, the most popular embedded software language also does not force you to write well documented, structured code. As one who has to work on code written by others, I am much more comfortable working on “Programmer A's” assembly code than “Programmer B's” C code. The quality of the code is not dependent on the language used, but, outside of a well defined process, is dependent entirely on the quality of the programmer.
I wouldn't force anyone to use Forth. An important factor in choosing a High Level Language (HLL) is maintainability. It can be bad enough learning the tricks of the different flavors of any HLL from different vendors, or for different processors, there's no need to throw in a new language too. And Forth is not supported by enough vendors to cover all applications.I could argue more on the merits of Forth, but like the Apple Macintosh, or UNIX,the marketplace has decided that “C” is the HLL of choice, and the embedded systems market is apparently not big enough to support multiple languages. Like the Mac, Forth may be best for those who work by themselves on a small number of products.
What means “sucks”? (my English is not that good).
In dictionaries I did not finda satisfying translation.
Jack Responds: It's a crude way of saying “It's awful”.
It's just a computer language, and one of many tools that can and shouldbe used by embedded professionals in bringing up a system. I spendmuch of my time debugging first silicon and first platforms and wheneverI use the Forth language/OS for this task it always gets done faster. Sure,c is the language of choice by most and it is an excellent portable assemblerfor quickly porting code bases between different processors. C++ and nowJava are excellent for high quality applications work. In my opinion productiveembedded professionals should use the best tool for the particular task athand so that the project gets completed on time and under budget and notview any computer language tool with religious zeal. They are just tools, akinto hammers and screwdrivers.
For the last two years I've tried to get those around me to look seriously atand to begin using UML from iLogic for more of the new code that needs tobe written. The notion of producing working code from documentation hasalways been attractive.
I use Assembler's, Forth, c, c++ for embedded, and I've not had the opportunityyet to use Java or UML. I also don't have a degree and found that article ofyour's to be a breath of fresh air on the sheep skin subject.
Your article on Forth pretty much hit the nail on the head on how Forth shouldbe used, which is why all of Sun Microelectronics unix boxes use Forth to boot,in the form of OpenBoot. When all of the hardware is working and verified byForth then unix takes over the box. When the hardware breaks then there isan interactive and programmable operating system running on the platformthat can be used to debug the hardware. The embedded envirnment isn'tmuch different.
Thanks for the thought provoking articles. 🙂
Dennis R. Miller
Debug on the fly and no documentation – sounds like something the Extreme Programming advocates would love!
Director, Software Applications
Global Payment Technologies, Inc.
Hear! Hear! I couldn't agree with you MORE. When I was a student I worked for a couple of reseachers at S.I.O here in San Diego and I all heard from then were the virtues of Forth. Being a student trying to start a career in embedded systems I tended to belive what the older more experienced people told me. Phooey! Now I'm the guy who calls the shots and Forth is way down in my arsenel of tools for all your stated reasons. It instills bad design from the very onset of a project that tends to follow it till it's slow painful death.
I coded Forth several years ago. It reminded me of APL.Where's Forth being used today???
Robert(Bob) E. Cronan