On Wed, Apr 11, 2012 at 5:57 AM, Torvald Riegel <trie...@redhat.com> wrote: > On Wed, 2012-04-11 at 11:24 +0200, Richard Guenther wrote: >> On Tue, Apr 10, 2012 at 7:29 PM, Torvald Riegel <trie...@redhat.com> wrote: >> > Think about programmers new to GCC for a second, and about code >> > completion tools. >> >> Honestly I care 1000 times more for existing GCC developers. Before >> new programmers will have an easier time with GCC _existing_ GCC >> developers will have to spend at least two GCC release cycles (that's >> very optimistic) turning the GCC codebase upside-down. Every >> existing GCC developer you lose on that way will slow down that >> process and for every existing GCC developer you probably need more >> that one "new" GCC developer starting. >> >> It's very easy for me to do the math and conclude that losing even _one_ >> experienced existing GCC developer makes this whole transition-to-C++ >> thing a non-starter. > > I agree that less work-force in the transition would be a problem. But > is C++ (perceived to be) so bad that it would make people change their > jobs? I mean, we're not talking about the experienced hobbyists here, > or are we? > > However, the concern you raised is only one part of the problem. The > other is that, put in a simplified way, GCC is competing with LLVM about > new and/or non-fulltime-compiler developers. For me, it looks like LLVM > is more appealing to them, and I believe part of the reason for that is > the codebase. > Now, how many release cycles do we have until LLVM is basically good > enough to be used as a distro compiler (e.g., until code quality and > confidence in bug freedom is sufficiently similar)? If we haven't > ensured that GCC is appealing by this time, why should new programmers > then start considering GCC and not just go by default to LLVM?
Yes -- this should be the main motivation factor for GCC to make major changes or even leapfrog -- LLVM is also more than 10 years old. David > >> >> > It seems to me that with such a tool it's much easier >> > to navigate from exp to the field, than having to scan through a much >> > larger number of accessor functions / macros (GET_*). The former >> > example starts at the source (exp) and yields/"builds" the result; the >> > latter names some function and then says applies it to the source. Why >> > is the former so much worse? To me, the former's structure is easier to >> > see, and if I would have to put the spaghetti tag on something, then the >> > latter. >> >> Sounds more like missed features or bugs in the tools you use. Heh, >> after all our complaints that C++ will be harder to debug are deflected >> to "that are gdb missing features / bugs". So - file bugs against Eclipse >> (or whatever new and shiny programmers use these days), that it does >> not work well with a codebase like GCC. > > Please don't dismiss this so easily. Of course this is just an example > and nothing major, but I believe many people will use tab completion on > the shell, for example, and code completion is really similar. On the > shell, or with paths names, you start with typing something, then can > navigate from this context you provided. That just works better when > you say context->function instead of function(context). > And I'm not a cognitive psychologist, but to me, seeing the context > first when reading left-to-right is also slightly easier to read. >
