

Why C++ is not my favourite language - alaricsp
http://www.snell-pym.org.uk/archives/2009/08/28/why-c-is-not-my-favourite-language/

======
dtf
I guess he's not a systems programmer. What language did Slava Pestov turn to
when he recently re-wrote Factor's VM?

C++ programmers: we do the dirty work so you don't have to.

~~~
Legion
Indeed. So many of these articles can be boiled down to:

"As long as we limit the comparison to things (our language) does well, and
exclude things C/C++ do that (our language) can't do at all, (our language)
totally 0wnz C/C++".

~~~
ilyak
Please never, never, never ever write C/C++.

С - simple and stable, C++ - huge and changing. C - portable and easily
parseable, C++ - unpredictable and unparseable. C - good, C++ - bad.

~~~
acg
I hear good stories about D from colleagues:

<http://digitalmars.com/d/2.0/overview.html>

~~~
dtf
D's great for at least two reasons:

1) it set out to be a no-compromise systems programming language

2) it's being designed by people with an deep and intimate knowledge of C++
(Walter Bright wrote a C++ compiler - no mean feat, and Alexander Stepanov was
Mr STL)

These guys know the good, the bad and the ugly of C++ much better than most.
From the stuff I've seen so far (check out Stepanov's presentations on an
iterator-free STL, or adding functional purity, and also look at the work on
making floating point more rigorous) this could finally be a worthy successor.

~~~
eru
3) You can declare functions to be pure. A lot of optimizations become
possible.

------
eplawless
That's really cool that this guy thinks dynamic languages have the potential
to be faster than C++. Maybe he can write a second article when they are
actually faster, with some properly done benchmarks or some valid technical
examples.

~~~
eru
Common Lisp is already quite fast and dynamic. And for the same number of
hacker-hours spend in optimizing, you probably get a larger speedup. Also
Python+C can be quite a fast combo. Fast to develop and fast to execute. Forth
is also quite fast and dynamic, if you grok it.

A lot of functional programming languages have also become quite fast in the
last decade. While there are in a sense more fluid than C++, they are normally
considered static (and not dynamic) languages.

If you want to compare asymptotic speeds where programmer-hours invested goes
to infinity, the lower level languages will probably always win. Like
assembler, C or C++.

For benchmarks see: <http://shootout.alioth.debian.org/>

~~~
UncleOxidant
OCaml does quite well against C++ in the shootout. OCaml's Functors and type
inferrence are a big win over C++ templates. Yeah, the syntax takes some
getting-used-to, but all in all the language seems to hang together much
better than C++ (perhaps not saying much)

~~~
eru
I agree. I like Haskell's syntax better. But their syntaxen are nearly
isomorphic for the most common stuff.

~~~
UncleOxidant
I'm finding OCaml's approach to be a bit more practical even if it isn't as
pure as Haskell. Once in a while it's nice to be able to drop into an
imperative style or even do some OO and OCaml lets you do all of that.

~~~
eru
Yes. Though Haskell allows imperative style (via Monads), too.

------
barrkel
The canonical anti-C++ link for me has to be <http://yosefk.com/c++fqa/> \-
pretty thorough and reasonably well argued.

~~~
alaricsp
That is indeed a most potent collection of detailed arguments!

Now, let's just wait for my colleague to start ribbing me for keeping our
project written in C again... ;-)

------
psranga
From my perspective, most of the stuff about C++ complexity rings untrue. Most
people I know seem to know enough about C++ that they can produce pretty good
code.

Yes, there's a lot of depth to C++ but you derive a lot of benefit from
other's wizardry even if you're not a magician yourself.

Maybe this guy didn't invest as much time on C++ as he did on his other
languages.

~~~
ajross
I think that's not the right criteria though. Are most of the people you know
capable _maintaining_ other people's C++ code?

The idea that you can write (!) sane code in C++ by using a simple/sane subset
is of course true. But the problem is that in a language of this complexity no
two people are going to be able to agree on what that sane subset is. One
person may love auto_ptr and use it everywhere, confusing her coworkers who
don't get reference counting idioms, but love the STL...

By the time you manage to get your project's coding standards hammered out and
enforced, and get it rigged up so it can talk to your external libraries that
don't adhere to those standards, you might as well have given up and used C to
begin with.

~~~
eru
I agree. (Might I add that reference counting is evil (and slower than true
garbage collection).)

------
cbeust
I sympathize with the author's dislike for C++ and while you can't argue that
dynamic languages "could" at some point in the future be faster than C++, it's
very unlikely to happen since one of the requirements for this kind of speed
is for a language to be statically typed. Without type information, the
compiler is left with very few options to optimize the generated code.

~~~
gruseom
_one of the requirements for this kind of speed is for a language to be
statically typed_

No, one of the requirements for _static optimization_ is that a language be
statically typed. It does not follow that there are no ways to make dynamic
languages fast, just that they mostly have to use different techniques.

~~~
cbeust
You need to make languages fast on both dimensions, static and dynamic. A
dynamically typed language can only be optimized in one dimension, which is
why they usually trail behind statically typed languages in performances
(since those are optimized along both axes).

~~~
alaricsp
I've not seen anything like the dynamic-dispatch optimisations the Self team
came up with in the 1990s done in C++, nor problem-domain optimisations
expressed as macros as is often done in Lisps, nor the aggressive constant-
propagation of closures and their eventual inlining that Factor does.

Perhaps some of them could be applied, but a highly complicated base language
with extensive mutation semantics (including pointer aliasing) probably mean
they'll be so limited in their applicable scope, and so difficult to
implement, that it's not an attractive activity for C++ compiler writers...

~~~
eru
Do you know Synthesis OS
([http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4...](http://citeseerx.ist.psu.edu/viewdoc/summary?doi=10.1.1.29.4871)).
The author made the OS specialize (and thus optimize) system calls during
runtime (or something like that, it's been a while since I read the paper).
The techniques might me applicable in higher-level languages than the
assembler used there.

~~~
alaricsp
Yeah! Synthesis is quite excellent. I've been interested in exploring using
the FORTH model of easily-accessible-runtime-compiler in that sort of
context...

~~~
eru
However it seems dead. Anything new on Synthesis (and related ideas) in the
last two decades?

~~~
alaricsp
Other than JIT recompilation in VMs of various kinds (which is only indirectly
related), no, not that I know of...

