What do you think?
Rate this book
Programming A Problem Oriented Language: Forth - how the internals work
In this year, 2018, we celebrate 50 Years of Forth. How do you define a computer language? Charles Moore, the inventor of Forth, takes you through the different steps and as well through the reasoning behind it. This is an early book and with the 50 Years Of Forth, this eBook, available for 4 years, will now be made available as print book as well. It is part of the Forth Bookshelf at amazon, see .
169 pages, Kindle Edition
First published May 2, 2014
26 people are currently reading
42 people want to read
About the author
Charles H. Moore
11 booksCharles H. Moore (also known as Chuck Moore) (born 1938) is the inventor of the Forth programming language.
https://en.wikipedia.org/wiki/Charles...
https://en.wikipedia.org/wiki/Charles...
Ratings & Reviews
Friends & Following
Create a free account to discover what your friends think of this book!
Community Reviews
Displaying 1 - 3 of 3 reviews
November 17, 2020
Charles Moore had a philosophy about using computers, and in 1970 (when he was 32), he wrote a manifesto of sorts on how to properly use a computer's limited resources. He included the design for his stack-based programming language "Forth" to make good on his views.
Moore believed in a 3-fold "basic principal": 1) "keep it simple", 2) "do not speculate!" (never include any code or library that is not used), and 3) "Do It Yourself!". By "Do It Yourself!" he meant to literally write everything from scratch. The libraries (he mentions SQRT and double-precision complex integer handling as examples), the language the libraries will be expressed in, even the operating system, everything, from scratch.
Example: (P174) "So now you’re face to face with the computer. What do you do? First an exercise. Initialize the interrupt locations in such a way that the computer will run, will execute an endless loop, when you start it. OK? Then modify your loop so that it will clear memory. OK? You’ve probably learned a lot.
. . . [details omitted] . . .
So, with a couple hours work — providing you read the manual first — you have an operating system (SAVE, LOAD) and debugging package (DUMP). And you know a lot about your computer."
Moore didn't like how wasteful high-level languages had become. p19 "For example, upon entering a FORTRAN subroutine it may save the registers it uses. If you didn’t need to save them you’ve wasted time and space." At the time of writing this review, Moore is still alive; I wonder if he keeps up with the industry, and if so, I wonder what he thinks of a hello-world-sized program in Go compiling to 2M, or 3M for the same program expressed in Rust? That said, I'm an avid 6502 assembly language programmer, which is used in retro environments where every byte counts, so I can understand where the author is coming from.
By today's standards (50 years later), Moore proposed some interesting programming anti-patterns:
P22: "Make the variables as GLOBAL as possible. Why not? You can save some space and clarity your requirements. For instance, how many Is, Js, and Ks do you need?"
P24: "Use comments sparingly! (I bet that's welcome.) Remember that program you looked through -- the one with all the comments? How helpful were all those comments? How soon did you quit reading them? Programs are self-documenting, even assembler programs, with a modicum of help from mnemonics."
[advocating for only saving Forth source, not finished binaries] P108: "It ought to be a Second Principle that you never save anything on disk without being able to modify it, but this rule is universally ignored. To simply copy dictionary entries violates another cardinal principle: never store core address on disk. You could never modify your program without chasing down all code addresses."
In fact, he gets a bit strange when it comes to describing how to translate Forth into native code. He starts off by saying (p103) "What about compiling code for your real computer then? Of course you can. But you probably won’t.", and concludes with (p107) "I’m sorry, but I think it’s infeasible to attempt an example. If you can’t see how to construct your own code entries from what I’ve already said, forget it. The application is extremely machine dependent — and rightly so.". Fortunately, if you want to compile Forth programs for, say, the Commodore 64, modern compilers do exist: https://github.com/jkotlinski/durexforth
It's fascinating to see contemporary techniques described but without the modern naming conventions.
For example (p162): "For very large dictionaries, scramble the word into a block address and search that block. By that I mean compute a block address from the letters in a word, just as we did for multiple chains in the core dictionary, though you’ll probably want a different algorithm. You can search one of a thousand blocks and be assured that if the word is anywhere, it’s in that block. Because you used the same scramble technique to put it there as you use to find it. Since many words will scramble into the same block, you of course search for an exact match. Again, just as in core. With such a large disk dictionary, you want to be careful of several things. First, once you choose a scrambling algorithm you can never change it; so make a good choice before you define lots of entries. Second, try to keep the number of entries roughly the same in all blocks; and roughly equal to half the capacity of a block—to compensate for the first 'roughly'. Or else provide for overflow by linking blocks together."
This is, of course a hash table with chain collision resolution
Or this (p154): "I am embarrassed not to know the standard terminology for what I am going to discuss. I have never heard it discussed and I have never searched for it. But it must be a standard aspect of compiler writing—discussed in courses dealing with compilers. If you know the terminology, you also know most of what I’m going to say: although I hope I can get you to stretch its application.
Our arithmetic operators have found their arguments already on the stack. Conventional algebraic notation uses such operators as infixes, and a left-right scan provides only one operand when the operator is discovered. Consequently the operation must be deferred until the other operand is available."
The phrase Moore is looking for is "operator associativity".
I'm glad I already worked my way through a different introductory book on Forth, because this "introductory" book is more about building your own Forth language from scratch. Crazy right? A book that doesn't first describe the language in any depth, but rather, the process by which to write the language itself. Increasing the difficulty for the would-be reader/implementer is that Moore was early into his thinking on Forth, and not all the fundamentals had been thoroughly solved. That said, if I were alive (and of age) in 1970, I would have likely drank this Kool-Aid. Fun stuff.
Moore believed in a 3-fold "basic principal": 1) "keep it simple", 2) "do not speculate!" (never include any code or library that is not used), and 3) "Do It Yourself!". By "Do It Yourself!" he meant to literally write everything from scratch. The libraries (he mentions SQRT and double-precision complex integer handling as examples), the language the libraries will be expressed in, even the operating system, everything, from scratch.
Example: (P174) "So now you’re face to face with the computer. What do you do? First an exercise. Initialize the interrupt locations in such a way that the computer will run, will execute an endless loop, when you start it. OK? Then modify your loop so that it will clear memory. OK? You’ve probably learned a lot.
. . . [details omitted] . . .
So, with a couple hours work — providing you read the manual first — you have an operating system (SAVE, LOAD) and debugging package (DUMP). And you know a lot about your computer."
Moore didn't like how wasteful high-level languages had become. p19 "For example, upon entering a FORTRAN subroutine it may save the registers it uses. If you didn’t need to save them you’ve wasted time and space." At the time of writing this review, Moore is still alive; I wonder if he keeps up with the industry, and if so, I wonder what he thinks of a hello-world-sized program in Go compiling to 2M, or 3M for the same program expressed in Rust? That said, I'm an avid 6502 assembly language programmer, which is used in retro environments where every byte counts, so I can understand where the author is coming from.
By today's standards (50 years later), Moore proposed some interesting programming anti-patterns:
P22: "Make the variables as GLOBAL as possible. Why not? You can save some space and clarity your requirements. For instance, how many Is, Js, and Ks do you need?"
P24: "Use comments sparingly! (I bet that's welcome.) Remember that program you looked through -- the one with all the comments? How helpful were all those comments? How soon did you quit reading them? Programs are self-documenting, even assembler programs, with a modicum of help from mnemonics."
[advocating for only saving Forth source, not finished binaries] P108: "It ought to be a Second Principle that you never save anything on disk without being able to modify it, but this rule is universally ignored. To simply copy dictionary entries violates another cardinal principle: never store core address on disk. You could never modify your program without chasing down all code addresses."
In fact, he gets a bit strange when it comes to describing how to translate Forth into native code. He starts off by saying (p103) "What about compiling code for your real computer then? Of course you can. But you probably won’t.", and concludes with (p107) "I’m sorry, but I think it’s infeasible to attempt an example. If you can’t see how to construct your own code entries from what I’ve already said, forget it. The application is extremely machine dependent — and rightly so.". Fortunately, if you want to compile Forth programs for, say, the Commodore 64, modern compilers do exist: https://github.com/jkotlinski/durexforth
It's fascinating to see contemporary techniques described but without the modern naming conventions.
For example (p162): "For very large dictionaries, scramble the word into a block address and search that block. By that I mean compute a block address from the letters in a word, just as we did for multiple chains in the core dictionary, though you’ll probably want a different algorithm. You can search one of a thousand blocks and be assured that if the word is anywhere, it’s in that block. Because you used the same scramble technique to put it there as you use to find it. Since many words will scramble into the same block, you of course search for an exact match. Again, just as in core. With such a large disk dictionary, you want to be careful of several things. First, once you choose a scrambling algorithm you can never change it; so make a good choice before you define lots of entries. Second, try to keep the number of entries roughly the same in all blocks; and roughly equal to half the capacity of a block—to compensate for the first 'roughly'. Or else provide for overflow by linking blocks together."
This is, of course a hash table with chain collision resolution
Or this (p154): "I am embarrassed not to know the standard terminology for what I am going to discuss. I have never heard it discussed and I have never searched for it. But it must be a standard aspect of compiler writing—discussed in courses dealing with compilers. If you know the terminology, you also know most of what I’m going to say: although I hope I can get you to stretch its application.
Our arithmetic operators have found their arguments already on the stack. Conventional algebraic notation uses such operators as infixes, and a left-right scan provides only one operand when the operator is discovered. Consequently the operation must be deferred until the other operand is available."
The phrase Moore is looking for is "operator associativity".
I'm glad I already worked my way through a different introductory book on Forth, because this "introductory" book is more about building your own Forth language from scratch. Crazy right? A book that doesn't first describe the language in any depth, but rather, the process by which to write the language itself. Increasing the difficulty for the would-be reader/implementer is that Moore was early into his thinking on Forth, and not all the fundamentals had been thoroughly solved. That said, if I were alive (and of age) in 1970, I would have likely drank this Kool-Aid. Fun stuff.
September 9, 2022
This is not an _amazing_ book by any means - but if you're into the Forth language/ecosystem like I am right now, it's pretty high on the list of things to read. It's Moore's own explanation of: 1) What he built, 2) How he reasons about a self-bootstrapping programming language (namely, Forth), and 3) His general philosophy of software development.
I gotta say, while you can argue about how Forth helps or hurts the cause, his First Principle of _keeping it simple_ is spot on! And he's practical about it too.
I like that we get an opinionated take on a variety of topics such as the pros and cons of word (function) name lookup strategies, etc. I love how practical he is about complexity vs. storage concerns vs. compute time concerns.
It's a bit rambling and meandering and is not a highly professional and polished book. According to the introduction, it's a manuscript that essentially sat in a drawer for decades. A later chapter even has a note that goes something like: "I'm not sure why I thought this part was needed, but here it is anyway..." Which I enjoy. Moore is human too!
I gotta say, while you can argue about how Forth helps or hurts the cause, his First Principle of _keeping it simple_ is spot on! And he's practical about it too.
I like that we get an opinionated take on a variety of topics such as the pros and cons of word (function) name lookup strategies, etc. I love how practical he is about complexity vs. storage concerns vs. compute time concerns.
It's a bit rambling and meandering and is not a highly professional and polished book. According to the introduction, it's a manuscript that essentially sat in a drawer for decades. A later chapter even has a note that goes something like: "I'm not sure why I thought this part was needed, but here it is anyway..." Which I enjoy. Moore is human too!
April 1, 2025
Look into the thoughts behind Forth..
I enjoyed reading of the thought processes behind the Forth language. It was entertaining to follow along on how and why to implement its features. I would recommend it to anyone who likes to fiddle with bits and bytes.
I enjoyed reading of the thought processes behind the Forth language. It was entertaining to follow along on how and why to implement its features. I would recommend it to anyone who likes to fiddle with bits and bytes.
Displaying 1 - 3 of 3 reviews