What is your opinion about self-hosting (i.e. writing the parser/compiler in its own language)? Is that really desirable, or even necessary, or just a gimmik (I know what Wirth says, wonder what you think)?
back
4 comments
(Not Walter but) Self-hosting in a compiler should be done wherever possible - if we ignore that if the compiler self-hosts it becomes it's own test suite (writing tests is good but it's quite difficult to find weird behavioural bugs using unittests if the tests only test one thing at a time) - it makes it so much easier to work on the compiler (For example, the main D compiler can build itself in a second or two on my machine - if I had to cart around some other huge toolchain it would be much slower). Another boon is that, if people who are really good (let's say) Go programmers want to make the Go compiler better they then don't have to try and write go in C++ if the main compiler is written in C++.
Also, it can also be a plan to rush to a MVP, rewrite the MVP in your language and go from there. This has the added benefit of giving you a decent sized program in your language at no extra cost - aside from testing this should make you design a better language as you learn what works at what doesn't in the "real world".
It's not always possible (Please don't write a compiler in Javascript, or even C if possible - pain and lack of abstraction respectively).
Yes on all points. I'll add that I invented D because D was the language I wanted to write code in. The D compiler was originally written in C-with-Classes, and it became increasingly irritating for me to have to be working in that language rather than D. Thankfully, the DMD compiler is now 100% in D and I've been slowly refactoring the code into much more pleasing forms.
Contrary opinion to the others: In almost all cases, don't bother self-hosting the entire compiler. At least not if you want an end result that optimizes nicely and can generate code for a wide range of architectures. That's a lot of work, and you're better off targeting an existing compiler framework (ahead of time: GCC or LLVM; JIT: the JVM or the CLR; in both cases there are probably other good choices as well). Of course if you start your project with "I wonder what an X compiler in X would look like", you will self host your hobby project end to end. But if you are trying to make something that is maximally useful for others, use the already existing stuff that is out there, and that is much better than what you would pull off on your own.
As for the parser, it's probably true that for many languages, self-hosting the frontend may be attractive. For others it might not. Someone else wrote: "if people who are really good (let's say) Go programmers want to make the Go compiler better they then don't have to try and write go in C++ if the main compiler is written in C++", which is somewhat true. On the other hand I once had to do stuff in the gfortran frontend, and I was very happy that it was written in C and not Fortran, because I know C but don't know Fortran. So I guess as long as your language is niche among people likely to be compiler developers, the point about attracting that talent doesn't hold. If your language gets popular enough, self hosting the frontend should become more interesting. Before that it's more of a gimmick.
If it is a general purpose programming language, this should always be done.
Not necessary at the beginning, but eventually as the language gains mindshare.
It is very hard to understand the language, if all contributions to improving it are done in another language.
Somehow it is similar to being a library author without having ever written a full blown application using the library, thus being blind to what are the possible usability issues.
I think it depends on the language. If you're writing a language that is targeted toward systems programming, yeah, it's probably a good idea to write a compiler in it. But what about languages that are targeted differently? Should people be writing parsers/compilers in CSS or SQL? Probably not a top priority there.