I Hate Forth
I Hate Forth
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 email@example.com His website is www.ganssle.com.
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.
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].
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.
Title: Senior Software Engineer
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.
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.
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.
"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?
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.
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, 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
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 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
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