It's been ages since I did any Forth programming, but at the start of my career I spent about 2 years writing Forth code. I have always found that bottom up pr

It's been ages since I did any Forth programming, but at the start of my career I spent about 2 years writing Forth code. I have always found that bottom up programming is very similar in nature to test first TDD. You start implementing one specific part, then you implement another specific part. You check to see if there is a better representation for it and refactor if you can. Rinse and repeat. This is very different than outside-in GOOSE style development, though. You start at the lowest level of abstraction and work your way up. It requires you to do some analysis of the problem up front so that you can see that low level of abstraction. WRT your example, I can't really work through it without a real problem, because the devil is in the details. But generally, if I have to parse some strings, I'll start with parsing an example of a string in the simplest way I can. Then I'll expand that code to include another string, refactoring the code as I go. Once I have some idea what the parsing interface is going to look like, I'll write some code to read a line from a file. Then I'll work my way up to call the code that reads the line and sends it to the parser. Then I'll take a look at the representation for the parsed string and implement a single CSV output. Then back up to hook that up. Finally, I'll move back down the abstraction layers and work on more strings. You want to move from that low level, gradually up refactoring as you go, and then dive back down repeatedly. Or at least that's how I do it. I don't pretend to be as skilled at it as Chuck Moore who is famous for discovering amazing abstractions. I should note that not all problems fit this style of development. Sometimes you have to work from top down. Normally you can discover this fairly quickly if you start chasing your tail. You'll implement something, work your way up, then move down only to discover that you have to change something fundamental. You do it, moving back up, only to discover that the first bit doesn't work any more. However, once you discover the top level abstraction you need, you can go back to a bottom up technique because the lower level abstractions will be more obvious.