{"id":4509,"date":"2020-01-26T04:18:44","date_gmt":"2020-01-26T04:18:44","guid":{"rendered":"http:\/\/mathscitech.org\/articles\/?p=4509"},"modified":"2024-01-01T10:36:26","modified_gmt":"2024-01-01T10:36:26","slug":"pol","status":"publish","type":"post","link":"https:\/\/mathscitech.org\/articles\/pol","title":{"rendered":"Forth, Lisp, & Ruby: languages that make it easy to write your own domain specific language (DSL)"},"content":{"rendered":"

Before domain-specific languages (DSLs) and REPL environments (read, execute, print, loop) became fashionable, computing pioneer Charles (Chuck) Moore had built, by 1968, what he viewed as the perfect computer programming language, which he named FORTH (for fourth generation language)<\/a>. What he had kept in view during its creation was an extreme austerity in syntax and structure as he searched for the minimalist system required to interact with a computer and be able to write custom problem-oriented languages<\/strong> to solve them. This approach is what he considered to be “programming”: you solve your problem by developing an application specific language with multiple levels of abstraction giving you in the end a small dictionary of simple words (in code) which represents the solution cleanly and in overall the fewest lines of code. Let’s look at this idea, how it has worked out over the years, and how you can apply this, regardless of the language you choose to (or have to) work with. This article looks at Forth, Lisp & Ruby, language that make it easy to solve classes of problems by writing your own DSL, i.e. by programming a specific “problem-oriented language” in which to solve your problem.<\/p>\n

<\/p>\n

1. Succinctness is Power<\/h3>\n

Paul Graham<\/a>, the well-known founder of Y Combinator, wrote “Succinctness = Power<\/a>” in 2002. A few quotes are noteworthy:<\/p>\n

“[Power] is directly proportionate to succinctness. Certainly succinctness is a factor in readability, in the mathematical sense [that] total effort = effort per line x number of lines. (We have to be careful here to distinguish between the readability of an individual line of code and the readability of the whole program. It’s the second that matters.)<\/em>”<\/p>\n

“To the user encountering the language for the first time, a programming language that has high readability-per-line means that the source code will look unthreatening<\/em>. … [But] this is similar to the very successful technique of letting people pay in low monthly installments instead of frightening them with a high upfront price. [But] installment plans are a net loss… the buyer is going to make a lot of those low, low payments; and the [similarly] programmer is going to read a lot of those individually readable lines.<\/em>” (Paul Graham, 2002, Succinctness is Power)<\/p>\n

Larry Wall, creator of Perl, says something similar when talking about Java, in his 2013 interview<\/a>: “Java is sort of the Cobol of the 21st century … It’s kind of heavyweight, verbose, and everyone loves to hate it … But managers like it because it looks like you’re getting a lot done. If 100 lines of Java code accomplish a task, then it looks like you’ve written 100 lines, even though in a different language, it might only take 5 lines. It’s like, you can eat a 1-pound steak, or you can eat 100 pounds of shoe leather. Though you feel a greater sense of accomplishment after the shoe leather, maybe there’s some downsides.”<\/em> (Larry Wall, 2013)<\/p>\n

What of Python? Paul Graham again: “Python’s goal is regularity and readability, not succinctness.<\/em>” (PG\/2002).<\/p>\n

2. Lisp… and Forth<\/h3>\n

So what is more concise and more powerful? Paul Graham’s destination is Lisp, and he describes why in “Revenge of the Nerds<\/a>“: “Lisp was a piece of theory that unexpectedly got turned into a programming language.<\/em>” (PG\/2002b) Or, to expand a bit, Lisp is more powerful and succinct than most modern languages because it was developed as math, not as a language. Its designer, John McCarthy<\/a> (MIT), came up with it as a simpler form of a universal Turing machine, but did not imagine it would be implemented: his graduate student Steve Russell wrote it later in IBM 704 machine code. <\/p>\n

If Lisp is good, then Forth is better. All the power of Lisp, due to its extensibility and recursiveness, all of this has been consciously built into Forth by Chuck Moore, who learned Lisp and APL from McCarthy at MIT, programmed with Fortran at SAO, Algol at Stanford, and Cobol at Mohasco. <\/p>\n

Where Lisp is the embodiment of an academic paper, Forth<\/a>” is the working toolset of a master programmer<\/a>, a programmer with a severely minimalistic mindset, and who has been sharpening his toolset for 40 years<\/strong>: it took Chuck 10 years to invent Forth<\/a> (1958-1968), another 10 years to perfect it for writing software only applications (1968-1978), after which he pursued software into silicon with Forth chips and other MISC (minimal instruction set) chip designs<\/a> (some, like the Novix, used by NASA for space satellites), tighter and sharper Forths which he used to build his own CAD tools for doing ultra efficient chip layouts, until finally arriving at ColorForth<\/a> in the 1980s. He tinkered with this through until July 2001 (the last stable version<\/a>), and which he has now used for 18 years, including for use in the 144-multicomputer on a chip, the GA144 super Forth chip.<\/p>\n

But, back to the title heading:<\/p>\n

Here is what Chuck Moore has to say about Programming a Problem-Oriented Language<\/a>:
\n“I’ve written many programs over the years. I’ve tried to write good programs, and I’ve observed the manner in which I write them rather critically. My goal has been to decrease the effort required and increase the quality produced.<\/strong> <\/p>\n

“In the course of these observations, I’ve found myself making the same mistakes repeatedly. Mistakes that are obvious in retrospect, but difficult to recognise in context. … <\/p>\n

“I’ve also been distressed at the lack of concern from others about problems I consider significant. It amounts to a general indifference to quality; a casual attitude of confidence that one’s programs are pretty good, in any case as good as necessary. I’m convinced this confidence is misplaced. Moreover this attitude is reinforced by the massive trend to high-level languages and a placid acceptance of their inefficiencies. … [To counter this, there is] a Basic Principle and two corollaries: Keep it Simple, Do not Speculate, and Do it Yourself. … <\/p>\n

“I’m going to tell you how to write a program. It is a specific program; that is, a program with a specific structure and capabilities. The next step is a problem-oriented-language, [i.e. one that is] tailored to a particular application ([one can] substitute application language<\/em> as synonymous.) <\/p>\n

A problem-oriented-language can express any problem I’ve encountered. By permitting the program to dynamically modify its control language, we mark a qualitative change in capability. In a sense, our program has evolved into a meta-language, [i.e. a language which] we apply to the application.”<\/em> (Chuck Moore, 1970b, Programming a Problem-Oriented Language)<\/p>\n

He then he goes on to describe, from first principles, why Forth is built the way it is, i.e. it is built to be the ultimate problem-oriented language, complete in 4K bytes of code. (Note this is indeed bytes, not K bytes or megabytes!)<\/p>\n

What are other examples of problem-oriented languages? There are many, but almost all of them are static, i.e. not extensible<\/em>. Only Lisp and Forth have that capability of extensibility (meta-language) out of the box.<\/p>\n

Forth, by its design, makes it easy to write a domain specific language. No need to decide on a syntax or write a parser. The Forth engine is the parser and uses the dictionary which your program dynamically extends with the new domain specific vocabulary.<\/p>\n

3. Domain Specific Languages<\/h3>\n

Looking at domain specific languages generally, examples are: graphviz, CSS, regular expressions, SQL, and parser-generator tools. These have a syntax not limited by any specific programming language, but as a consequence, one needs to treat it with a parser.<\/p>\n

What about writing a DSL in an existing language (not Forth)? In this case “you have a particular idiomatic usage of one programming language; you’re still writing in that host programming language, but you’re using only a subset of its features, you use it in a kind of pidgin way to get that same feeling as you have with an external dsl. What you want to get is the feeling that I’m programming in a language that has been specially written to write my kind of state machine, even though you are programming in the host language, for example Ruby. You still want to fool yourself with the illusion.<\/em>” (MF\/2013) Martin Fowler Fowler\/2013 (28:40)<\/a><\/p>\n

This is at the heart of what a problem-oriented language approach is.<\/p>\n

4. Programming in a Problem-Oriented Language, and a Plug for Forth<\/h3>\n

Why have we gone on this journey through history and languages? Because programming to build problem-oriented languages (or domain specific languages) is, I believe, is at the root of productive application programming, regardless of the language you choose to use.<\/p>\n

Quietly, many have chosen to work in Forth, some exclusively, and others as detoxification from a software development world which is anything but simplistic or minimalistic. (See Scot Stevenson’s article, How I came to join the underground computer cult of Forth<\/a>, (Feb 20, 2014). <\/p>\n

Forth is a language that forces this type of thinking upon you, and it is worth using until the way of thinking has become ingrained, second nature. Then one will write in this way in any language, for the better.<\/p>\n

Bernd Paysan puts it well:
\n“Forth is an interactive language… You have a command line and you can just type commands in and try them out. This is very helpful for the beginner and the impatients, and it turns out that it is helpful for everyone, especially for debugging. You don’t need to write a test program to test your program.<\/p>\n

“Forth is fast… Though it has an interactive command line, programs are really compiled to quite efficient code. Forth programs are also called “words”, since each program has a name … You call it just by typing in that name. There is no difference between words from the language and words you defined yourself, you can even define words using an inline assembler. The whole system is written this way. <\/p>\n

“In this respect, Forth is quite similar to Lisp and its descendants… [but] Forth differs from Lisp in that it doesn’t use lists, neither for calling, nor for storing multiple values. Forth uses a stack to pass data between words, and it uses the raw memory (as seen by the assembler programmer) for more permanent storage. It’s much lower leveled than Lisp, and that’s one of the reason why it is fast. It’s not only fast, the simplicity makes it very small, too.<\/p>\n

“Forth is the ultimate language for building extensions. Programming in Forth is generating higher levels of abstractions, until you have a language well fitted to solve your problem. The simplicity of the underlying system allows it to rely on it, which is important when you search bugs. The usual approach for application programming is to keep each layer simple, too. This is essential for rapid development of critical applications.<\/p>\n

“Forth is said to be an amplifier. A good programmer programs better in Forth (and he learns to program better in other languages, too, when he masters Forth); a bad programmer programs worse in Forth, and he’s spoiled when working with other programming languages.”<\/em> – Bernd Paysan, Why Forth?<\/a>, 1997<\/p>\n

Jeff Schilling writes similarly:
\n“One of the unique things about Forth (at least until the resurgence in interest in Domain Specific Languages – fueled by Ruby but arguably around for a long time) is the ability to have the source language converge on the problem space. It is a magical place wherein the syntactic sugar of the programming language fades into the background and the language of the domain emerges.<\/p>\n

“Many experienced Forth programmers have reported that the language frees them to think in terms of the solution instead of the tool, that it is expressive enough to encourage original, elegant solutions without penalty and without bending over backward. (Some have even said their use of Forth made them better programmers in other languages.)<\/em>” – Jeff Schilling, The Joy of Forth<\/a>, 2007.<\/p>\n

5. Invitation<\/h3>\n

If you haven’t tried Forth, try it. Start with Starting Forth and GForth, or with F-PC Forth within vDosPlus (an MS-DOS emulator for modern Windows machines). You may be surprised at how much it starts to grow on you, and to change how you think about applications programming.<\/p>\n

To see the results of using Forth to build real applications, check out my Turtle Logo program<\/a> with installer and source code included. It was written in 2016 in about 900 lines of Forth code using F-PC with the main program development done in spare time over a number of weeks, and then extended into a full fledged program for pre-schoolers to learn programming concepts over the next several months (my first child was the first user). To my surprise (and delight), coming back to it three years later for my second child, it was easy to continue to extend it again with minimal effort due to the tightly factored design that Forth steers toward, and the multi-layered, problem-oriented language that results.<\/p>\n

For an example using Ruby, see the Cuneiform Transliteration Parser and Sign Frequency Generator built to analyze the first known instances of writing in Uruk and Susa<\/a> c.3500 BCE (nearly 5500 years ago!). Watch this space for that article (forthcoming).<\/p>\n\n

Related Articles<\/h3>\n