Stack OverflowWhat kind of knowledge do you need to create a new programming language?
[+61] [24] systempuntoout
[2010-04-04 20:36:11]
[ language-agnostic compiler programming-languages ]

I've just finished reading " Coders at works [1]", a brilliant book by Peter Seibel with 15 interviews of some of the most interesting computer programmers alive today.
Well, many of the interviewees have (co)invented\implemented a new programming language.
Some examples:

It's without a doubt that their minds have something special and unreachable, and I'm not crazy to think I will ever able to create a new language; I'm just interested in this topic.

So, imagine a funny/grotesque scenario where your crazy boss one day comes to your desk and says, "I want a new programming language with my name on it. Take the time you need and do it."

Which is the right approach to studying this fascinating/intimidating/magical topic?

What kind of knowledge do you need to model, design and implement a brand new programming language?

(16) Everything seems difficult until you take the time to understand it. Try being curious instead of afraid. The basic concepts of this topic are not as hard as you think. You have the advantage of TONS of reading material and knowledge that those language authors didn't. Not to mention SO ;) - Kai
You are right; but you know, inventing a new language is one of this thing that since university you consider like "magic". - systempuntoout
(5) Community wiki? - ChristopheD
(1) @Kai, @systempuntoout: I use SO too for my programming language development, and the programmers here react very good on it. Also some very, very, useful comments for improving stuff, which you can't learn from books or resources. - Pindatjuh
(4) Intro to compilers is an undergrad course. Writing a new language is non-trivial, but not especially hard. Writing a new language that anyone will want to use, however... - dmckee
(1) I just want to mention that the book Masterminds of Programming is very similar, and "features exclusive interviews with the creators of several historic and highly influential programming languages." - Bill the Lizard
@Bill the Lizard many thanks for book recommendation. - systempuntoout
Also Josue Block had a big participation on the shape of Java core libraries. - OscarRyz
The correct spelling of his name is "Joshua Bloch" - Don
@systempuntoout - Please flag this when you've finished editing. It has been collecting flags and really needs to be locked again. - Tim Post
[+51] [2010-04-04 22:01:38] Jakob [ACCEPTED]

I too think that writing programming languages shouldn't be something you take on as an attempt to create the next Erlang or JavaScript. Yet, I find it to be a great exercise for the mind and once you start thinking about languages a lot, you find that:

  • You start realizing what's wrong with existing languages.
  • You discover what's great with existing languages.
  • It becomes even easier to learn new ones.

For my own part I've implemented a subset of JavaScript with a few improvements and also another language with a single datatype (the bit) and a single operator (nand) for proving low-level ideas, as well as a couple of DSLs for templating and more specific code generation.

So, on to what I think you should read about:

  • Lexer: Transforms a stream of characters to a stream of tokens ("class", "int", "{" and "++" are typical tokens)
    • Requires knowledge in: Regular expressions.
    • Implementations: There are lexer generators in most languages; Lex for C, Alex for Haskell, ANTLR or JLex for Java, GPLEX for C#, etc.
  • Parser: Transforms a stream of tokens into an abstract syntax tree (AST).
    • Requires knowledge in: ASTs, finite state machines, context-free grammars, Backus-Naur Form.
    • Implementations: Just like with lexers, there are parser generators in most languages: Yacc for C, Happy for Haskell, ANTLR or CUP for Java, GPPG for C#, etc.
  • Generator: Transforms an AST describing your language to an AST of the target language.
    • Requires knowledge in: The target language and/or platform (assembler, C, JVM, CLI or another of your favourites).
    • Implementations: Compared to the other steps, this is where you'll have to do alot yourself. Get started by looking at what other people did. CoffeeScript ( would be my suggestion, it's both cool and quite simple.
  • Optimization: Transforms the AST you produced into a more optimized one
    • Requires knowledge in: Once again, a fair amount of understanding of the target platform. There are lots of algorithms to wrap your head around, depending on how deep in you want to go.

There's a nice tool called BNFC (Backus-Naur Form Converter) developed at my university that can give you a kickstart into the lexer and parser parts. If you'd like to get something up and working quickly I'd recommend it very much. It's a little more limited that using lexer/parser generators directly, but very productive. You'll find it here:

All of this aside, you should of course learn as many radically different programming languages as you possibly can. All of C, Erlang, Haskell, Prolog, Lisp and Javascript have contributed greatly to widening my own ideas of programming languages. Unless you know them all, pick one and start hacking ;)

