I’m reading the downloaded Thinking Forth PDF by Leo Brodie.
The preface to the 2004 edition starts off a bit strange:
- in the 1984 preface he disses object oriented programming
- in the 1994 preface he apologizes for that, after having worked a bit with an OO Forth
- in the 2004 preface he partially retracts his apology and notes that he by no means has sold out in favor of full-blown OO languages, because “there was no need for garbage collection etc” in the OO forth
- and then he disses Extreme Programming. Some people have noted parallels between Thinking Forth and XP: iterative development, incrementally enhancing code that works, not over-solving the problem. But XP does no conceptual design, from what he’s read about it. He concludes the preface with: “But the irony in comparing Thinking Forth with Extreme Programming is that some developers of the XP stripe (and who of course have never heard about this book) don’t even see the value of a spec! Ah well.“.
Ah well.
But there’s a lot of stuff that resonates (again) with thoughts about DSLs:
“An important result of this approach is that the entire application employs a single syntax, which makes it easy to learn and maintain.
In fact, you shouldn’t write any serious application in Forth; as a language it’s simply not powerful enough. What you should do is write your own language in Forth (lexicons) to model your understanding of the problem, in which you can elegantly describe its solution.“
And on design:
Forth is a design language… In Forth you can write abstract, design-level code and still be able to test it at any time by taking advantage of decomposition into lexicons… Using this philosophy you can write a simple but testable version of your application, then successively change and refine it until you reach your goal.
How very much unlike design in XP!
And on planning:
Forth programmers spend less time planning than their classical counterparts, who feel righteous about planning. To them, not planning seems reckless and irresponsible. Traditional environments force programmers to plan because traditional programming languages do not readily accommodate change.
The book mixes Brodie’s views with interviews of people using Forth and of Forth’s creator Chuck Moore. The advice they give is often contradictory (plan more, plan less), as each gives the advice that is applicable in their situation. I remember that at the time I first read this book, one of my colleagues (who liked Forth) said he hated the book: “Can’t they make their minds up? They constantly contradict what they said a few pages before!” 🙂
I especially like Moore’s bits. One of the tips is: Don’t write your own interpreter/compiler when you can use Forth’s
Moore explains it thus:
If you write your own interpreter, the interpreter is almost certainly the most complex, elaborate part of your entire application. You have switched from solving a problem to writing an interpreter.
I think that programmers like to write interpreters. They like to do these elaborate diffcult things. But there comes a time when the world is going to have to quit programming keypads and converting numbers to binary, and start solving problems.
Take that you evil purveyors of badly designed programming languages disguised as configuration files or (the horror!) XML files!
