On Wed, 2012-04-11 at 15:13 +0200, Richard Guenther wrote: > On Wed, Apr 11, 2012 at 2:57 PM, 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? > > Until some company puts money behind converting to C++ then yes, > it's the hobbyists (or the non-hobbyists in their spare time).
That is not what I said. The question I raised is whether a change to C++ aimed at growing the developer base would actually make full-time GCC developers change their jobs. What you are questioning is whether a single company would make itself responsible for the conversion. This is two different questions. And elsewhere in the thread, you assert that if the conversion happened, other developers would stop working on it (i.e., my question above). If this would indeed be the case, nobody would fulfill your request (money behind the conversion). So let's look at the first one first. > > > 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? > > If you look at the existing developer base then the majority of it is paid. > And frankly while empolyers may listen to their employees, switching > from GCC to LLVM is not something they'd do based on a C++ vs. C > implementation language (but maybe based on availability of consulting > services or new employees or viability of using LLVM for weird architectures > or simply based on customer demand). Makes sense. But you also say that a switch in the language doesn't really matter for paid developers (or their employers), so why is there then such a strong opposition towards a switch? (assuming that the switch might have benefits to new developers..) Also, AFAICT, LLVM is attracting more new paid developers than GCC, or not? For them, they don't have to switch from GCC to LLVM, they simply don't start with GCC. That is certainly due to differences in the license to some extent, but if employers believe that they can get their employees to a quicker start when using LLVM, then this is bad for GCC. > >> > >> > 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. > > Well, but mult (add (x, y), z) is easier to understand than x.add (y).mult (z) > because operator precedence is visible. > > Similar for doit (a, b) compared to a.doit (b) (or b.doit (a) - what > preference > is there for two inputs?). So you likely end up with a mix anyway. Yes. But mult, add, and the doit don't have a single context, they have two. On the other hand, consider two-input but single-context examples such as read(obj, property) vs. obj.read(property); which makes the context more easily visible? So, it's not about the number of inputs, it's whether there is a dominating context. You have that, for example, when starting navigating a graph from somewhere (eg, CFG), adding leafs to a tree node, getting or setting properties of an object, etc. I would guess that such operations are pretty common, more so than operations with more than one context. Also, I don't think anyone is arguing for a one-size-fits-all approach here. A mix isn't a problem really, as long as it easily reveals the structure of the program logic (e.g., stuff like contexts, or operator precedence as you mention).