And oh, my main advice would probably be to focus on writing lots of imaginary code in your own not-yet-existing language before hacking away too much with an implementation. This works like a spec; it forces you to think about what the language should do, why and how it will feel to use it.

By the way, I too finished reading Coders at Work a couple of days ago. It was a really great read, I'd recommend it to anyone!

(5) Just for the record (once again) there is no need for any stage of the compilation process to create an explicit tree of any sort. This is exactly the kind of answer you would expect from an undergraduate student who has taken one course on compiler writing. - anon
(7) Just to clarify; most of this answer is in regards to implementing a language with a compiler, as opposed to the designing of a language. - Graphics Noob
@Graphics Noob Could you elaborate a little bit? - systempuntoout
(4) My answer was my two cents on where to get started in a practical sense; what the process of a compiler (can, but doesn't have to) look like, techniques to read about and tools to use. If it sounds like beginner stuff, then good, it should! It's written for beginners. Regarding design as opposed implementation, yes, designing a language requires a different set of skills than my list. My basic suggestions still is to learn different language paradigms and trying to express ones own language with some code. Of course there's more to it and I'd love to ramble on the design subject as well :) - Jakob
[+23] [2010-04-04 23:39:32] ewernli

A programming language is about a set of abstractions that you use to express a meaningful program. The question is: what abstractions should the language provide? I don't think it is about compiler, lexer and parser.

The beauty of a language comes form the "less is more": a relatively small set of abstraction should be able to be combined to program great libraries, framework and ultimately end-user programs. (Individual abstractions sometimes don't fit with each other, or may even conflict. You will need to decide carefully what goes in or not.)

As C.A.R. Hoare indicates in his famous paper "Hints on Programming Language Design" there are two views on language design:

  • Part of language design consists of innovation. This activity leads to new language features in isolation.
  • The most difficult part of language design lies in integration: selecting a limited set of language features and polishing them until the result is a consistent simple framework that has no more rough edges.

1. What will make your language special?

You need to have a vision about your programming language and what it should do. What are the strength and weakness of your language? In which area do you want it to shine (there should be at least one that is the main driving force of your initiative)?

Here is short list of driving forces to consider:

  • Simplicity - A language with few abstraction is easy to grasp, but may be limited, e.g. don't expect to do pattern matching in Smalltalk. On the other hand, too many abstractions kills it as well.
  • Modularity - How do you deal with modular development, name clashes, isolation of components, etc.?
  • Composability - How do the programming language favors/impede composition? E.g. pure functions can naturally be composed, while object can't. Transactions (with transactional memory) can be composed easily, while locks can't.
  • Safety - How safe is the programming language abstractions? Can you break encapsulation in some way, e.g. if you have meta-programming facilities? Can you provide safety guarantee, e.g. with a type system?
  • Expressiveness - How easy is it to use the abstraction to express solution to some problem? Does expressiveness conflict with readability?
  • etc.

2. Abstractions in your language

When you have a vision about your language, then you can start shaping the abstractions that will support it. For instance, Scala's vision was "Let's blend function and OO" so they designed abstractions such as case class. NewSpeak's vision was "Let's make modules a first-class abstraction", so they pushed the concept of nested class to the extreme.

There have been a lot of abstractions proposed to design programming language. To design a new language, you should know a lot of them and decide how your programming language will compare against others. (Read the ECOOP or OOPSLA papers of the last decade and you will get an overview :) Here are few:

  • Object
  • Class
  • Function
  • Trait
  • Type system
  • Scoping/modularity abstractions
  • Extension mechanism (e.g. open class, extension method)
  • Security mechanism (e.g. class sealing, final)
  • State manipulation abstraction (mutation, freezing, immutability, transactions)
  • Pattern matching abstractions
  • Exception handling abstractions
  • Representation independence abstractions (e.g. properties/slot)
  • Meta-programming abstractions
  • and a lot more to come ...

3. What you need to design a programming language

To create a programming language, you probably need (1) a vision and (2) a set of tools to implement and experiment with your design, e.g. parser generators (3) formal background for certain area such as type system.

But more important that everything else, I guess you need hard work and passion :)

EDIT: I've added C.A.R. Hoare quote at the beginning.

