Why C++ â€¦

Andrew Wrote:One language I really liked from my programming languages course was Gopher, a simplified version of Haskell which has since been supplanted by HUGS. I liked Haskell's syntax more than LISP's, primarily for its brevity. Here's some further reading if you're interested.

Personally I really dislike the haskell syntax for many reasons like indentation as syntax and theres a lot of very arbitrary little things which bug me, it happens in haskell just like it does in mathematical notation.

Of course, the language has many incredibly useful things that lisps do not (pattern matching, implicit currying, algebraic types, type inference etc)...
Thing is, in (on) lisp you can write code-transforming macros which means (combined with closures and functions as a first class data type) that any language feature you like the look of you can easily implement in lisp itself (including all mentioned above, object systems, domain specific languages, declarative programming and so on..).

But once you've read SICP, and realised that programs you use daily crash due to being programmed in pointerful, non garbage collected languages by humans, everytime you try to do even a little meta-programming in C++ you just end up in template hell: more bother than its worth to try and write correct programs in any C based language.

I don't believe you can be a good programmer without the ability to know when your tools are hurting your ability to produce a solution. That means that (amongst other things) you must realize that no one programming language is the be all and end all, so you could not make a statement like "I only need language <X>".

I personally believe that C++ is not a good language for *any* task, for reasons I've often explained before, and the people I've met who I consider to be good programmers tend to agree. I've only met one who didn't, and he programmed C++ like the standard library (though somewhat more readably), not like he wished it was Java, as most people do.

I most definitely don't program like I wish it was Java, as I don't particularly like Java. I simply believe that C++ is my best choice for what I'm doing right now. I may decide to refine that later and choose to use embedded scripting languages etc. to augment what I'm doing, but I haven't needed to do that yet.

My philosophy is that at any given time, there are three things that you may care about when programming. From least common to most common:

1) You want to write fast code.
2) You want to write correct code.
3) You want it to be easy to write code.

Unfortunately, these tend to work against each other.

If you want to write fast code, you need a language which takes you close to the hardware. It needs to provide a fairly direct mapping between the "high-level" source and the assembly, so that you can pinpoint problems in the assembly and know exactly what needs to change in the high-level code to fix them. The only language I've ever used which does this is C. With C++, as soon as you get into references, copy constructors, operator overloading, etc. there is too much going on for that direct correlation between source and assembly to exist.

If you want to write correct code, you need a language which prevents you from making as many errors as possible. That implies a strict static type system, array bounds checking, an inability to poke around directly at bits and bytes in memory, etc. Obviously, C++ doesn't fit that bill; the closest language I've found is Haskell. Java's unchecked exceptions rule it out, though there are tools that can help with that.

If you want it to be easy to write code, you need a language that allows you to express what you want; that doesn't tie you down to rigid typing structures, or keep you fiddling with minutiae like memory management. This tends to mean a highly dynamic object-oriented language. Unsurprisingly, since this is the most common category for code to be in, this is the category with the most appropriate languages in it. Ruby and Python are two obvious ones. C++ is far too static, and keeps you far too immersed in low-level details to be useful here.

Of course, any given project is likely to consist of parts which fall into each of these three categories, which leads many people to seek a "compromise language" -- one which is "fast enough", "safe enough" and "easy enough". Ultimately, I believe such languages are always a waste of time. You will spend more time optimizing the bits that need optimizing, more time fixing bugs in the critical sections of the code, and much, much more time trying to design your software in such a way that you can actually build it, than if you were using the appropriate language for each part.

These languages are not difficult to tie together. All have easy ways to interact with C, which can be used as a thin layer of glue to stick them all together. The boundaries between the sections of code with different requirements tend to be reasonably well-defined, and you can therefore avoid crossing your language boundaries too often.

If you're using the right language for the job, your code will be as clear, concise, and well-designed as it's possible for it to be. To use the favorite vehicle analogy, you wouldn't try to use a Ford Ka as a personnel carrier in a war zone, and you wouldn't drive to the shops to get the groceries in an APC. Either might "work", but you'd be better off with two separate vehicles.

And please, don't try the argument that "it's easy for me to write C++" or "I don't waste time fighting C++'s memory management and lack of dynamicity" or "I don't make bugs these days"; it's well known that people are notoriously bad at analyzing their own productivity. There are simple studies and metrics that prove that programmers are more productive in more dynamic languages, and write safer code in safer languages.

You forgot to mention of few other important aspects...
- API support, e.g., it's no good to try and use python if you have to create bindings for a lot of external APIs. There are tools that automate this process, but sometimes its an issue.
- If you have to do lots of bit fiddling, C++ is alright. You can write safer code with its stronger type system than C, provided you know what you are doing.
- Fancy languages may have dependencies on 3rd party libs and APIs that may make using them on your platform of choice impractical.

Whether C++ is better than C depends on the job, and your point of view, and your skill. A novice can be lulled by the false promises of extra safety of C++. You can get that extra bit of (type) safety, but you have to work for it. An undisciplined C++ programmer probably creates very hard to find bugs.

The thing OSC is trying to say, is that time learning a new language is never wasted. There's tons of languages that let you do things easier and better than C/C++, and if you really need the extra performance, you can always fall back to C/C++ to do your gruntwork. And the "easier and better" part here isn't an opinion, it's a fact. One interesting revelation that may come to you when you code in higher level languages, is that you need that extra performance edge C will give you less often than you thought.

Now, that having said, I prefer to use Objective-C for GUI work on OS X, or some interpreted language for generic dabbling, but I do have large amounts of C++ code vested in a cross-platform (and multi-language) project.

I believe that C++ can be a convenient language to use, but you have to be aware of its limits, the limits of your understanding of C++ in particular, and the limits of your understanding of programming in general. C++ gives you lots of subtle ways to shoot yourself in the foot, and don't think you're special and it won't happen to you.

DoG Wrote:You forgot to mention of few other important aspects...
- API support, e.g., it's no good to try and use python if you have to create bindings for a lot of external APIs. There are tools that automate this process, but sometimes its an issue.

Yes, "the best tool for the job" being a large third-party c++ library is one of the few good reasons for using it

Sometimes you can stick an abstraction level higher than the library, and avoid binding a large interface, in which case I generally think you should, but sometimes that's not feasible and you have to bite the bullet.

Quote:- If you have to do lots of bit fiddling, C++ is alright. You can write safer code with its stronger type system than C, provided you know what you are doing.

I disagree with this. C++'s type system *is* marginally more strict than C's, but not in ways I've often found to matter. I'd almost certainly write in C here, because there is far less opportunity for the code to run away.

Quote:- Fancy languages may have dependencies on 3rd party libs and APIs that may make using them on your platform of choice impractical.

Unfortunately, sometimes a problem on Windows. Seldom a problem on Mac OS X and Linux, and not a problem for the particular languages I listed in my prior post.