In wiki.OSDev.org, they talk about Forth's inventor Charles Moore and you have the following statement:
Charles Moore, inventor of Forth, wrote a CAD program which was structured around just 5 lines of code. When asked how long it took to write those 5 lines, he replied, "Ooh, about 2 years"!
I've been trying to find out more about that OKAD program but without much success.
Did Charles Moore really write a CAD program in only 5 lines of code?
tl;dr It's not 5 lines and it's not a CAD program, but it's still extremely small, but that's not as impossible as it first sounds.
You are misunderstanding the quote in several different ways.
First off, we are not really talking about something like AutoCAD here. Chuck Moore's company is designing microchips, and he himself describes these tools as "VLSI Design Tools". If you look through those pages, you will see that the tools don't really look like you are imagining: they are text-driven, not GUI-driven, and they are pretty low-level. (The chips Moore designs are very simple, deliberately so, therefore he does not need all the fancy tools that are required to tame the complexity of a billion transistor monster like modern desktop and server CPUs and GPUs.)
[An example of OKAD visualizing an XOR gate. Source: https://colorforth.github.io/gates.htm]
Second, the quote doesn't say that the CAD program was written in only 5 lines of code, but that it was "structured around" only 5 lines.
The very fact that the word "around" appears in that sentence implies that there was more code than those 5 lines – otherwise, there would be no "around".
On the page linked above, Chuck Moore talks about 500 lines, not 5.
It should also be noted that colorForth, as the name implies, employs color for syntax and semantics. This means that there is an additional dimension that can be used which is not available to most other programming languages. This alone can cut down the size of the code, if you consider that everything colorForth expresses with color must be expressed using text in a more typical programming language.
Third, you have to consider the mindset of Chuck Moore. He is obsessed with simplicity and efficiency. He invented his own keyboard layout, so he can type more efficiently (using only the 27 keys of the home row). He designs his own CPUs because he considers the ones available on the market to be inefficient and too complex. He creates his own VLSI design tools, his own programming languages, etc.
Fourth, you have to understand how Forth programs are typically written. Forth programmers typically use Language-Oriented Programming. Now, they don't call it that because the term was invented much later, and also because programming in that style is so natural in Forth that nobody would even think of giving it a name. But that is what Forth programmers are doing.
So, what is Language-Oriented Programming?
The idea behind LOP is the same as the idea behind Object-Oriented Programming or Procedural Programming: in Object-Oriented Programming, you solve a problem by breaking it down into Objects, by writing Objects for every sub-problem, every sub-sub-problem of the sub-problems, and so on. The same with Procedural Programming: you break it down into Procedures.
With LOP, you solve each one of the sub-sub-…-problems by imagining the ideal language in which solving this particular problem becomes trivial, then solving the problem by writing the program in this language.
As a result, you end up with really simple, short programs, because they are all written in a language that is specifically optimized for solving this particular problem. These languages are typically called Domain-Specific Languages. However, note that this is a rather new term and is not used within the Forth community. Chuck Moore himself uses the term Problem-Oriented Language.
The only thing you are left with, is implementing all of those little languages. But you can apply the same approach here: you imagine a language in which implementing a language is easy, then implement all the languages in this language. Which leaves you with only one last problem: how to implement this language … oh, but this problem is already solved, because in order to implement this language you need a language in which it is easy to implement languages, but you already have such a language: that's the language you are just implementing. So, you can implement this language in itself, and you are done.
Forth (and by extension colorForth), in turn, are designed for this style of programming. For example, it is easy to extend the Forth language with new constructs that are indistinguishable from the built-in ones.
It is perfectly conceivable that a CAD program written in a language that is specifically designed for writing CAD programs (and even more: a language that is specifically designed for writing this particular CAD program) would only take 5 lines for the core of the code.
For an extreme example, consider the HQ9+ programming language. While it was created as a joke, it nicely demonstrates the principle: HQ9+ can solve the three most common beginning programming assignments (Hello World, 99 Bottles of Beer, and Quine) in a single character … but it cannot solve any other problem. It is highly specialized, but within its specialized domain, it is highly efficient in terms of code size.
A more realistic example how LOP can dramatically compress code: Linux has on the order of ten million lines of code. It is typically said that 90% of that is drivers, and 90% of the rest is architecture-specific. That leaves us with about a hundred thousand lines of code for the actual "meat" of Linux. That's not much more than memory management, task scheduling, task isolation, basic I/O, and some other stuff.
The various versions of the L4 microkernel are on the order of a couple thousand lines of code, for a kernel that tries to do as little as possible. One of the guiding principles of L4 is that functionality is only implemented in the kernel if that goals of that functionality are impossible to achieve otherwise. Everything else is in userspace.
OTOH, a system that Alan Kay and some other researchers were working on a decade or so ago, which employed LOP techniques, needed only ~30000 lines of code (they were aiming for 20000, down from 60000 for the publicly released Smalltalk-80 2.0 system and 230000 for Squeak, and were down to 30000 when they ran out of funding) for a full desktop system, from the most basic functions of the OS kernel, to a VM, garbage collector, graphical desktop environment, networking, document processing, IDE complete with compiler, interpreter, debugger, code browser, and editor, desktop publishing, spreadsheet, and a lot of other stuff. That's a full desktop system in a third of what Linux needs just for the bare core of its kernel and only less than an order of magnitude more than one of the smallest microkernels.
Of course, this system did not have all the bells and whistles of a modern desktop system, but consider this: Windows is about tens of millions of lines, Office hundreds of millions. That's on the order of 10000 times more code … even if Kay's system is just a basic research system, I don't think Windows+Office has 10000 times more features. (Again, a lot of this is drivers, architecture-specific code, workarounds for BIOS bugs, import and export for third-party file formats, etc. But even if we assume that 99.99% of that is not necessary, we are still at an order of mangnitude more code.)
These 5 lines may have been the centerpiece of the code, but the whole of OKAD is a lot larger:
The application I use colorForth for is called OKAD, Ok Aided Design. It is set of design tools for VLSI layout/simulation. The Ok comes from classic Forth, where each command line is acknowledged with it. The source code for OKAD occupies 1440 blocks, the amount that can be stored on a floppy disk. This is the largest body of code I've ever written and has taken some 8 years to develop.
So, not really 5 lines.
