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

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

On Sun, Mar 16, 2014 at 11:22 AM, Jeremy Ong <jeremycong@gmail.com> wrote:
> As for compiler speed, I understand :). I fall in the camp of people
> who are willing to wait because I believe the compiler is doing useful
> work for me (type checking, static assertions, compile time
> expressions, generics).

The enemy of C++ is its heritage as a C-compatible language, which
includes a build system that was new when men wore bellbottoms and
women had flowers in their hair.  That is, most of that wait is not
essential for the extra checking and due to the preprocessor pumping
in massive includes. In this sense, C is bad for C++.  (Compare this
to the wonderful smart linker that Delphi had and weep.)

It doesn't have to be like this. When I was working on UnderC I
realized two things (a) it is not essential to build an executable for
testing and (b) if you can maintain live compiler context then headers
only need to be parsed once. This happens naturally if you have an
interpreter, plus an incremental compiler like Lisp systems.  (They
are still smug about that and for good reason).  However, I moved on
to other problems.

As for performance, Mike Pall has given us an existence proof that
dynamic languages don't have to suffer in performance compared to
compiled languages.  The trouble with dynamic languages is when doing
'programming in the large'.  With C, I can jump around a large
codebase like a mountain goat;  Eclipse makes Java almost pleasant.
Without explicit type annotations it's hard to do that with dynamic
languages.  (You just need enough to resolve the ambiguities so type
inference can fill the gaps - see the Typed Lua project).

The people who manage big codebases in Lua have to do a lot of
thinking up front and use extra tooling, like static type checkers.
It would be cool if they could share some of their stories, but what
they share in common is that they are not casual scripters!