Re: C++ religious war (was: llua Higher-level C API for Lua)

[William Ahern <william@...>]

On Sat, Mar 22, 2014 at 12:58:30PM +0200, steve donovan wrote:
> On Fri, Mar 21, 2014 at 9:08 PM, Coroutines <coroutines@gmail.com> wrote:
> > I agree here, I remember a big point of Go was much shorter build
> > times.  Being able to rewrite an expansive C++ project in Go and not
> > waiting half a way for the build to finish.
<snip>
> The given reason for longer compile-link cycle is that we are getting
> a better executable, both more thoroughly checked and optimized.
> However, in the case of C++, the longer compile cycle is a
> self-inflicted wound because of the ancient build system (here the C
> legacy has hurt C++).  We tend to make a virtue out of necessity, but
> C++ need not take so long to build, and its modern "successors" are
> generally quicker and have cleaner designs (e.g Nimrod, which has the
> same heavy emphasis on compile-time metaprogramming).

Doesn't Nimrod compile to C, which must in turn be compiled to a native
binary?

C was built to compile quickly. It's part of the reason why its type system
is so loosely defined. The fact that it often compiles slowly today is
because of optimizations, some of which have--out of necessity or
convenience--horrendous O(n^2) or worse complexity. Most often these
optimizations are never attempted by other languages, or they're postponed
until runtime. That modern C compilers are so good at optimization is why
some really awesome languages target C as an intermediate language. And even
though many languages theoretically permit easier and deeper optimizations,
in practice its often simpler to compiler to C and leverage the incredible
number of man-years put into C compiler optimizations.

C++ is worse because 1) the language syntax and type system is obscenely
complex from a compiler's perspective and 2) the large number of
subexpressions that the syntax attempts to hide from you but which explode
the AST. And of course all of this is compounded by the heavy optimizations
performed.

I think the issue with C's heritage is overblown, especially considering
that modern compilers support pre-compiled headers. The data structure
definitions that must be parsed from header files would also have to be
parsed and loaded from binary formats, and the speed benefits aren't really
that astounding. I think the greater problem is the practice of people
having dozens or even hundreds of compilation units. In many projects every
little C or C++ file has like 2 or 3 functions defined. Far fewer people do
stupid stuff like that in Java, C#, or other languages.