(1) Thanks for your detailed answer! - systempuntoout
[+15] [2010-04-04 20:48:48] ChristopheD

For starters you would need to know exactly what it should be able to do differently (or better) (and why) then all the languages which are available today.

Some of our best tools available today arguably grew out of frustration with the tools at the time they were conceived / invented.

(3) I think "need" is a bit strong here. I think it's perfectly valid for someone to try to design a language out of curiosity or as a learning experience. It doesn't necessarily have to be better than all other languages out there. - Bryan Oakley
[+9] [2010-04-05 04:22:20] Norman Ramsey

What kind of knowledge do you need to model, design and implement a brand new programming language?

If you just want to try out a new language idea, you need some knowledge of

  • Abstract syntax
  • Concrete syntax and parsing
  • Formal semantics, typically operational semantics or denotational semantics
  • Definitional interpreters

And depending on your language idea you may also need to know something about

  • Static type systems

These topics are covered at an appropriate level of detail in Friedman and Wand's book Essentials of Programming Languages [1]. It's a good book. For somebody designing and building a new language, it's much better than the Dragon book, because it's about languages, not compilers.

It will also help you enormously to be familiar with a wide spectrum of existing languages, so that instead of having to reinvent everything, you can steal the parts that have been done before, thereby making it easier to focus your own energy on whatever makes your language new and special. Remember: talent imitates; genius steals. You want to steal from the very best designs, and that means you have to know something about them.

If you write your definitional interpreter in a language like Haskell or ML, you can build something interesting very quickly. I especially recommend Haskell because you can take advantage of "parsing combinators" to deal with concrete syntax—very civilized.

If, on evaluating your idea, you decide you want your implementation to run at native-code speeds, you have a whole host of other stuff to learn. But Icon, Lua, Perl, Python, Ruby, and UCSD Pascal all enjoyed considerable success in their day without necessarily having native-code compilers.


@Norman thanks for your answer - systempuntoout
i'd like to second the recommendation for EOPL, it's a splendid book. - Allen
[+7] [2010-04-04 20:45:50] Blair McMillan

Knowing more than one existing programming language would be a good start. Even if some of them aren't programming languages per se, the different ways that they do things would be helpful for deciding what you do/do not want your language to do.

I'd suggest knowing a variety of existing programming languages, not just two. C, Lisp, Haskell, Prolog, and Perl should make a good mix to start with, although there's obviously many other excellent mixes. - David Thornley
Wasn't that what I was saying? - Blair McMillan
More or less, although "more than one" didn't seem strong enough to me. - David Thornley
[+7] [2010-04-04 20:49:58] anon

You need to know that your language is almost certainly doomed to obscurity and failure. I would guess that 99% of programming languages are never used by anyone except their author. If you can live with this, developing one is fun. Speaking as an author of several (doomed, obscure) myself.

Interesting, could you expand on which languages those are (if they are googleable)... - ChristopheD
@ChristopheD They included a FORTH like language, a text adventure writing language, and a C-like language. All vanished without trace. My latest language that no-one is using is an attempt at declarative data generation, which also hasn't worked out too well - this is available for inspection though at - anon
Brilliant answer, thank you!Could you elaborate ,from you experience, what are the most important things to study and which is the best approach to this subject? - systempuntoout
(2) @systempuntoout "read a lot of books, be clever, and get lucky" would be my approach. I would also add "stop web surfing and start coding" as a codicil. - anon
@Neil Butterworth: Did your text adventure language at least get to the IF archive? - David Thornley
(1) @David Afraid not. This was back in the 80s (it was the project I used to teach myself C++) and this interweb thing didn't really exist then. - anon
@Neil Butterworth: The question isn't "what must I do to create a successful language". It is more simply "what must I learn in order to be able to create one". Telling someone not to learn how to do something because the project will be doomed doesn't help answer that question. - Bryan Oakley
[+6] [2010-04-05 00:57:42] SHiNKiROU

I think you should learn more mainstream programming languages before you make your own. You should try to understand code snippets written in programming language that you did not learn. (if you learned C++, you should be able to understand Java code without learning Java)

