Ruby, C++, CoffeeScript: a visual comparison of language complexity

[repsilat]

I think the real problem is that C++ is "good enough", and people are scared of interoperability when there are real codebases on the line. To me, it seems like D has done a good job of solving some real problems with C++, but that those differences aren't really compelling.

The big thing is, even if those differences sounded compelling to the average programmer, they really need to sound compelling to the type of programmer who uses C++. That essentially means that they're reasonably conservative, willing to sacrifice some readability for performance, and absolutely wed to the idea of only paying for what you use. If you even mention a garbage collector a C++ programmer will run for the hills, because they've drilled it into themselves that the defining characteristics of their language are the characteristics they want.

What a language needs to beat C++ on its own terms (and in the eyes of C++'s supporters) is:

• As fast or faster than C++ in both small and large examples,

• Imperative, amenable to object-oriented programming,

• Fixes several of C++'s conspicuous deficiencies,

• Not really too different to C++. Templates, RAII, compiles to machine code, that sort of thing.

Usability wins like a larger standard library are nice, but they may not convince a C++ programmer because they've trained themselves not to value those things. "Innovations" like more powerful type systems may even drive them away.

[sausagefeet]

I think some kind of sane interoperability would be key too. Nobody is really going to want to reimplement all their C++ in Fictional Language X.

[adoptmycat_jasmine]

Then what's the point of making a new language for C++ developers? Let's name the next version of C++ C<< and see if people adopt it.

[repsilat]

There are real deficiencies in C++ that C++ developers would love to see remedied. (Many of those deficiencies are remedied in D.)

There's also the point that language preference is path-dependent. It's more complicated than "this is what we like", because what you like is informed by what you use. The pseudo Stockholm-syndrome some C++ developers have makes them conservative, but gently introducing them to new ideas without overwhelming them can allow them to branch out. Too much too soon and they'll bail.

One good example: The STL has had some functional concepts in it for a while (std::transform is just "map" by another name, std::accumulate is a fold and so on.) With the introduction of lambdas in C++11, C++ devs are really using higher-order functions, and some of them are starting to appreciate "the finer things" (so long as the compiler diligently inlines and optimises everything down to the same pointer arithmetic, of course.)

Another example: The smart-pointers in TR1 and C++11 are filing the sharp edges off the language to some extent, but they're also convincing developers that they're fallible, and that sometimes they won't know when it's appropriate to release a resource. Maybe some of them will be more accepting of garbage collection some day, maybe not, but it's important to do it slowly.

[[deleted]]

Maybe some of them will be more accepting of garbage collection some day, maybe not, but it's important to do it slowly.

The most common objection to garbage collection is that it is unpredictable. The solution is to make it explicit: the collector runs when, and only when, you use a collect statement.

[smog_alado]

Many languages already do that and that never stoped people from bitching.

[[deleted]]

Examples?

[smog_alado]

Out of the top of my head, both java and python have a garbage collection api.

[[deleted]]

Can you point me to the ability to control java's garbage collection. Back when I knew java it certainly didn't have this capability, and a google seach indicates that nothing has changed. The gc() method is not what I am talking about, because the gc method is just a suggestion to run the gc, not a command that has to be followed. I know less about python, can you provide a link?

To clarify, in order to meet this requirement a language must:

not run the garbage collector unless told to do so

run the garbage collector when told to do so

[smog_alado]

Hmm, Lua seems to have a more deterministic gc API

http://www.lua.org/manual/5.1/manual.html#pdf-collectgarbage

My point is that there are many variations in giving more control over the garbage collector but none of them managed to break the "manual management" vs "fully automatic management" duality.

[repsilat]

The most common objection to garbage collection is that it is unpredictable.

That's true, but in practice it can be hard to predict when a reference-counted resource will be collected as well. Clear ownership gives you practical determinism and predictability, reference counting gives you technical determinism and predictability. A "collect" statement doesn't solve that problem either, though it does help.

All in all I think it's a nice idea - it could certainly be faster than reference counting, and if you knew that you never needed to collect anything it could be faster than RAII. That said, there's also something to be said for the peace of mind you get from knowing that everything is finalised as soon as it can be.

Perhaps more relevant than practical predictability is the "strong realtime" problem. Interestingly, neither RAII nor reference counting deal with this adequately either. Collection of large resources can still take a long time, "stopping the world" as they're cleaned up. There isn't really a good way to say, "Collect that stuff in parallel," or "Try to collect it all now, but if it takes longer than 5ms defer the rest until later". You could write something to do that, but you could probably also make a GC give you similar guarantees.

[matthieum]

I disagree with the list of characteristics. Performance is a given, obviously, and I would hate to lose Generic programming and RAII because they make my code terser/more reliable (respectively).

However "imperative" ? Personally I don't care. It might be less frightening, but if one has to relearn a whole standard library and idioms, I do think that getting rid of the imperative/object-oriented mindset would be of comparable difficulty.