Forth Followup - Embedded.com

Forth Followup

In last week's installment of Break Points,* I raved against the evils of the Forth language. Since then the electronic wires have been fairly humming with pro and con feedback from you, gentle readers.

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 His website is .

*Editor's note: This column originally appeared in The Embedded Pulse (Jack Ganssle's online column, which we have consolidated under Break Points). –10/12/12

Reader Feedback:

Language issues are so strongly linked with the compilers. Proponents ofAda 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 Pascaland 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 programmerAugusta Ada Byron.

The Ada language was developed specifically for large embedded, real-timesystems. The syntax of this “huge and complex beast” as you put it wasdesigned to make the source code readable and easily maintainable. It isthe first (only?) internationally standardized object oriented programminglanguage. The Ada language was built on the principles of enforcing goodsoftware engineering, and it is this last point I believe that sendslesser programmers running back to their “C” code comfort zones. Aparticularly telling article concerning the effectiveness of embeddedprogramming in “C” versus Ada was written by John McCormick of theUniversity of Northern Iowa. Briefly, he found that in teaching anundergraduate real-time systems course over many years, students' successrate developing control code went from 0% to nearly 50% when the languageused was changed from “C” to Ada.

While “C” may have a place in application programming – it is quick towrite, everyone knows it, and the compilers are very forgiving – thelanguage soon becomes unsuitable as the size of the application grows.I must agree, and your poll illustrates that, given Ada's design forsupport of embedded real-time systems, we do not in general pick the mostappropriate 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 toreduce programming errors…. what a novel concept! And, the compilers areessentially perfect due to the validation process. Brilliant ideas. Yet forsome reason it has almost zero market share in the embedded space. Why?

Karl WoelferSoftware Architect, Embedded Systems
Heartstream Philips


I recently started reading “Extreme Programming Explored” by William Wake. Ididn't get very far. As an old Forth programmer who was the “Forth Doctor” atMountain View Press, I quickly recognized that this great new discovery wasjust the use of typical Forth programming methods applied to C and madepossible by GHz computers that allow rapid write/compile/test cycles that arenearly as fast as Forth development on an Apple II.

I guess these new eXtreme programmers never used Forth and so don't know theheady eXperience of working in a moldable object type language where you havethe 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 thatis another story, perhaps best titled “How to ruin a company with a languageguru.”

Note: I have seen some wonderful Forth projects. The great Canon Cat by JefRaskin and Information Appliance, Inc. crammed a massive amount of code in asmall space with a very efficient tokenized Forth.

Today there is a very sweet object oriented Forth called Mops for the PowerPCand 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 seewhat the minority is up to. The object model is better and more intuitivethan 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) NationalSemiconductor HPC16083. There is an almost-ANSI C compiler, and anassembler. At my previous job, the chief engineer learned on an 8085, soguess what we used? There was assembler. No C, no BASIC, no Forth, nonothing.

(2) Ease of use — Can I just run the language, and get usable output, ordo I need to recompile the source to make it work on my machine, orotherwise fiddle with it? — We dropped a “more advanced” C compiler becauseit could not work with code written with the previous version.

(3) How easy is this language to learn? The big problem I have with Forthis 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, andPascal. When I needed a program to monitor RS232 communications, Pascalcouldn't do it, and with C I'd need to write the low-level interrupt driversmyself (Not to mention debugging them!). With BASIC, I just OPENed the COMport, and was up and running in less than half a day. However, C is good forwriting character-stream filters.

One of the difficulties with Forth is lack of documentation — not in thecode people have written themselves, but documentation that explains whatall the words mean. Type in “words” and the vocabulary zooms by on yourscreen. 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 onthe 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 nosedaround the Forth sites two weeks ago, there were articles available, butthey were almost all written by pros on subjects I'm not interested in. (I'mstill trying to find out how to read in that string…).

Another difficulty is interoperability. I can write a program with myfavorite editor, and load it into / compile it with C, Pascal, or BASIC.With Forth, I have to struggle to learn someone else's idea (oftencounter-intuitive) of how an editor (seemingly based on EDLIN or VI) shouldwork.

Oh, well, enough steam.

Rich Ries


Ada – “a huge and complex beast” haven't you even compared the ISOLanguage Reference Manuals for Ada and C++?!?!?! 🙂

Ada95 is positively silph-like and at least you can get compliantcompilers for it!

I've also found it that the GNAT compiler at least produces more efficientcode than either VS++ or Borland C++ – though these are obviously not thedomain your concerned with.

Check out www.cw360.com for their quarterly job surveys and you'll findAda 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, Ithink 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, toodeep. Java's strength is that it offers much of the OOPy stuff in a moreuseable context. Predictions are tough, but I expect that when Java maturesit will seriously eat into C++'s market share..


Ada (named for a lady) is not ADA. I used it extensively on a largeproject where it significantly reduced integration complexity. First youintegrate your interfaces (with package specifications), then youintegrate the functionality (adding the package bodies). And it alwaysdoes 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 ofcertification that Ada has. Everyone I know has fought compiler bugs with Cand C++. That doesn't happen with Ada.


I can't agree with the opinionthat new folks will use new LanguagesThe real force is management, becausethey decide the language choicewith arguments like “standard”.

For example:
i made a code size comparisionbetween Eiffel and C++. AlthoughEiffel is a real high level languagewith garbage collector, the result wasonly 20% code size compared to C++.But instead the winner is Embedded C++,a completely crippled language(no multiple inheritance and nointerfaces, no templates, no exceptions)that also results in 20% code size.

Another example: can you show me anyC-Compiler that can generate codeto 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 whatthey are told it is “standard”,and they don't ask questions.

Every sane programmer avoidsusing C++ if possible. For methis is the only explanation, whynearly all free software is n o t writtenin C++. But C++ is widely used in commercialproducts. Why? Ask the management.At the moment everyone wants to haveembedded Java. Exactly they want acheap system with no power, no memoryrunning a java byte code interpreter withjava runtime environment and Internet.Do you think they know that they aretalking about?

In a few years you will see a lot ofembedded java machines, because managementwants them. Then all studentswill learn Java and in ten years javais standard and no one will ask why.If you don't believe me, try to convinceyour management to use something differentthan 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-bitmachines, at least the somewaht limited “Embedded C++” variety. Not thatanyone is USING them…

I think you overlooked one big force in language choice: what students aretaught in the universities. The languages you learn as an undergraduateare probably going to be the languages you use once you get out ofuniversity. Learning new languages is quite rare. And what languages aretaught? Ada: very rarely. C and C++: all over the place. Java: all overthe place.

So the java people have understood the importance of academic mindshare bygiving away development tools… and that will pay off in a few years withmore programmers familiar with Java being forced to do embeddedprojects. Good times are coming for vendors of “unnecessarily powerful”hardware.

Fepp

JACK REPLIES: Yeah, I do agree. Languages come into their own when newfolks come into the market who have grown up with them. That means we oldfarts must die before a new language succeeds…

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.