In a real practical application, if you properly evaluate Forth for doing Embedded solutions, then it becomes a real viable option considering the alternatives. First thing is readability of a DSL for an embedded project, working through the HAL that are created just to communicate with the hardware is a real PITA, but forgoing that even further, creating your own DSL for the HW layer is extremely useful even for the HW teams, you can be calling connection the same for once, Pins will be Pins, you will SENDRESPONCE PIN20 etc. Furthermore, you can be doing unit testing with in the development phase not after, so that eases the debugging of the SW and expedites time to do integrated validation. Further more, the interactiveness of FORTH is a unique experience, it makes the little MCU feel like a complete system. There was a recent posting in youtube that best describes this, and IMHO, it’s a hard to beat option as you den with in a MCU, validate each of the function words in Forth to ensure that bit of the code is working. Finally, you don’t need a lot of the dedicated hardware to debug, you are with in the system and you can read the register and memory interactively, so no surprises. If you consider al this, then it’s IMHO a hard option to pass up for this kind of work. Here is the video I mentioned: https://www.youtube.com/watch?v=VPVbARJ8QsA&t=3120s Cheers!