Programming language design knowledge is very important. You must know what is the point of making (and using) a programming language. (left as an exercise to the reader, hint: why we don't program Assembly, why we are not Real Programmers?)

(note: the key topics mentioned are in bold, you should Google them for tutorials)

After you gathered ideas, then learn how to parse. Regular languages and formal language theory are musts. Also, learn about lexers such as lex and also learn how to tokenize without a lexer. A tokenizer splits a code to labeled chunks from

function factorial(n) {
  if (n == 0) { return 1; }
  else { return factorial(n - 1) * n }


[FUNCTION function] [IDENT factorial] [LEFT_PAREN (] [RIGHT_PAREN )] [LEFT_BRACE {]
[IF if] [LEFT_PAREN (] [IDENT n] [EQ ==] [INT 0] ... and so on

After that, learn about context-free grammars and parser generators such as yacc and JavaCC. A parser checks if tokens are places properly according to the set of rules ("grammar") and deal with them.

For example, a while statement is defined as "a while keyword, a left paren, an expression, a right paren, a block." You must transform it into a context-free grammar.

WhileStmt := WHILE LEFT_PAREN Expression RIGHT_PAREN Block

(Expression and Block defined separately) And a parser generator transforms them into a source code that deals with the tokens.

By this time, a good exercise for you is to write a calculator program.

Beyond that, you should learn about abstract syntax tree (AST) generation and interpretation of ASTs. In Java, the tree generation tool is called JJTree. Make a formula calculator [1] with your knowledge.

After you mastered making interpreters, learn how to make compilers, and the fun part: bootstrapping: learn how did a Java compiler was written in Java.

I made a LOGO ripoff as an example:

Also check my own calculator:

And a simple reverse polish notation calculator (Turing-complete) that I made without any effort:

I think you don't need a computer science degree, since I'm grade 9 and I am still able to create a programming language. Google and self-study.

Sorry if my English is too weird, I said I'm grade 9 and I'm not a native English speaker.

Here are some links to some useful resources and examples:


Thanks to have shared your experience :) - systempuntoout
I think it would be better to study (not necessarily learn) a few non-mainstream languages in addition to the mainstream ones. Study LISP or Tcl, erlang, languages like that. Python should probably be on that list since it has a non-traditional way of detecting blocks of code. - Bryan Oakley
[+6] [2010-08-20 13:37:58] Stephane Rolland

The site I think you absolutely must go to is Ltu - Lambda The Ultimate [1]

It will helps you confronting yourself to several other paradigms. And reading other language inventors.

Go ahead !


[+5] [2010-04-04 23:27:01]

Well .. i wonder why no one mentioned the Dragon Book [1]


(2) Because it is pants? - anon
@Neil What does "it is pants" mean? - Josh Stodola
@Josh UK English for "not very good" - anon
@Neil Then I would have to disagree. It's a fabulous book and teaches you everything you need to create a programming language. - Josh Stodola
(3) @Josh, Dragon book teaches you some basics you need to implement a programming language. But designing a language is completely out of its scope. Actually, there is no decent textbook on how to create a language. - SK-logic
@SK-logic: I suspect there never will be a good textbook on how to create a new general-purpose language. There are books, I believe on how to create domain-specific languages, but that doesn't seem to be what the OP was looking for. - David Thornley
(off-topic) @Neil: So for example, if I don't like the pants you're wearing, I can just say "Neil, your pants are pants!"? - Cam
Right- there's a big difference between implementing a language and designing one, just as Frank Gehry's contractors aren't going to be able to design another skyscraper just because they know how to organize a lot of concrete pouring and welding. - Ben
For designing a language, you should read books on programming theory and type systems. I would personally start with Structure and Interpretation of Computer Programs and move onto Concepts, Techniques and Models of Computer Programming and go from there. It would also be good to learn multiple languages from the main paradigms - the different paradigms (at least imperative, functional, OO) so that you know whats available and multiple languages because even within a paradigm, different languages will do things differently and you should have a good idea of whats available. - Dan
[+4] [2010-04-25 23:02:05] Artium

One skill that might help is being a Scandinavian ;)

(6) I've read that beards are at least as important. - David Thornley
[+3] [2010-04-04 20:46:36] Chuck

Writing a programming language, by itself, is not all that out of reach [1]. Creating a good one is much harder. I think the best thing to learn first would be a good understanding of the history of programming languages — what's been tried, what's worked, what's failed. Armed with that, you need to know how your language is meant to be used so you know what design suits that best.


[+3] [2010-08-26 08:12:29] ZXX

To actually invent new programming language the most important knowledge is about the field where that language will provide more natural and/or better expression of problems and solutions.

Most of the people you listed, and many others credited with authoring a programming language that became popular, had very limited knowledge about actual parsers, let alone compiler writing techniques - as evidenced by a lot of awkward syntax which happens when you know what you want but noit how to do it well - so you do it the way you know at that moment.

What they did know however was "their" field - what was itching them, things they needed to exprees in order to feel that it's more natural or easier to use. Thye mostly started just by ripping off whatever they found that was close enoguh to their ideas and wasy enoguh to get into and tweak. Everything else came latter.

You can invent something that is pretty much a new programming language without even writing any parser or compiler - take JQuery as example. The reason why you see so many functional-something languages is that they have virtually no parsing needs that are not already provided. You could literally write your own sub-language in Haskell without ever knowing how real parser works.

Bjarne Stroustrup has been quoted saying that he wish he used recursive descent parser for C++ - which is the lamest parsing technique in the universe. Why? Because it would make his life easier and allowed him to spend most of the time on what he really wanted to do - make a new language :-)

interesting answer, thanks. - systempuntoout
[+3] [2010-11-12 12:11:09] gath

Good question... There is this book i have, and every time i try reading it my head spins like crazy! One day i'll crack it i promise.

its all about languages and how to build one.

Programming language Pragmatics- Micheal .L. Scott [1]

Btw, am reading "Coders at work" really nice book.



added to my wishlist, thanks - systempuntoout
[+3] [2011-01-07 15:19:55] Ben

A lot of the sense of magic (of the incomprehensible variety) will change to a sense of magic (of the wonderful and elegant variety) if you work through, say Chapter 4 of the Wizard Book (Structure and Interpretation of Computer Programs - freely available from MIT online, btw.). There, you implement a metacircular evaluator, as well as two other variations on the theme. Meaning, in essence, you'll have built three languages-- not from scratch, but you'll see what a language is.

And then you can move on to the last chapter of the book, and then to EoPL, and the Dragon Book and LtU, and reading the specifications for your favorite languages, and contributing to those languages (because they're obviously open source, right?) and before you know it, you'll actually have ideas about what you'd want to do in your language, why there it'll do something new and useful, or better than the others, or whatever it is that makes it something you want to build.

[+2] [2010-04-04 20:44:19] el.pescado

You need to know theory of formal languages and grammars in the first place to know what is context-free grammar (most programming languages have context-free grammar). Then, you need to know something about compilers. It's good to know tools like Lex and Yacc and things like Backus-Naur form.

EDIT: I think MSc degree in Computer Science is a good starting point;)

I have a CS degree and i know it's a good starting point :); but, to invent a new language, you need more.Probably a Phd on the subject, and time.... - systempuntoout
(7) @system: formal qualification (like a piled higher and deeper) have nothing to do with it. Not even the bacheloriate is necessary. It's the deep knowledge of what is wrong with existing language and what is possible for fixing it. The long study involved in getting an advanced degree is one route to obtaining what is needful, but not the only one. - dmckee
@dmckee Uhm, i'm talking about time.At university\phd you have time to learn and focus.Now working 10hours a day, imho is more difficult to start a project like this. - systempuntoout
(1) @dmckee: even so, a university compiler course will come in very helpful if you actually want it to be a working language and not just a specification. - Callum Rogers
@el.pescardo: I don't think this answer is true. Many years ago I decided to create a domain specific language (though that term hadn't been invented then, I don't think). I knew nothing about formal language theory, grammars, etc. I just dug in to the lex and yacc man pages and started hammering away. It was a fabulous experience and taught me a lot. All I really had was a burning desire to do it. - Bryan Oakley
[+2] [2010-04-04 21:26:27] Nick Dandoulakis

Domain specific knowledge could help to design a language to solve problems that arise in
that domain. A big collection of use cases, problems and solutions so that you have a good picture
of the space problem. That kind of knowledge is needed, how to actually implement the language
is of secondary priority IMHO.

[+2] [2010-04-04 22:24:50] Jørgen Fogh

Designing a good language is as much an art as a science. I am interested in the subject myself and I am taking every course on languages at my university. However, what I have learned in school is simply a set of tools. Knowing about type systems and operational semantics would not have helped Yukihiro Matsumoto [1] design Ruby [2] and I suspect that he did not have much formal training in language design when he began.

I think the best way to learn about language design is to learn as many different languages and paradigms as possible and to learn them well.

Disclaimer: I have written a couple of compilers, but I am still a novice when it comes to actually designing languages. And probably when it comes to writing compilers too ;-)


