I've found that forth works best when you use it to create a DSL for your problem domain, and you write your application code in that DSL. That DSL becomes the

I've found that forth works best when you use it to create a DSL for your problem domain, and you write your application code in that DSL. That DSL becomes the critical abstraction that helps prevent your codebase from becoming an unusable/unmaintainable mess. This isn't a new idea; the book that got me thinking about when/how to use forth was (oddly enough) http://thinking-forth.sourceforge.net/ http://thinking-forth.sourceforge.net/ . It's a good read even if you never intend to build a forth project. As a side note, I've done image processing with forth: I helped build a commercial HD video camera with it that shipped in the mid 2000s, and I found it well suited once we had the problem reasoned out well enough to build our DSL. Overall the product ended up being composed of forth/C/hand written assembly, and a bunch FPGAs. We shipped things with < 10 people, and I think the interactive/extensible mindset that forth gave us helped us get the product out the door successfully.