[ofalkaed]

Large programs mean lots of word definitions and essentially writing a DSL, most are not going to document that DSL well enough to make the code readable to anyone else and how many people want to learn a weird adhoc language myopically designed for building one program? I love Forth but it mostly died for good reason. Once you learn its workflow and develop your dictionary it is incredibly quick and easy to use but it will be a chore for anyone else to understand and work with.

[johnisgood]

So if it is documented well, then it would be suitable for large-enough programs? Or do you have any tips?

[ofalkaed]

I think it can work but it takes a different way of looking at things. The main thing is that you need to take the time to design that DSL from the start and stick to it, if you come to a place where the DSL can not do what you want you need to address the issue with the DSL instead of just falling back onto the underlying Forth. It is a very different way to program and at times you find yourself have to make massive changes to the DSL you designed which also means changes to the program you are using it to write.

DSL is probably not quite the right word, it could be but generally I think it is still going to be fairly Forth like, but you need to think of it that way. You layout what your program does and then reduce it to a few dozen words which work as a description language for the program, then maybe a 100 more words which those words require along with any glue and together all constitute a reasonably sane language. Then you start from the bottom up and implement all those words. The big trick is having the foresight required to pick the function of each of those hundred odd words well enough that no one will ever have to dig into the the 1000 odd words below that it took to implement them. It really forces you to think about how your program may evolve and the bugs which may crop up, you can't change one of those low level words without affecting all that are built on it and if you do the easy work around things start to get messy.

Not sure how well I explained that, I am no Forth expert but I am getting better.

[alexisread]

That's a nice take. Implicitly though, that implies treating words not as functions but as coupled routines, possibly because forth is untyped.

If anything goes wrong during development you need that model of the stack in your head to debug- I think that's the main differentiator, and if you had a typed forth with local variables, it would enable greater readability ie. I can scan the individual words/ functions without needing that stack model.

Just my POV, not sure if that resonates?

[ofalkaed]

Forths can have local variables, both ANS Forth and gforth have them and if your forth does not have it you can make your own or possibly just include gforth's if your forth is compatible. Keeping track of the stack becomes second nature and all but the simplest implementations have great tracing and debugging if you get lost.

Forths can also have types but it is slightly different, gforth has a float stack with its own commands and you can implement others and any other feature you want.

Once you get used to working global and without type it gets surpringly easy, it is more difficult for me to work with type and scope than without and when I use something like C I am constantly fighting it and feel like erything is needlessly complicated.