Java/C# to C++? From One Complex Language to Another

Share via Twitter Share via Facebook Share via Linkedin Share via Reddit

I just read with interest this piece from News.com on the future of C++, and I think I must have missed something. Presuming that quotes were not taken out of context – which is always a possibility – Bjarne Stroustrup, the creator of C++, is making a two part assertion, part of which I agree with and part of which I don’t.

The first part of his contention is that Java and .NET are suffering from something of a backlash. This, with some reservations and qualifications, I agree with. I’ve addressed this, at least from the Java perspective, before. The second part of his assertion, and what I’m dramatically less clear on, is that developers reacting against either one of the modern, objected oriented, garbage collecting languages are heading back to C++.

C++ advocates – and I know there’s at least 1 or 2 likely to read this (that means you, Christopher 😉 – hold the flames. I am not, repeat not, saying that C++ does not have a role to play, because it does. For many purposes, C++ is an ideal choice, maybe the only choice; I agree with Dewitt on that score.

But in my experience, developers abandoning (or refusing to learn in the first place) Java or C# are doing so primarily for reasons around complexity and productivity. They want to get things done as quickly and simply as possible. More often than not, this means the P from LAMP; Perl, Python or PHP. Maybe even Ruby. But not C++.

C++ the language has many virtues, but simple and quick are not typically counted among them. Perhaps it’s that Stroustrup is seeing a backlash for reasons other than complexity and productivity, in which case I’d love to know drivers he’s observed. But without more specifics, I can’t see C++ being a beneficiary of a mass move away from either Java or C#.

Either way, however, I do agree with my colleague’s quote in the piece: C++ has a very definite role within the enterprise alongside both Java and C#, as well as a number of scripting language choices. Different tools for different jobs; let’s all say it together.


  1. You nailed this one for me. Python/Ruby and C are a great combination that provides both convenience and efficiency when you need it. C++ is really very fringe for me at this point when going into new projects but I guess I won't rule it out completely.

  2. Our opinions aren't as far apart as you might think. Complex doesn't explain what is going on in the language right now. Core language constructs are being redefined via libraries. Some people see this as the future. I feel it is hurting my productivity as C++ becomes more read only. Throw in what MS is doing with C++/CLR and you have a recipe for a language that nobody really understands.

    What I see happening is developers such as myself are going to go in two directions.

    1) C for low level stuff where performance matters (eg implementing language run times).

    2) Scripting languages like Python, Ruby, and PHP for everything else.

    More on that latter.

  3. Christopher is right in as much as he asserts that the direction of migration depends on the problem. If the problem is performance-sensitive, it will be towards C and C++. If not, it will be towards dynamic languages like Python, Ruby, etc. FWIW, I see very little Python and Ruby deployed in production (and I pretty much always ask the question) — and it's hard to even find a customer that intends to deploy Python or Ruby into production. I would estimate that I see 25% C, 40% C++, 30% Java, 5% odds and ends. Of course, I'm looking at a subset of computing (namely, business-critical computing), and I'm nearly always looking at the core of the infrastructure — I'm sure other languages play a role in scaffolding or prototyping that I don't see. That said, if there were a groundswell towards deploying languages like Python and Ruby in production, I would expect to be seeing it…

  4. Ryan: I think you precisely reflect the "getting things done" mindset I'm seeing more and more. It's not always about elegance; apart from code reviews, there are rarely style points for getting something built.

    Christopher: I wasn't aware of the depth of the disconnect w/in the C++ community – though I've seen a thread here or two that you may have linked too – but it seems to me that if the language is risking advocates like yourself, they have something of a problem on their hands.

    Bryan: We're definitely aligned on performance as a gating factor for application selection; in that if performance is the primary, overriding concern it's highly likely that C and its brethren will be at the top of the pack. That said, however, I think the lens through which you view things, as you mention, is an important consideration. I'd argue that the type of customers you most often speak with represent the actual minority of development tasks, although they are the most difficult to complete. IMO, Python, PHP, Perl, Ruby etc are successful primarily b/c most shops simply will never experience the kind of loads that Wall St or the Fortune 100 will. They need something that can be scaled within reason, and is maintainable for at least as long as the CIO can keep his job. So basically what I'm getting at is that there's production, and there's PRODUCTION. You, I think, are talking about the latter – and in that context you're absolutely right, but I'm seeing a fair amount of the scripting folks deploying to the former.

  5. I can't say there is a deep disconnect with in the C++ community, but I feel that I am starting to disconnect with it personally. There are so many different programming styles going on in the language right now that it is literally becoming impossible to walk into a project as a "C++" developer and be guaranteed to understand what is going on.

    It is becoming a career endeavor to understand all of C++, and personally I want to get the apps out, not wrestle with the language all the time.

    I can understand why linus pushes against C++. You are opening a flood gate if you let that stuff into the kernel.

  6. "IMO, Python, PHP, Perl, Ruby etc are successful primarily b/c most shops simply will never experience the kind of loads that Wall St or the Fortune 100 will."

    Ohh, careful there! That's an architecture problem, not a language one. Yes J2EE and .NET have had plenty of cash burned up into making them go faster. Add in all the money spent on making DB2 and Oracle scale at the backend, and you've got what, billions spent making client-server middleware viable?

    Now, if we look at Bittorent, or XMPP, or Jini, or JXTA, or even raw Erlang, as a middleware alternative. You can start seeing non-client-server distribution options where in extreme cases, the system will go faster as more clients come on board. Language/runtime scaling doesn't seem to matter so much there. It'll boil down to the same economic argument as moving away from systems languages does – why spend so much time and money tuning and mucking about with app runtimes, clusters, scaling criteria, discovery, deployment and who knows what else when we could be shipping new features on, wait for it, because it gets better, optimally provisioned hardware? Who cares that you're really smart and can get bottlenecked by design client-server architectures to scale up and out? Give it 4 or 5 years and it'll seem a lot less nuts to run the enterprise on P2P or IM-ware.

  7. Speaking as a former mathematician, the parallels between writing good and optimal code is uncannily similar to deriving equations in the correct form. Writing elegant C++ is precisely this. I've dabbled with Java and C# but prefer C++ as it is just more expressive. Also it is more 'challenging' and really forces you to think about what you are doing.

    I think I agree with most of the comments above, but don't forget that scripting languages already have regexp stuff inside it, so they in effect already have their own class libraries albeit part of the language. You could rewrite it yourself, but why bother?

    The whole industry is just under going a 'settling' period where people are 'choosing': (1) 'Back end' – C/C++, (2) 'Front end' – the 'VB' languages (VB, C#, Java – yeah, yeah, Java on the backend…), (3) 'glue' – the scripting languages (Ruby, perl, python, etc. ).

    And lets be honest, you always want the performance, no matter how great a VM is, it's another few years of Moore's law before I'd consider a VM language for the back ends I have to write.

  8. Cantrill comments on your blog? Dagnabbit tecosystems rocks… i am going to have to start writing blogs about c++. actually maybe i should write something about smalltalk, now IBM is sundowning its VisualAge implementation. at least i would be guaranteed some comments from James Robertson, one of the James blog cluster – so far Governor, McGovern and Robertson. a blog of Jamess…

    And Bill de hOra is always, ever insightful. interesting IBM's analyst relations folks just sent a

  9. Here's Google's Joe Beda's take on C++

    I tend to agree with most of it.

  10. Where I see it going is to a evolution of C like D (http://www.digitalmars.com/d/), that is low level (inline assembler) yet supports advanced features like Garbage Collection. That for performance critical applications.

    On the less critical side: scripting/dynamic languages;

    The reason I say this is because good programmers are hackers(PaulGraham definition); From this i conclude the future is: a) open source for the basic with mainly commercial for enterprise solutions / tools / etc. b) Flexable, programmers love it: I am moving away from Microsoft products because it's hard to play it may way.

    With eg. D/PHP I'm free to do it may way or based upon any one of many frameworks; the choice is mine and it's liberating;

Leave a Reply

Your email address will not be published. Required fields are marked *