Forth, Delphi, and now webOS

If you were searching for the terms “Forth,” “Delphi,” and “Greg Stevenson,” it’s probably because you read the foreword I wrote for Mitch Allen’s new webOS book. In it I mentioned that the advent of webOS was only the third time in 30 plus years that I had gotten truly excited about a new technology.

At first, I did not mention what the first two technologies were, or why they got me excited—I didn’t want to bore the reader with what, in computer terms, is ancient history. However, the editors at O’Reilly thought the “what and why” would be of interest to some readers, so we reached a compromise. I mentioned Forth and Delphi in the foreword and gave simple instructions to search for them along with my name, Greg Stevenson, if readers were interested in knowing more. This post is the promised explanation.

The Forth language was most popular in the late 1970s and 1980s. (I still have my August, 1980 issue of Byte magazine where Forth was on the cover.) At that time, most microprocessors had very little memory, and memory was very expensive. Memory became “cheap” when 2K static RAM chips dipped below the $50-per-chip mark. Even if you had money, most systems were limited to no more that 64K. In those days, there were basically three main programming approaches. The first, Assembly language, was typically considered the fastest and most space efficient, but coding in it was extremely tedious, and it was very hard to debug. The second approach was interpreted languages such as BASIC. These were interactive, so writing and debugging were fairly easy. But they consumed a lot of space and were extremely slow because everything was interpreted. It’s sad, but because comments (REMark statements) were runtime commands, the quickest way to speed up a program and get back valuable memory was to remove them. The last traditional approach was compiled languages. C was the most popular, but there was also Pascal, Fortran, etc. These languages were easier than assembler, but almost as tedious. Their speed was better than BASIC, but because they typically linked in entire libraries, they consumed a lot of memory.

Enter Forth. Forth was interpreted, but used a technique called Indirect Threaded Code (ITC), which was very different from a BASIC or JVM interpreter. It was much closer to machine code—and much faster. It was compiled, but not like Assembly or C. It was also unique in that it spanned the entire functional spectrum from ultralow-level assembler to ultrahigh-level domain or application-specific languages. You could easily drop in code, or extend existing data or control structures as needed. Its syntax was simple, elegant, and unbelievably powerful. The compiler and interpreter were each comprised of fewer than 16 lines of code. The Z80 assembler was about 45 lines. The entire language—assembler, compiler/interpreter, multitasker, etc.—used less than 8K of memory. Also, note that all of Forth was written in Forth.

Forth was one of the first public domain (think “open source") languages to gain traction. It was available for virtually any system shortly after it came out. Forth programmers were considered fanatics, and to be fair, some were on the lunatic fringe. However, as someone once said, Forth programmers were excited about Forth in the same way that people with severe myopia were excited about getting glasses. It felt good to stop walking into walls! With Forth I could interactively step through each part of an application, make a change to the equivalent of a function, and recompile in less than a second. And all this was in 8 to 16K of memory on 8-bit processors running at 1 to 5MHz.

Forth served me very well for about 15 years. Initially I used it for standalone applications with the primarily text UIs of the day, and then focused on embedded applications. PCs were getting cheaper and had more memory and faster processors, but embedded applications and the use of Forth allowed costs and consumer prices to be reduced even more. This trend continues today. Go to and you’ll see that Forth is still very much in use.

Eventually computers got fast enough and cheap enough that graphical UIs were practical. However, programming for them was a royal pain. Unlike embedded systems, you could not go straight to the metal; you had to use the OS and event-driven programming. Visual Basic made the process a lot easier, but it always seemed like I would get 80% of the application done, and then start walking into walls again. So it was like the old days, but with the new GUI platforms.

Let me clarify something at this point: I am very much a promoter of what works. I have switched from PCs to Macs and back to PCs. I loved Forth, but would have dropped it in an instant if something better worked for me. I always like checking out the latest language, framework, etc. and will switch if something truly warrants it. I don’t care if something is popular; I care if it works. With that understanding, let me give you some background on Delphi. When I first heard that Delphi was “object Pascal,” I said to myself, “That makes sense; I object to Pascal.” Pascal, like BASIC, was a very constraining language to me. On one hand, it was easy to teach and prevented students from doing stupid things. On the other hand, it prevented real programmers from doing useful work. Still, the buzz was that Delphi was different, so I took a closer look.

Delphi got Pascal right. Delphi performs enough type checking to prevent programmers from easily shooting themselves in the foot, but still allows shooting between the toes when necessary. I had originally planned to use Visual Basic for prototyping and then code the real project in Delphi, but Delphi’s IDE was so elegant, it was actually quicker to prototype in Delphi. Like Forth, Delphi is a gestalt. Delphi is compiled, but is single-pass and wickedly fast. The applications are also extremely fast compared to those done in Visual Basic, and on a par with those done in C++. However, 20 lines of hard-to-read C++ code can be done in about 6 lines of clean, readable Delphi code. Like Forth programmers, Delphi programmers have a reputation for being fanatical about their language. This “fanaticism” is really more like a civil enthusiasm. There is no doubt in my mind that if Delphi had started out as a Microsoft product instead of a Borland product, it would be one of the dominant three languages today. Instead, Microsoft hired away most of Borland’s top Delphi talent and created C# with it. (Borland was the best farm team Microsoft ever had.) Even with the brain drain and years of virtually stagnant development, Delphi is still the best application for developing Win32 applications. Most mainstream developers are shocked when they learn how many commercial applications are written in Delphi. Skype is just one well known example.

Now again, we are seeing another shift. Processor speeds, memory, AND transmission speeds are getting faster and cheaper to the point where mobile devices can offer what feels like traditional desktop power in a handheld device—and at a price that most consumers can afford. As I stated in the forward to Mitch Allen’s book, webOS seems to have that perfect balance for these new devices, just like Forth and Delphi did for the devices of their generations. To be honest, I’m still not keen on JavaScript as a language, but it has gotten progressively easier to use in the last 10 years. And it makes a lot of sense in the webOS framework. In any case, there’s a lot to like in webOS, and if my track record holds true, it should be a great platform for at least 15 years.

Even so, I’m still looking for something better…

Giving Back

Southern California Quality Assurance Association

SBS is proud to provide web design and hosting services for the Orange County chapter of the Southern California Quality Assurance Association. Our founder, Greg Stevenson, is a charter member of the group which was started over 10 years ago. The mission of SCQAA-OC is to promote the sharing of information relating to software quality practices, principles, concepts, and methods for the betterment of its members and their companies. In addition to enabling sharing through meetings, seminars, and workshops, SCQAA-OC also reinforces software quality and testing practices through educational meetings, and sponsors software quality events throughout Southern California.


preDevCamp is a not-for-profit software development gathering being held on August 8, 2009. Its purpose is to help local developers share their knowledge in developing Palm pre applications using both traditional web standards and the Mojo SDK. The event is currently being planned in over 60 cities around the world. Sierra Blanco Systems team members are the organizers for preDevCamps in Orange County, California and in Sumy, Ukraine. SBS founder, Greg Stevenson, is one of three preDevCamp global organizers. We encourage you to click the link above to register for the camp nearest you.