I was interviewing a candidate recently, and we were talking about some of the programming languages he claimed to know, which was mainly focused around C++ and C#. We started to discuss some of the types of problems he finds easier to solve in each when he said something I found very misleading: “A programming language is really just syntax”. As we talked more, I started to ponder what a shallow understanding of a language this really was. It’s kind of like questioning whether a dollar is a dollar is a dollar. Smart financial people know that the source of the dollar is very important, and so the utter simplification is misleading.

Before I get too far into this, I will note that if you’re using .Net, you can get a lot closer to making the premise of the initial argument, because the .Net languages all can support the same APIs. That wasn’t the case for this individual, as he was using C++, not C++/CLI. With that being said, let’s get into some of the real substantial differences:

1) The standard libraries that the language supports. I find this to be one of the most underrated aspects of working with a language. I think part of the reason is that when you use some languages (C++) there’s a large population of programmers who don’t really make good use of the standard libraries. In my experience, this is often because they sometimes fall into using non-portable APIs, such as Microsoft’s ATL or MFC instead of STL containers, or libraries that may be considered more suitable for an embedded environment. Anyway, I think this is a critical feature, because, again consider the example of C++: Something as commonly used as XML is not standard. This is almost unfathomable for programmers of languages like Java or C#. Meanwhile, the flipside is .Net, which is immense and becomes very difficult for a developer to be proficient in all of it.

2) Third party libraries the language supports. I would consider this almost as important as the standard libraries issue. Unlike the standard libraries, there’s a much better chance that the third party libraries have API interfaces to be used in multiple languages. This will be one of the the top things you would consider when choosing the appropriate language for a task.

3) Language Paradigms: This is another feature which gets underrated at times. Does the language properly support Object-Oriented Programming? Template Meta-Programming? Functional? How easily does it support multi-threading? Again, all of these are critical differences between languages which go well beyond syntax.

4) Static Typing or Dynamic Typing or Both (coughC#cough)? With static typing, you can potentially find a lot of structural errors during compile time and need less code coverage during your unit tests. With dynamic typing, you don’t have these luxuries, but have much better support for rapid development.

5) The tools that are supported for your language.

6) Syntax. I consider this one of the least important differences between languages. It’s very easy for a professional programmer to adjust to a new syntax, assuming it isn’t completely nonsensical.

In the end, I think of this like deciphering any sort of spoken or written language. At the end of the day, if you aren’t able to communicate effectively, then your words are meaningless. This goes far beyond sentence structure. When discussing programming languages, it goes far beyond syntax.

.Net, ATL, C++, Developers, Functional Programming, MFC, Object-Oriented, STL, Template Meta-Programming, XML

This is a post I decided to migrate from my old blog and ultimately removed from my old blog.  Hopefully you will find the information useful:

I spent a little time reviewing threading technologies. OpenMP is the option that gets the most attention, because it’s an open standard and is the most likely to stick around. However, in my review, I stumbled upon Intel Threading-Building Blocks, and I have to say it’s a better option, despite being a commercial library. Here’s a head-to-head comparison from my PoV:

1) Compiler support: OpenMP uses pragmas, so it needs explicit compiler support, although most of the newer compilers support it. TBB is a portable library, so it can be built and added for older compilers. As Stroustrop says, it’s better to have something added as a library rather than keywords and compiler directives, because it opens up possibilities. Advantage: TBB.

2) Code clarity: In cases where OpenMP can be used, OpenMP involves very little work in modifying code if you have a parallelizable loop, for example. TBB involves functors, and while STL algorithms are nice, it’s also nice to have the ability to do things inline. I give OpenMP the edge, because in the best case, OpenMP is a little cleaner. In the worst case, TBB may be cleaner, but I’ll give this one to OpenMP. Advantage: OpenMP

3) C++ Support. OpenMP is clearly not targetted towards C++ programmers. It doesn’t support many important C++ constructs. TBB seems to support these better. The iterator support is quite important. I understand that OpenMP intends to be support C++ with the 3.0 spec, but it’s still quite lacking. Advantage: TBB

4) Concurrent containers. OpenMP has nothing for extra C++ support. TBB has a few concurrent containers and I believe there’s more in the next version. I can’t express how many times I would’ve parallelized a piece of code if I had something like concurrent_queue available. Major props, Intel. Huge Advantage: TBB

5) Exceptions. OpenMP has an issue where you throw an exception into an OpenMP thread and the behavior is undefined. This is not surprising, but they have no plans to correct this issue. This issue alone makes OpenMP unusable for production code, because there’s too much work to do to make OpenMP handle exceptions correctly. TBB states an intent to acknowledge exception handling and propagate the first exception. I believe it does this correctly. Advantage: TBB

Overall, as a C++ programmer, I think TBB wins on almost all aspects. Since it’s using threading underneath, it’s clear to me that you can achieve similar speed-ups with both. I believe TBB gives more opportunity for taking existing C++ code and making smaller modifications, while OpenMP would require you to “dumb down” your code to C level in order to take advantage of things. If you’re a C programmer, I don’t have any doubt, however, that you’d want to consider OpenMP. TBB is the C++-friendly version of OpenMP, as far as I’m concerned.

C++, Intel, OpenMP, TBB, Threading, Threading-Building Blocks