|
Well, yes. He can't. I assume you already know why but, in case you don't, let me put it in simple terms for you: it's easier to create something from scratch than to extend existing code base. Have you every tried to fix a bug in or make an improvement to GCC? I did; I tried many times and I failed. Maybe it's just that I am not hacker enough (I'd say it's exactly the reason), but...
The size of the code is enormous, the documentation scarce and of limited use to new people - sort of like with man(1) pages: if you already know what you're looking for they're great, but if you don't and need real help then I'm sorry, but tough luck.
You'd better know where to look for parser, optimiser, code generator, etc. and how they interact with each other; where to get information about source code you're translating (keep in mind that there are "new" and "old" ways, and for some constructs only one is available). Unless you have tons of time on your hands (don't have to work, or are lucky enough to go to a University which has some people working on the code), or work for one of the companies developing GCC then you have pretty slim chances of actually getting through. I don't know how it is with LLVM/Clang. Maybe there it's easier to contribute. But HELL YES it's easier for a lone developer to "(...) create a whole new language, complete with a module system, a proof system, a constraint system, a parser/lexer (...)" and it is ridiculously hard to "(...) extend C by adding new flags to the compiler that are optional and don't necessarily break anything from old code and lets you selectively upgrade your sources.". I know this from experience as well as, I'm sure, many others. I am building a parallel VM: I designed its instruction set, built a compiler and static analyser for it, went with it to a conference, etc. etc. It's not that hard and I bet you could do it too. But to take an existing language (read it as "an existing compiler") and "add new stuff without breaking anything" or just "add new stuff"? Man, that's orders of magnitude more difficult. There's also the satisfaction factor at work: when working on new project you get instant gratification - "Test pass!", "New feature!", "A bug fixed!", and "I get to implement this cool idea I had and nobody's gonna stop me!". When you work on an existing project (especially one as big as GCC or Clang) you have to brace yourself for several hours of reading the code before you can begin to think about where to start. If you did read the code and tinker with it every day then it will get easier, but you have to have the will power to burn through all that code, and not everyone does. Just my $0.02. |
I've had my own share of ICEs and patches back in gcc3 days where Debian mailing lists were being used as a gcc issue tracker :-) and these days you just fork and work from there. And if people really need your patches, they will integrate it willingly. No need to "get through" anyone.
If you need some confidence boost, start off with reading semi-old patches from other contributors. That will immediately take you to the cogs of the machinery so to speak. Also, debugger is your friend. I hope you have one for your parallel VM.
I maintain 15+ year old delphi code bases as a profession, so I guess your rant just flew out of the window for me. The "tests passed all green checks" insta-gratification is a lost memory. The freedom to implement whatever you want is kinda constrained but still there.