Skip to content(if available)orjump to list(if available)

An Attempt at a Compelling Articulation of Forth's Practical Strengths and Eter

ofalkaed

Considerably better than most such articles that I have read on this but I think if the Forth community wants to get people into Forth it really needs to stop talking about how it can fit in a boot sector and the REPL; the former is not of interest or use to most programmers and the latter is probably a major cause of the misconception of Forth code being impossible to read.

What I see as the real strength of Forth is that if you write your program in source files, there is no abstraction. You stick your word definitions in those source files and let the application you are writing dictate the words you define instead of relying on the dictionary you built up on REPL and things quickly start becoming easy and the code remains readable. It might seem like a lot of work and endlessly reinventing the wheel but if you start with a featureful Forth like gforth it does not take that much time or effort once you have the basics down; you can build complex applications with gforth as easily as you can build up a full Forth with that minimal Forth that fits in your boot sector.

The main thing is learning that application development with Forth is actually top down design and build up writing. You break the application up into its major functions, break those into smaller functions, break those into words and then break those words into those simple sort words that everyone in the Forth community says you should write. Then you start writing code. I am just starting to get the hang of Forth and it is surprisingly quick and powerful once you start getting the sense of it.