(4) All praise to Matz, but the "design" of Ruby consisted of only two steps: (1) rip off Smalltalk and (2) throw in a few bits from Perl. It's good to steal from the best, of course... - Norman Ramsey
(4) @Norman: A great artist knows exactly what to steal. Ripping off Scheme and throwing in a few bits from COBOL wouldn't have worked nearly as well. - David Thornley
(4) @David: All too true! And ripping off Smalltalk was a truly brilliant stroke, because the Smalltalk people deliberately cut themselves off from the OS. Using Smalltalk is like this: you get to live in a really great house... but it's on Mars. Having a similar house on Earth is a huge win. - Norman Ramsey
[+2] [2010-04-05 10:18:24] leppie

A firm understanding of denotational semantics [1].


[+2] [2010-04-27 21:19:23] Grumdrig

I've had occasion to create perhaps as many as eight or ten little languages in my own professional career (in addition to various others for my own purposes/enjoyment). It's sometimes the best way to solve some domain-specific problem. Reference, for example. [1]

It's not particularly miraculous or difficult. In general, the you'll do it because there's no existing language that exactly fits the bill; without that motivation, you can't really expect to be able to design some awesome language, essentially in a vacuum.

So the next time you need one, write it. Nurture it, and let it grow. (Both the language, and your beard.)


