Do you write the first compiler in another programming language? And the fully rewrite the compiler once the first compiler is mature enough to produce reliable builds, compile the new compiler on that first compiler, in order to have a compiler that is written in the same language as the one it’s compiling?
If this is the case, and this might be a stupid question, why would want to? You’ll essentially be throwing away potentially years of work on that first compiler just to have a circularly compiling programming language? What benefits could this have to make the extra effort worth it?
You don’t spend years building that first compiler. You make it very minimal. Then you use a really minimal version of your language to develop the compiler for a slightly more powerful version of your language. Which you then use in turn to make even more powerful versions. The very initial compiler would probably take a single talented programmer less than a week to make.
Bootstrapping software tends to be awkward sometimes. On old DEC machines the manual suggested to enter a program by hand, via switches in the front, that would load a program from the (hole punch) tape reader that would then load a program from the tape reader in a more space efficient way :D
Many languages don’t bother, there are even operating systems that can’t compile themselves. Also you don’t need to throw the initial compiler away since it can be used to bootstrap from source on new platforms. (If you need that for whatever reason)
Yeah, there’s no way around writing it in a different language first (or by manually typing out the 0s and 1s), because you need an executable program to do the compiling.
As far as I’m aware, the main benefit is ‘dogfooding’, i.e. actually using the language that you’re creating, in at least one larger project.
Another big advantage is that people who would consider contributing to your compiler are most likely to know the programming language that they’re trying to compile, not some random other language.
Drew devault is currently writing a systems programming language and i learnt a lot from that. For instance, a bootstrap compiler written in C is useful for packaging and adapting the new language to a new processor architecture or similar things.
- We are building a new systems programming language
- How to design a new programming language from scratch
- Parsers all the way down: writing a self-hosting parser
- Tips for debugging your new programming language
The language is somewhat “in the public” but Drew asks that it remains a secret until it is more mature.
Also interesting is this thread on the alpine linux devel list regarding self hosted compilers like rust. In essence, rust is difficult to package, because you need rust to compile rust.
Having never written a compiler I would use whatever language I liked best to do it. I’d try to use as many libraries as possible to start and if the language finds a niche I’m sure someone would come along and write a better compiler.
My main question to ask back to you would be why do people create new languages? There are so many I would think that for any given problem space, it would be more efficient to survey all of the existing languages than to write a new one.
I mean, superficially there’s a ton of languages, but if you start having requirements, you quickly get to the ground of it.
At the start of this year, I was looking for a language for a project where I basically wanted operations folks to write that programming language in order to configure their deployments.
As sort of base requirements I had:
- compiled, statically typed
- strong typing with sum types
- readable, high-level, powerful enough to define nice interfaces
Into closer consideration got these:
- Wren -> not actually statically typed
- Zig -> too low-level
- V -> too immature
- Prolog -> too mind-bendy
- OCaml -> objects are kind of bolted on, stdlib doesn’t really make use of them
- Rust -> too low-level, strings are too clumsy
- Nim -> significant whitespace, no interfaces/traits, Python-esque imports
- Haxe -> Generates code in other languages which is hard to debug
- Scala -> need to also know Java to use libraries, need JVM on target host
At the end, I went with Scala, but I’m currently battling that JVM requirement (trying to compile native binaries with GraalVM) and mostly losing, so it’s certainly not ideal either.
I should probably add, though, that obviously at the end of it, I did not write a new programming language. That is still a rather large endeavour. But I certainly considered it.
Even just a Rust pre-processor might solve some of my problems, but would probably create new problems, too.
My main question to ask back to you would be why do people create new languages?
There are as many answers to that question as there are language implementers. Some of the reasons include:
- People simply don’t know how massive and diverse the language community is.
- People want to do it as a personal challenge. (That was my reason.)
- People want a language that is, broadly speaking, just like A but with feature1 and without feature2. (I suspect this is the most common reason and it leads to a phenomenon I call “OOP Heartbreakers” because the product is usually something that is largely indistinguishable from existing, established languages but has no support and thus no real hope of success.)
- People are introducing an entirely new way of looking at programming (the cringe-inducing word “paradigm” has entered the chat) which is best fostered by a different way of structuring code. (This is why we have languages like Prolog and the ML family and …)
- People have specific needs that aren’t being met by existing languages for their projects. (Ask me about my unmet needs for embedded systems programming…)
- … and a cast of thousands of others …
