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 jack@ganssle.com His website is www.ganssle.com.
Reader Feedback:
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 words
is ok in a serious writing,
> Suppose your average function is 50 lines of code.
This is too much for any language. The word "average" means
that some functions are *many* times longer.
For good Forth the average size of a word is 7 words inside
a 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 that
Forth keeps comments in the target memory. BTW, he does not
state 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 of
such articles is anti-education.
You see, Forth is exotic, in the same way as UK pound is an exotic
currency. Forth sort of has an ANSI/ISO standard, and UK pound
is sort of hard currency. But ask anybody at any exchange office
outside UK what 25 pounds banknote looks like, and in at least 95%
of cases you will find out that they have never seen one.
Michael Gassanenko
I'm using Forth for 11 years for DOS/Windows (financial and internet
software) and embedded development. Before that I few years used C/C++,
Pascal, Assembler, Lisp, Smalltalk. I select Forth, because it gives me
possibility to do my work quickly, so less expensive for customers. And it
makes strong code... Forth code don't need to be extensively documented,
because it is self-documented. Where you've seen "50-lines function"? Most
of Forth functions - 1-2 lines. It is impossible to make an error in such
function, so coding is highly modular, reliable, stable and reusable.
Forth code reliability is enough for writing high-performance internet
servers. 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 Forth
language. You can see source code of our Forth web-server at
http://acweb.sourceforge.net/. It is written using SP-Forth (it also open source).
[Sorry for my poor English].
Andrey Cherezov
Software Engineer
Delosoft.com
Jack,
Anyone who claims that: "a well-designed, carefully coded system should
consume no more than 20% of the schedule in debug" hasn't worked in the
real-world for quite some time. This is buffoonery! A more realistic
value 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. The
interactive value of a TIL (thread interpretive language) should NEVER be
diminished - for both coding and debugging. And that's what gives Forth
it's advantage over: C/C++, Ada, and their ilk. As far as Java is
concerned, I'm afraid the overhead of the JVM is simply prohibitive.
John
Title: Senior Software Engineer
Company: AT&T
FORTH SUCKS? C sucks, C++ sucks, Assembler sucks, Fortran sucks, Ada
sucks, JAVA sucks, Perl sucks, Ruby sucks, for the same reasons. It's the
designer/programmer not the tool that makes the difference. I thought
this article was an interesting approach to finding out just how much
FORTH hasn't fallen by the wayside like Pascal.
Chuck Esserine
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 for
everyone.
I use Forth for embedded applications, as well as under Windows/DOS on a PC.
Regards,
Howerd
Howerd Oakford
Managing Director
Inventio Software Ltd
As a software developer for the past decade, I have coded in a wide
variety of languages. I've seen and worked on a lot of code written by
others. The issues raised by this article are not unique to Forth. Any
programmer can undocumented code which is difficult to understand. Any
programmer can write well-documented code which is easy to understand. I
find badly written Forth code to be no more or less readable than badly
written C or Perl code. The problem isn't the tool, but is how the tools
are used. I've developed a number of PalmOS applications in Forth lately,
and other than getting re-accustomed to the stack-based way of doing
things that I used to use on my HP-48, I've not found the adjustment to be
a difficult one. I do comment my code, extensively, and that's a good
thing no matter what language one uses.
Another poster in this thread wrote that Forth "instills bad design from
the very onset of a project that tends to follow it till it's slow painful
death". In my experience, if you have a bad design, it doesn't matter what
tools you implement it with. If you're willing to take the time, you can
write well-designed software in most any language.
Tamara Cravit
Partner
Taylored Software
"Forth sucks?" Is that what passes for thoughtful analysis these
days? (sigh)
Maybe it would be useful to look at the objections to Forth that prompted
such 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 came
from. 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't
typically as freely shared, regardless of source language, and I suspect
Jack 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 computer
language ever used which doesn't have "passionate devotees?" Assembly
language, C++, Java, and even Visual Basic each have their "passionate
devotees" but is that really a reason for more objective people to reject
the programming language? After all, "any language is just a tool." The
last "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 more
than C sucks or assembly language sucks or programming sucks. Maybe Jack
needs to retire or just go fishing for a while, if things seem to
"suck." After all, it's just a tool, right?
Ed Beroset
Firmware Manager
ABB Automation
We find Forth quite useful for initializing new hardware, diagnostics, and
as an interactive debugging environment requiring comparatively few
hardware resources. As suggested by OpenBoot's Mitch Bradley, politically
Forth is tougher to sell than to actually use. Some posotive and negative
Forth observations came up in a recent Embedded Systems Conference panel
discussion on programming languages where the consensus had suitable
applications for Forth, Basic, and Assembly language-but no one owned up
to any "silver bullet."
Curiously, seasoned developers spoke most highly of (now rarely
used)Pascal and Ada when considering the complete life cycle of an
embedded systems product. Regarding combinations of code and
documentation, a fair amount of research centers on "literate programming"
ranging from Donald Knuth to Forth(Peter Knagge). UML seems an extension
of Object Oriented Design where Class Diagrams and State Charts (Bubble
Diagrams) provide design documentation that a tool like the Visual Studio
Class Editor or iLogix Rhaphsody translates to source code. IMO high level
designs are not the same as documentation for source code.
Wil Blake
President
Embedded & Mobile Systems Inc.
The author simply does NOT understand Forth!
Graham Smith
Programmer
If you give someone a length of rope and they hang themselves with it, you
can 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 systems
applications, you just can't beat it.
Steven R. Commer
Senior Systems Analyst
Debitek
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
President
FORTH, Inc.
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.
Michael Losh
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.
David Graham
President
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.
Bob Applegate
Senior Software Engineer
Ulticom, Inc.
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.
Don Warbritton
Software Engineer
Ametek/Dixson
What means "sucks"? (my English is not that good).
In dictionaries I did not find
a 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 should
be used by embedded professionals in bringing up a system. I spend
much of my time debugging first silicon and first platforms and whenever
I 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 assembler
for quickly porting code bases between different processors. C++ and now
Java are excellent for high quality applications work. In my opinion productive
embedded professionals should use the best tool for the particular task at
hand so that the project gets completed on time and under budget and not
view any computer language tool with religious zeal. They are just tools, akin
to hammers and screwdrivers.
For the last two years I've tried to get those around me to look seriously at
and to begin using UML from iLogic for more of the new code that needs to
be written. The notion of producing working code from documentation has
always been attractive.
I use Assembler's, Forth, c, c++ for embedded, and I've not had the opportunity
yet to use Java or UML. I also don't have a degree and found that article of
your'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 should
be 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 by
Forth then unix takes over the box. When the hardware breaks then there is
an interactive and programmable operating system running on the platform
that can be used to debug the hardware. The embedded envirnment isn't
much different.
Thanks for the thought provoking articles. :-)
Dennis R. Miller
Philips Semiconductors
Debug on the fly and no documentation - sounds like something the Extreme Programming advocates would love!
Tom Mazowiesky
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.
Troy Flowers
Staff Engineer
Iconn Wireless
I coded Forth several years ago. It reminded me of APL.
Where's Forth being used today???
Robert(Bob) E. Cronan
Diagnostic Engineer
RiverDelta Network
