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

[Jeremy Ong <jeremycong@...>]

I think you've written a well-thought out summary that brings to light
to issues well.

To me, the following list embodies all the "tensions" that each
programming language tries to resolve in its own way.

1. Type safety vs type flexibility
2. Lean runtime vs batteries included
3. Small syntax vs expressive syntax
4. Opinionated virtual runtime vs native runtime (aka what does the
scheduler do)
5. Speed vs safety

In addition, languages make decisions early about

1. Build system/ecosystem
2. Code organization (module/objects/headers)
3. Static typing (templates) vs runtime typing (reflection)
4. Embedded vs native execution

Having used in order of exposure BASIC, C, PHP, Javascript, C++, Java,
Lisp, Python, Ruby, Haskell, Erlang, Lua, R, C#, Elixir, Rust, and
probably a few more I'm forgetting, I've concluded that there is no
war. Only a series of tradeoffs that should be considered for each
project.

However, it *is* true that languages have varying degrees of technical
debt due to poor decisions made early in the design of the language.
For example, Javascript was meant to be embedded into small webpages
as simple scripts to manipulate the DOM and transfer small chunks of
data back and forth from the server via JSON. As a result, JSON is an
inefficient protocol and build tools and modules aren't natively a
part of the language. PHP was also written in a time when web
applications were smaller and so the OO part of PHP wasn't introduced
until much later, which had tons of its own warts (inconsistent API,
oddities with static members, etc.).

I think the real war that should be waged is the one between people
who think that there is "one true language" and those that are more
polyglot oriented.

On Sun, Mar 16, 2014 at 1:06 AM, steve donovan
<steve.j.donovan@gmail.com> wrote:
> 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.)
>