Language wars


Recently I had to brush up on my C++ knowledge for a job interview. I have been coding in C++ for maybe fifteen years now but for the last three years I’ve spend most of my programming time doing C# instead because it pays my bills. So I decided to get a quick overview of the fundamental syntactic, idiomatic, and ideological differences between C++ and C# to restore my memories.

I searched for C++ vs. C#. My bad. I should have known better and I guess I even did but hoped for some helpful results anyway. Instead I was presented lots of opinionated and subjective attempts to answer ill-fated questions about performance and features. I will stop right here because I couldn’t say what happens when you ask these kinds of questions any better than Eric Lippert, Jeff Atwood, and Steve Yegge. In fact you should stop reading my blog now and read theirs instead.

Language matters?

Don’t ask which is better. Ask what is the right tool for the job. In the end you should base the choice of programming language solely on project constraints and productivity considerations. The latter in turn are likely much more dependent on the expertise of your team than anything else. And for the vast majority of all software performance doesn’t even matter much. But then again the vast majority of software are apps, websites, and scripts. Not my line of business. I’m a specialized minority.

I do massively parallel computations and soft real-time applications. Stuff where you can’t afford having an operation take ten milliseconds to complete. Obviously I care a lot for performance. When it comes to languages and libraries less overhead and more control is better for me – as long as productivity doesn’t suffer too much. Because in the end someone has to pay for the time my colleagues and I spend on turning ideas into code.

On a more holistic scale for performance and productivity both C++ and C# are somewhat in the middle. Perhaps with C++ favoring performance and C# favoring productivity whenever the two are mutually exclusive. Which is less often than you might think. If you really need raw performance you should head towards C, assembler, programmable hardware, or even custom chips. Oppositely if productivity is prime look for existing solutions in terms of frameworks, libraries, or even complete software.

C++ vs. C#

Lets compare these programming languages anyway. For reasons of scope I will just ignore all other programming languages. But you shouldn’t! Always be aware of what tools are available. They might be the better fit for the job.

I will also not consider platform dependence at all. If you have a very specific target platform in mind or need to support a wide variety of platforms chances are high that C# is not an option. This is a good example of project constraints mentioned above. Make sure to get those right before going into details.

Because my post turned out much longer than envisioned I’m going to break the actual comparison up into multiple parts and link them here.

  1. Memory management
  2. Type system
  3. Polymorphism
  4. Syntax

Importance of Knowledge

Knowledge Age

If you run a business in the knowledge age then there is a good chance that it involves some kind of development. That’s were engineers come into play. You can say engineering is about applying scientific knowledge and ingenuity to develop technical solutions. But because there’s always more than one solution to a problem it’s also a lot about making good decisions. Decisions that will affect the future of your business!

engineering knowledge


In the presence of multiple possible solutions to a given problem the key to making good decisions is knowing their respective strengths and weaknesses. Oftentimes there is a tradeoff. Therefore it’s a good idea to evaluate the available options according to your individual business requirements. So make sure to know your requirements!

Also note that these decisions might occur on multiple levels of abstraction. This is especially true for software development. Strategic decisions like what target platforms to support, what programming language to use, and what tools to employ are usually made by the management. On the other hand most low level decisions like what algorithms to apply and how to implement them are usually left to the programmer. Inbetween senior engineers decide about frameworks, architecture and data structures — the core of your product.

decision hierarchy


Every decision has far reaching consequences on the levels below it. They force constraints and limitations on the available options further down. That is why you want your high level decisions to be made early and to stay stable. Also make sure they are good. Otherwise you would be wasting time, money, and lots of effort.

Mid level decisions tend to have the strongest implications on the ability of the product to actually meet the business requirements. This is where fulfillment is created within time and budget — or where it fails. This is also where the ability to react to ever changing requirements is determined. Like with a huge building you want your architecture to be clean and stable, yet flexible enough to cope with unforeseen demands. A rigid architecture will soon become messy, and a messy one will soon become unmanageable. So well engineered architecture and data structures are key to retaining agility.


Ingenuity and scientific knowledge is necessary to come up with possible solutions to existing problems. And by now it should be clear that a deep understanding of the available options and their respective implications is key to making a good decision. All of this highlights the importance of knowledge.

Engineering knowledge can be obtained by higher education, professional training, and experience. Your business will want to acquire, build, and retain it, because loosing knowledge means reduced agility, going into dead ends, and ultimately loosing the ability to fulfill requirements!


  • Acquire knowledge by hiring highly trained and experienced people.
  • Evaluate each possible solution regarding individual business needs.
  • Document each decision, its rationale, and its implications. It seems like a lot of work but it’s pays off. Omit documenting the implementation!
  • Build additional knowledge through reflection and team training.
  • Keep knowledge by retaining your team. It’s good for your business!

I hope all of this makes sense to you. It might even be obvious to you. I totally agree, it should be obvious. But it’s a lot easier said than done and I’ve seen noble goals go overboard as soon as time is short. Resist the temptation of shortsighted decisions!