Over half of the emails I've received strongly disagreed with my stance. Some corrected factual errors (thanks for the information!); others suggested I don't know what I'm talking about. Some very smart people made some very interesting comments, which I won't attempt to refute - see the archived feedback and form your own opinion.
Yet the poll results paint a very different picture. Out of over 1,300 responses, a mere 3% of readers use Forth.
Some people suggested that Forth fits the ideal of eXtreme Programming, as it's highly suited for rapid and interactive development. That's an intriguing concept! But as I wrote in "Firmware without a design," XP, while embodying fascinating ideas, still scares me due to its de-emphasis on design. Most Forth projects I've watched suffer from the same malaise. Not that this is a characteristic of Forth, but the language's very best feature (interactivity) is also its worst, in that it enables such dysfunctional behavior.
Many respondents said that Forth is just a tool, and trashing a tool is pointless. Agreed. As I wrote, Forth is unbeatable for some problems, such as hashing out hardware peculiarities. It's interactive nature lets us make rapid changes in an environment where design might be impossible, since usually hardware docs are incorrect or missing; we have no idea how the damn thing is supposed to work and must reverse engineer the interfaces.
The poll results, though, are quite interesting and surprising. Forth and "other" are equal with 3% response - pretty much in the noise. ADA ranked dead last, with only 2% of the toll. Other, more scientific surveys generally place ADA at 5 to 10% of the embedded space. In one sense ADA is just the opposite of Forth, with a rigidly defined syntax that cannot be extended under pain of losing the ADA imprimatur. Not at all interactive, and a huge and complex beast, many wags feel that once you can convince the compiler to generate an object file the project will work. Between ADA and Forth we have two philosophical extremes, each with more or less the same market share. Fascinating.
C, as usual, was the clear winner, with 68% of the vote. C and C++ taken together represented 85% of the response. Though this is not a real surprise, why is it that developers so overwhelmingly chose these languages? Is it because these two work better for large applications? Twenty years ago most every embedded app was coded in assembly. In this poll assembly would be in the 3% "other" category. Yet 20 years ago a 10k system was huge. Now, as other market surveys show, typical systems are hundreds of thousands of lines of code.
One might suggest though, that ADA is a "better language" for big systems as the compilers are essentially perfect, and the syntactical checks so rigorous that we cannot fall prey to silly mistakes. Does this mean we actually do not pick the most appropriate language for a particular application? My observation has been that, in general, developers use the lingo they are most comfortable with. Most C experts program in C, perhaps slowly migrating to C++ as this force becomes more inevitable. ADA folks (both of them) stay with ADA.
Inertia, comfort level, and very real business issues (it's easier to get C programmers than Java or ADA developers) usually force the language choice.
C++ scored a very odd 17% of the survey. Admittedly, a market researcher would be horrified by the poll, which didn't even allow multiple language choices. Yet the numbers are suggestive. C++ generally scores at 45% of the embedded space, a number I've never been able to believe. There are no C++ compilers for 8 and 16 bit processors, so such a high score means that half of all embedded systems are 32 bits or more, and all use C++. That doesn't hit my credibility button.
I think two forces skew the C++ numbers. The first is that every embedded survey I read clearly has trouble differentiating between embedded desktop applications. A vast number of folks build Visual C++ projects, and there's surely a lot of developers with a foot in both embedded and non-embedded spaces.
A second force is the surveys' inability to separate people using C++ compilers from those writing real, OOPy code. Hey, I just love those "//" comments instead of C's cumbersome slash-star-star-slash. But using a few C++ features does not mean I'm really writing in C++.
So the 17% number returned by our poll strikes me as being very probably correct.
What about Java? A paltry 5% of respondents use it. But it's new(ish), and it lives in only the 32-bit space. Despite exhausting amounts of vendor and magazine hype, Java's popularity (in embedded systems) is about on par with Forth. It's practically a non-contender. To me there's a lot about Java that's appealing (stay tuned for a future column on this), yet the vast majority of us stay in our C/C++ comfort zone.
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:
Language issues are so strongly linked with the compilers. Proponents of Ada argue that the compile time checking increases the chances that your application will work.
This is an immensly valuable feature which is also attributable to Pascal and Occam, both of which I dropped because there are few cost effective high quality compilers available for a wide range of targets. In my group we use C++ on 16 bit micros, and find it very effective. We do however avoid some of the more heavyweight features such as multiple inheritance to help with code maintainance. I have also written a Forth interpreter myself for a DSP, but came to the conclusion that Forth is not appropriate for large applications.
Oliver Sedlacek
System design manager
Bio-Rad Miocroscience Ltd
A few comments about your Forth Followup article.
As a technical clarification, Ada is not an acronym but the name of the first computer programmer Augusta Ada Byron.
The Ada language was developed specifically for large embedded, real-time systems. The syntax of this "huge and complex beast" as you put it was designed to make the source code readable and easily maintainable. It is the first (only?) internationally standardized object oriented programming language. The Ada language was built on the principles of enforcing good software engineering, and it is this last point I believe that sends lesser programmers running back to their "C" code comfort zones. A particularly telling article concerning the effectiveness of embedded programming in "C" versus Ada was written by John McCormick of the University of Northern Iowa. Briefly, he found that in teaching an undergraduate real-time systems course over many years, students' success rate developing control code went from 0% to nearly 50% when the language used was changed from "C" to Ada.
While "C" may have a place in application programming - it is quick to write, everyone knows it, and the compilers are very forgiving - the language soon becomes unsuitable as the size of the application grows. I must agree, and your poll illustrates that, given Ada's design for support of embedded real-time systems, we do not in general pick the most appropriate language for a particular application. The only place C++ should be embedded is in a Windows application.
Personally, I think Ada is the only language ever written designed to reduce programming errors.... what a novel concept! And, the compilers are essentially perfect due to the validation process. Brilliant ideas. Yet for some reason it has almost zero market share in the embedded space. Why?
Karl Woelfer
Software Architect, Embedded Systems
Heartstream Philips
I recently started reading "Extreme Programming Explored" by William Wake. I didn't get very far. As an old Forth programmer who was the "Forth Doctor" at Mountain View Press, I quickly recognized that this great new discovery was just the use of typical Forth programming methods applied to C and made possible by GHz computers that allow rapid write/compile/test cycles that are nearly as fast as Forth development on an Apple II.
I guess these new eXtreme programmers never used Forth and so don't know the heady eXperience of working in a moldable object type language where you have the ability to modify the compiler till it fits the problem.
As far as the slow vanishing of Forth, there are a number of good reasons -- quite a few political within the so-called Forth standards groups. But that is another story, perhaps best titled "How to ruin a company with a language guru."
Note: I have seen some wonderful Forth projects. The great Canon Cat by Jef Raskin and Information Appliance, Inc. crammed a massive amount of code in a small space with a very efficient tokenized Forth.
Today there is a very sweet object oriented Forth called Mops for the PowerPC and Win32Forth Windows. Both are free and available on a server, taygeta.com. The docs and tutorial for Mops are very good and worth reading just to see what the minority is up to. The object model is better and more intuitive than c++ by a long shot.
Charlie Springer
I think a few factors were forgotten in the Forth flap:
(1) Availability -- Is the language available for this micro? If it isn't, forget about it. The company I work for uses the (extinct) National Semiconductor HPC16083. There is an almost-ANSI C compiler, and an assembler. At my previous job, the chief engineer learned on an 8085, so guess what we used? There was assembler. No C, no BASIC, no Forth, no nothing.
(2) Ease of use -- Can I just run the language, and get usable output, or do I need to recompile the source to make it work on my machine, or otherwise fiddle with it? -- We dropped a "more advanced" C compiler because it could not work with code written with the previous version.
(3) How easy is this language to learn? The big problem I have with Forth is that once you get past "DUP-DROP-ROT" and the RPN, you are on your own, basically.
(4) Ease of Application -- I am familiar with Assembler(s), C, BASIC, and Pascal. When I needed a program to monitor RS232 communications, Pascal couldn't do it, and with C I'd need to write the low-level interrupt drivers myself (Not to mention debugging them!). With BASIC, I just OPENed the COM port, and was up and running in less than half a day. However, C is good for writing character-stream filters.
One of the difficulties with Forth is lack of documentation -- not in the code people have written themselves, but documentation that explains what all the words mean. Type in "words" and the vocabulary zooms by on your screen. Try to find out how to (1) Read in a string from the user, (2) Manipulate said string, and (3) Show that string in a specific location on the screen. There are dozens (hundreds?) of books available on C, BASIC, Pascal, all written in a variety of styles and for a variety of audiences. There are very few written about Forth, and how to use it. When I nosed around the Forth sites two weeks ago, there were articles available, but they were almost all written by pros on subjects I'm not interested in. (I'm still trying to find out how to read in that string...).
Another difficulty is interoperability. I can write a program with my favorite editor, and load it into / compile it with C, Pascal, or BASIC. With Forth, I have to struggle to learn someone else's idea (often counter-intuitive) of how an editor (seemingly based on EDLIN or VI) should work.
Oh, well, enough steam.
Rich Ries
Ada - "a huge and complex beast" haven't you even compared the ISO Language Reference Manuals for Ada and C++?!?!?! :-)
Ada95 is positively silph-like and at least you can get compliant compilers for it!
I've also found it that the GNAT compiler at least produces more efficient code than either VS++ or Borland C++ - though these are obviously not the domain your concerned with.
Check out www.cw360.com for their quarterly job surveys and you'll find Ada is doing surprising well over the last year...
Cheers!
Martin Dowie
Lead Software Engineer
Avionic Systems, BAE SYSTEMS, Edinburgh
Jack Replies: Agreed. The very best thing about Ada, IMO, is that it *works*. Compilers must pass quite an exhaustive test to be legit. And, I think that C++ is a huge unwieldy beast. Despite some quite cool features, and the nice things that come with OOP, I think C++ is too complex, too deep. Java's strength is that it offers much of the OOPy stuff in a more useable context. Predictions are tough, but I expect that when Java matures it will seriously eat into C++'s market share..
Ada (named for a lady) is not ADA. I used it extensively on a large project where it significantly reduced integration complexity. First you integrate your interfaces (with package specifications), then you integrate the functionality (adding the package bodies). And it always does what the language standard says it will!
Jack Maynard
Title: staff software architect
ENSCO
Jack Replies: I've always thought that all languages need the same sort of certification that Ada has. Everyone I know has fought compiler bugs with C and C++. That doesn't happen with Ada.
I can't agree with the opinion that new folks will use new Languages The real force is management, because they decide the language choice with arguments like "standard".
For example:
i made a code size comparision
between Eiffel and C++. Although
Eiffel is a real high level language
with garbage collector, the result was
only 20% code size compared to C++.
But instead the winner is Embedded C++,
a completely crippled language
(no multiple inheritance and no
interfaces, no templates, no exceptions)
that also results in 20% code size.
Another example: can you show me any C-Compiler that can generate code to check array boundaries at run time? 30 years old pascal compilers can do so. Do you think this is progress? New folks fresh from university use what they are told it is "standard", and they don't ask questions.
Every sane programmer avoids using C++ if possible. For me this is the only explanation, why nearly all free software is n o t written in C++. But C++ is widely used in commercial products. Why? Ask the management. At the moment everyone wants to have embedded Java. Exactly they want a cheap system with no power, no memory running a java byte code interpreter with java runtime environment and Internet. Do you think they know that they are talking about?
In a few years you will see a lot of embedded java machines, because management wants them. Then all students will learn Java and in ten years java is standard and no one will ask why. If you don't believe me, try to convince your management to use something different than C/C++ or Java. It's all so immature, i have a headache...
Ingo Knopp
A small note: C++ compilers are becoming available for 8- and 16-bit machines, at least the somewaht limited "Embedded C++" variety. Not that anyone is USING them...
I think you overlooked one big force in language choice: what students are taught in the universities. The languages you learn as an undergraduate are probably going to be the languages you use once you get out of university. Learning new languages is quite rare. And what languages are taught? Ada: very rarely. C and C++: all over the place. Java: all over the place.
So the java people have understood the importance of academic mindshare by giving away development tools... and that will pay off in a few years with more programmers familiar with Java being forced to do embedded projects. Good times are coming for vendors of "unnecessarily powerful" hardware.
Fepp
JACK REPLIES: Yeah, I do agree. Languages come into their own when new folks come into the market who have grown up with them. That means we old farts must die before a new language succeeds...