Why C++ is not my favourite language

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

by alaricsp • 17 years ago

17 52 17 years ago

snell-pym.org.uk

eplawless• 17 years ago

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.

eru11• 17 years ago

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/

jcl2• 17 years ago

I can't help feeling that Common Lisp should be doing better, considering that it's a language where you can effectively tell the compiler "It's OK to store this variable in a register". It's currently doing about the same as Mono, which IIRC doesn't JIT, and worse than Java.

The king of dynamic language performance right now is LuaJIT, which crushes Perl, Python, and Ruby and performs admirably relative to Smalltalk and Scheme.

UncleOxidant3• 17 years ago

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)

dtf6• 17 years ago

I've found Python/C++ (via boost::python) to be a fantastic combo. There's also luabind which does similar lua/C++ two-step.

magv• 17 years ago

More than 10 years ago Jeffrey Mark Siskind posted micro benchmark [1] of his aggressively optimizing Stalin Scheme compiler versus then-current GCC. Stalin produced code 21 time faster than GCC.

I do not know why this fact remains so little-known.

[1] http://groups.google.com/group/comp.lang.lisp/msg/9801ba2edd...

psranga3• 17 years ago

Note the comparison is to C, not C++. The runtime improvement came from aggressive inlining.

I'm pretty sure that C++ code (which allows templates, function objects etc) can be written to do the same.

Of course, then we'll get into discussions about whether the C++ code is "idiomatic", requires "wizardry" etc.

The biggest win I see for JIT'd dynamic languages is their ability to optimize across source files. I wish C++ had the capacity to slurp in ALL of a project's C/C++ files and compile it one pass.

In these days of 16G developer desktops, is this an unreasonable demand? :)

alaricsp7• 17 years ago

That day may not be too far off... I hope ;-)

cbeust2• 17 years ago

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• 17 years ago

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.

cbeust2• 17 years ago

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

psranga3• 17 years ago

Ousterhout of Tcl fame has a very nice (and surprisingly old) paper about this. http://www.tcl.tk/doc/scripting.html

acg5• 17 years ago

Don't you mean statically bound? I think quite a few C++ programmers get into the mindset that once the program has compiled that's the end of the optimisation. It depends on the system that is being run, but if the system has a long runtime: ongoing optimisation may bring about better performance over time. This is particularly true given how many bad C++ programmers there are (which is partly down to the language learning curve).

Strict typing was mostly about trapping programming errors at compilation rather than runtime. Perhaps something despite all the effort C++ has struggled to improve defect count through typing (C++ systems often fail for far more obscure reasons, and the strict typing can cause hideous compile-time errors).

dtf6• 17 years ago

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.

Legion2• 17 years ago

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++".

acg5• 17 years ago

Hardly, I know many people who spent years learning C++ in the 90's only to avoid it now. The reason is they had no love for the language. The C++ language design has serious flaws that whenever someone brings them up there's the usual, rolling of the eyes and the "yeah we know" sort of look. The if you criticise you must be a dumb attitude is encouraged by the C++ community too, and that was not borrowed from the C community: where the emphasis was beautiful tight code (like the K&R manual itself).

Lets face it C++ is something like 30 years old this year. For a 30 year language to have so many flaws, and for newer languages to make a better job of integrating OO while still keeping the power: you have to ask whether the C++ community really knows all about technology and nothing about design. The whole project has been mislead from start to finish. It strikes me it had to take a couple of ada programmers to write the STL.

ilyak2• 17 years ago

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.

UncleOxidant3• 17 years ago

It seems like a language like OCaml could do quite well in the VM implementation space: it has very low-level imperative constructs that can be used to optimize, yet also has very good features that allow for generic programming (modules, functors, type inferrance).

barrkel• 17 years ago

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

alaricsp7• 17 years ago

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

psranga3• 17 years ago

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.

acg5• 17 years ago

Perhaps, or perhaps C++ programmers who defend the language haven't spent enough time in other languages.

If you are just plugging components together I can think of better languages.

In my experience C++ demands more time that most languages to master. Which is a far longer time than, say, C.

ajross• 17 years ago

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.

eru11• 17 years ago

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

alaricsp7• 17 years ago

FWIW, I'm working in C for my day job (and resisting calls to move up to C++), as my day job involves shuffling bytes around rather than particularly complex code; it's ~20KLOC. Then we build the tools to manage it in Python with a bit of shell scripting here and there. However, I code Scheme in my spare time, and would do the lot in that if I didn't then have to justify training new developers in Scheme! C's the right tradeoff for commercially developing a high-performance database kernel, IMHO.

I've done plenty of C++ in past jobs... which is why my day job is in C :-)

eru11• 17 years ago

Is there an easy way to shuffle bytes and bits in Scheme? I was quite delighted when I found Data.Binary (http://code.haskell.org/binary/) for Haskell.

Why C++ is not my favourite language

Related Stories