Thanks for book recommendation :) - systempuntoout
(1) I finally shaved my beard two years ago, it made me look really old... - Stephane Rolland
[+2] [2011-01-07 09:02:35] Sandman

I think that one possibly good way to start would be to try to implement a small DSL using Xtext [1] or something similar. Start with something concerning a very small domain. Then, later on, work on a language concerning a larger domain. After a while, you should have no problem implementing very complex languages, and not just DSLs, but GPLs as well.


[+1] [2011-04-01 00:54:58] joeld

A good approach is to try and write a "toy" interpreter or compiler for your favorite language. That way you can learn about how to implement a language without getting bogged down in language design, and you have the existing grammar to start from with and plenty of test cases. While it's a huge project to design a "industrial strength" compiler or interpreter, it's pretty easy to write something than can compile or run a limited set of test programs.

Then, you just ask yourself, "how can I make this better"?

[+1] [2011-04-01 02:17:39] Andreia Gaita

In 2006, the organizers of the ICFP [1] came up with an awesome task that involved you figuring out how to decode and parse a language they created - or rather, an alien programming language found in ancient scrolls ;)

Besides the million hours of fun trying to figure out everything in those alien scrolls (it's like a russian doll, that thing), the part where you create a compiler for a language created for fun is a really interesting way of getting into this thing of creating languages.

The site has the source code of everything, but I recommend trying to figure it out by yourself, it's much more fun. The mailing lists are still up as well, with interesting information about the language and the contest task.


[+1] [2011-04-01 05:12:44] Jasim

The first step is the hardest - designing your language - the constructs, object orientation, type system etc. It is better to start with very simple constructs and add more as you understand the subject better.

Then write a program that does something simple in your hypothetical (as of now) language. The rest of the steps are towards writing code that will read this program and execute.

Building the implementation requires you to first build a lexical analyzer. The tried and tested route is to use tools like lex/yacc. However there are excellent parser libraries in high-level languages like Ruby/Python and Java. Ruby for example has the awesome Treetop [1] library which uses PEG [2] to describe languages. For a beginner, it would be much better to use one of these languages since they help you focus on implementing your language than debugging weird memory allocation bugs in your C code.

Once you've an AST [3] built for your language, try building an interpreter for it. If you're using a high level language, you could loop through the AST and call routines in your host language for getting the desired functionality.

This approach will yield you a slow interpreter - but you'll have a new language with an implementation. And as you get better in the craft, you can change gear and add code generation [4] and make it a compiled language.


[0] [2011-04-01 00:08:10] Charlie McHenry

Ping Rich McConnel or Brian Russel if you can find them. Authors of Clipper, they turned a compiler into a full-blown programming language with Clipper 5.0 back in the day. Brian was fond of saying, you could write Clipper in Clipper.

Or Rick Spence! - Jasim