Forth in the commerical embedded marketplace?

[Peter Jakacki]

(edited and reposted from microcontroller.forth group)
There seems to be no quality forums for Forth and the alt.lang group itself is a real turn-off. However, when I started a microcontroller Forth group years ago the main problem is still the same problem, that any Forth forums are mainly concerned with standards and PC Forths, yet the real strength of Forth has always been in control applications which is the domain of microcontrollers, not PCs. So there is nowhere I can post this.

Yesterday I was talking to a new client and when he asked me which languages do I code in, and I timidly admitted that I use this little known language called "Forth". FORTH! he roared, and while I was taken aback he went on to say that he didn't think anyone programmed in Forth anymore, but ...... he always loved Forth for industrial control applications. My alarm was allayed.

Well the thing is, we sometimes think "nobody" else uses Forth, but so many times I have come across people or hear of people who use Forth in a commercial product, but don't advertise it. After all, why should you? The truth is I have Forth buried in so many products in so many different markets and with different types of MCUs, right from the humble 8-bit to the 32-bit and even now I am working on 64-bit RISC-V Forth as well.

What about you? What stories can you tell or know of? What Forth do you use and what features do you see that would be welcome? How do you feel about "the" standards?

I am posting this on my Tachyon Forth Source Forge page as well. Hopefully you Forthers will come out of the woodwork and "squeak up"! :)

[Maciek]

Reposted from the reply via message board in the Parallax forum in Jan 2021.
Here are my thoughts.

"Forth in the commercial embedded marketplace?"

There may be more answers to your question than just one. Some may even contradict each other and that would be just as good.
Firstly, I would segment the market to four groups as they differ too much to take a common approach to them.
Group 1 - low value, disposable goods/gadgets
Group 2 - medium value, commercial equipment
Group 3 - high value, unique custom project
Group 4 - factory automation and commercial robotics.

Then I would chose which side I'm on - the client (investor) or the solution provider (programmer). Here I take the client/investor side and try to answer your question.

Group 1 - low value, disposable goods/gadgets - I really do not care what a solution provider uses. The only requirements I am concerned with are if the solution (mostly) works, is (fairly) cheap and can be implemented as fast as possible.

Group 2 - medium value, commercial equipment - Here I expect to have to provide some level of support for the product for a few to several years with predictable time to fix period . If my contract with the solution provider is adequate (mitigates the risks I might experience along the years the product is expected to be in service) and the solution provider is well established (good reputation, financially stable, dedicated etc.) I mostly would not care what he/she uses as a programming language but typically I would think it is safer to stick with something well known just in case somebody else than my current provider would have to maintain the code.

Group 3 - high value, unique custom project - here is where it becomes more interesting and challenging to both sides of the contract. I would very much like to work with my solution provider very closely. Big money is at stake and project has to deliver. Failure is not an option. Whether I would prefer any specific programming language or not would be very much dependent on the objectives of the project and without these requirements I can't really say.

Group 4 - factory automation and commercial robotics - this is very similar to group 3 but If I run a big or a business critical (small but my life depends on it) factory I would rather stick to something mainstream with at least two or three alternative vendors ready to take over in as little amount of time as possible if my main one fails.

Of course, there are other factors to consider like, for example, code ownership, costs of lost production, insurance, defamation risk etc.

Forth is a niche programming language and it will stay as such. If one is able to find his niche and fill it with a product coded in forth and does it right, the customer will happily come again and will silently advertise the solution provider and possibly forth to his business partners/clients hence successful forthers do not need to advertise big.

When it comes to standards I am of the not so popular opinion that a standard is something that is nice to have if it doesn't get in your way. And by that I mean that if I was presented a chance to do something in a way described by some standard and do the same thing better but violating the said standard at the same time, I would always choose the later. Why ? Simple. To me the common sense should always prevail.

Trying to enforce whatever embedded forth standard is just such a waste of time and (usually limited) resources that I wouldn't even consider such a thing for a second. Forth is, when done right, all about delivering the working solution with the lowest development cost and time possible.

I'm a casual forth user and not a professional embedded programmer but when I got to play with micro controllers years ago and saw so many badly written and poorly documented programs and so called "standard" libraries I almost quit. Add to that different compilers, IDEs, portability issues...
And then I came across forth. It so happened that was at the time when Thomas started his stm8ef project. Then I discovered mecrisp stellaris and then your Tachyon and TAQOZ which I am patiently learning. I am sure I will never look back unless there is a clear benefit to it which I can't see at the moment.