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

[steve donovan <steve.j.donovan@...>]

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.

People think this is a second-order consideration, but I'd rather be
up and testing rather than playing with light sabres while my code
compiles.  There are different 'cognitive styles' among programmers,
and I seem to fall into the 'attention deficit' end.  These styles
cannot be ranked with ability, or with effectiveness; they are another
dimension.

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).

Ultimately, this debate won't be settled by comparing specifications,
but by market share, and there "worse is better" will dominate.  We
may regret this, but the fact remains that the programming languages
which are exciting and different are also harder to learn[1], and
often require a love of theory.  We can take heart from that insight
from Paul Graham, that when you are working on the server side in a
rapidly-changing world, a 'secret weapon' can be most effective for
small start-ups.   Like the old New Yorker cartoon suggests, on the
Internet no-one knows you're running Lua on the back-end.

[1] e.g. world-wide shortage of good C++ programmers, leading to quiet
programmers on the edge of the developed world being approached by
large multinationals ;)