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?
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:
Into closer consideration got these:
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.
There are as many answers to that question as there are language implementers. Some of the reasons include: