Who’s a hose beast?

Ryan is disillusioned with C++.  The analogy of C++-as-a-person-whom-I’m-going-to-divorce is kinda lame, but his criticisms are typical.  I normally don’t get in blog wars like this, but for some reason, I’m feeling defensive tonight. 

  1. He complains about C++ that “You can’t decide who you are”. 

    What this means is that he thinks C++ behaves inconsistently.  Firstly, so does any other language that has more than one compiler.  Java may be an exception, but there aren’t many java VMs other than Sun’s – and even then, there are probably differences.  The C++ standard is clear about expected behavior in almost all conceivable scenarios, and it spells out where the behavior isn’t well-defined.  I think his complaint here ought to be with the “compiler friends” he hangs out with.  He could also find a portable compiler that tries to comply with the standards (such as gcc/mingw or the intel compiler, if he’s on x86.  VS2005 does a respectable job of implementing the standard, but then, it’s not portable in any sense.

  2. “Self-denial”? What the heck? 

    Yes, so C++ doesn’t have usable reflection capabilities.  That was an intentional design decision made to prevent the runtime overhead involved – remember, C++ was designed as a tool for creating high-performance software.  Languages and VMs that support real reflection are aren’t.  Repeat after me: C++ isn’t the tool you should use in a project that requires reflection.  Languages that support reflection aren’t the ones you should use in a project that require high performance.

  3. I honestly don’t understand his complaint that C++ doesn’t “know what strings are”. 

    He says he has to use a “null-terminated blah blah blah” – which you should never have to do in C++.  And what’s so bloated about std::string?  I find it to be quite nice, actually.  Non-standard third-party implementations need not apply.  std::string works just fine.

  4. C++ doesn’t know what arrays are?

    std::vector<int> anyone?  Also, if std::vector<std::vector<int> > doesn’t blow up your skirt, then typedef it.  Sheesh.

  5. Templates

    Where to start?  Firstly, C++ having templates is still more than Java can say.  Generics != templates.  The syntax is a little unseemly at first, but it’s an acquired taste – like beer.

  6. Dependency resolution.

    Firstly, header dependency resolution isn’t a characteristic of C++.  The pre-processor does that.  Secondly, if your code is so complicated that wrapping all your headers in
    #ifndef _BLAH_
    #define _BLAH_
    // definitions
    #endif

    doesn’t work for you, then your design is broken.  Don’t blame C++.

  7. Necessity of design patterns?

    Design patterns are just the outflow of a few decades worth of industrial experience.  People are starting to retire en masse, so they thought it might be a good idea to write some things down.  Why is that a bad idea, and what does that have anything to do with C++?  No language can obviate the benefits of having formal design patterns.  Not even our current rock-star, Ruby.

More generally, what I want say, and what many expert programmers will say until they’re blue in the face and what many other programmers simply won’t listen to is that languages are just tools.  They’re all designed for something, and that something isn’t always the same.  Actually, it usually isn’t.  Use a tool that’s appropriate for the job.  C++ happens to be designed for a very broad and general application domain.  That’s a large reason for why it’s so widely used.  I don’t know that I even know of any other languages that have such a large application domain.  Even Java, C#, and Lisp/Scheme aren’t as general-purpose as C++ is.  The point is use the tool appropriate for the job.  The fact that C++ is a combo compound mitre saw/router/nailgun doesn’t mean it should be used to paint a wall.  Likewise, you shouldn’t use a paintbrush to try and make furniture.  Ruby does not do everything Perl does with none of the downside.  Perl has its strengths, and Ruby has its.  Let it be at that.

Just to address Ryan’s specific comments: the reason certain languages are widely used and “safe” is because of their large application domain (and other reasons as well, many of which ultimately spring from this primary reason).  Businesses don’t want to invest in many niche tools when they can support good general tools for the same or less.

Also, I don’t necessarily disagree with his insistence that we shouldn’t be monolingual (picking up new programming languages should be something any good programmer can do quickly), but I also think that it’s good to be able to fall back on something as an expert. 

Powered by ScribeFire.

This entry was posted in Uncategorized. Bookmark the permalink.

Leave a Reply

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

*

You may use these HTML tags and attributes: <a href="" title=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong> <pre lang="" line="" escaped="">