[Date Prev][Date Next][Thread Prev][Thread Next]
[Date Index]
[Thread Index]
- Subject: Re: C++ religious war (was: llua Higher-level C API for Lua)
- From: steve donovan <steve.j.donovan@...>
- Date: Sun, 16 Mar 2014 10:06:24 +0200
On Sun, Mar 16, 2014 at 9:11 AM, Benjamin Heath
<benjamin.joel.heath@gmail.com> wrote:
> Actually, the new subject line had me hoping for a spirited flame war when I
> saw it. Can we start a real one anyway, just for kicks?
Well, Enrico has done my mind a service with his remark that he is a
C++ user, not enthusiast. Magnificently pragmatic (we are engineers,
after all: whatever works for the job). Since I've become known as a
ex-C++ enthusiast, here's some balance.
The basic criticism of C implicit in C++ is that C is too
weakly-typed, and gives fewer guarantees that a compiled program will
behave correctly. Having recently sweated over C in a stressful
deadline situation, I know this very well - humans are error-prone,
especially when under pressure. It allows more elegant and safe
abstractions, for instance you are less likely to shoot your foot
using Selene than using llua when working with the Lua API at a higher
level. The 'abstraction penalty' you pay can be very little, at least
measured in execution speed, since C++ will inline ruthlessly. The
built-in support for OOP makes large-scale program organization easier
and less verbose.
However, everything has costs - that 'ruthless inlining' can really
give you fat executables, since this is the default behaviour for
templates - and in modern C++, just about everything is a template,
whether sensible (standard containers) or not (strings and iostreams).
Again, because of templates, compile times become intense and error
messages become the stuff of legend.
Particularly for _infrastructure_ projects, using C++ makes it harder
for a project to communicate with the rest of the universe - e.g. FFI
bindings to C can be very straightforward, whereas the C++ ABI is much
more complex (quite apart from name mangling). This is very relevant
to the business of doing Lua bindings.
Stroustrup says that there's a lean and elegant language trying to
escape from C++, and this is why I'm interested in the next generation
of statically compiled languages. Nimrod is particularly promising - a
fresh, no-compromises approach to compile-time metaprogramming with a
very straightforward syntax. But it has no corporate sugar daddy, so
it's likely to remain niche.
In the meantime, I've been trying to make C more expressive (llib
project) but this is all getting rather off-topic for people
interested in a powerful, lean dynamic language called Lua ;)
(Static and strong typing are orthogonal concerns, of course, although
this point is commonly misunderstood. Lua is the C of dynamic
languages in many ways, compact, few dependencies, and tending to
weaker typing - we pass around tables where Pythonistas would tend to
create a named class, etc.)