In last week's installment of The Embedded Pulse 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 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...
