"Stephen Pelc" mpeforth.com> wrote in message
news:48c29da7.884407687@192.168.0.50...

Worse than being not socially acceptable, I get the sense that most people
programming for embedded applications have simply never even heard of Forth.
As far as those on the MSP430 Users group are concerned the only options
seem to be C and assembler.

As far as getting people to try Forth, I think that the first step is to
make them a)aware that there is something that might better suit their needs
and b) how it might be better. That is where magazine articles authored by
current users might be helpful. A deeper question is why would current users
bother to write such articles. Magazines don't pay very well for the stuff
that fills the space between the advertisements. There are quite a few
people here who are quite dedicated to the language, perhaps we need more
who are dedicated to its use.

The audience for the first question is probably management. They have to
see benefits to the bottom line in order to even consider changing. In my
experience, too many software managers have little or no actual hands-on
experience. They took a class in C in university, so to them that is
obviously the language of choice.

BEGIN RANT {
If our political and corporate leaders don't soon smarten up, Chinese will
become the lingua franca of spoken languages.
} END RANT

I'm really not too sure what your point is here. I don't believe I have
made any claims, let alone having claimed too much. Simply put, Forth fits
nicely with the way I like to work - an iterative try it and see approach.
Looking at the questions asked on the MSP430 Users group, I get the sense
that a lot of the questions asked there would quickly yield to such a try it
and see approach. Forth, or at least SwiftX, allows that. Read the manual,
write the registers, see what happens, write the function once you've
figured out what to do. As a test engineer, I've traversed the code-compile
& link - download - debug loop with C far too many times - though usually in
a windows based environment. Lingua franca or not, in my opinion, C is a
lousy language when you need to get close to the hardware - particularly
with new designs that may not work quite as advertised or might not be well
documented.

I'm afraid you've really lost me here. I have no idea what numbers, theory,
and assertions you are referring to.