By Alex Korban. Webpage link at bottom

Most people will agree that C++ is a fairly complex language. But just how complex is it? I got curious about quantifying that by comparing the number of concepts a programmer has to understand to learn a programming language in its entirety.

Concepts in my definition include large categories like classes and operators, as well as more fine grained things like if-else statements and while loops. There is a lot of variation in the complexity of different concepts, so their number can only serve as a rough measure of language complexity. Nevertheless, I think it’s interesting.

I chose C++, CoffeeScript and Ruby for my comparison. CoffeeScript and Ruby are dynamically typed so they are significantly different from C++. However, all three are multi-paradigm general purpose languages, supporting (to a reasonable degree at least) object oriented, functional, procedural and generic programming. So this post is about C++ vs. dynamically typed languages.

I think it would also be interesting to make a comparison with other statically typed languages such as F# or Scala but I’m not really familiar with them, so it would be hard for me to do.
CoffeeScript

First up, let’s look at CoffeeScript:



It has a total of 68 concepts divided into 8 major groups.

Note that I listed metaprogramming as one concept because it’s largely based on the concept of executable class bodies.
Ruby:



Ruby is clearly more complicated, with 96 concepts in 11 major groups. It’s got a more sophisticated class model than CoffeeScript, as well as things like constants, blocks and operator overloading.

C++

Finally, here is C++:



There are 186 concepts in 18 groups on this diagram, double the number of Ruby concepts and almost 3 times more than in CoffeeScript!

I believe that some of the concepts in C++ (such as name resolution) are also comparatively more complex, with a lot of nuanced rules. The concept of names in C++ is more involved than in the other languages because there are many different categories. In dynamic languages, more or less everything is either a constant or a variable (including class names and function names).

I omitted the concepts of compilation and linking because the other two languages don’t have them.

From the diagram we can see that there are many reasons for the complexity. Part of it is the static type system, another part is templates, yet another part is the name system, as well as the complex class model. The underlying drivers are of course performance and type safety.
What’s not in the diagrams?

I didn’t include a lot of other things that a programmer is required to know in order to use a language in practice:

standard libraries
language idioms and best practices
concurrency concepts
design patterns

These things become more prominent when a programmer progresses from learning to mastering a language.

I think that C++ would win the prize for complexity in such a comparison too. For example, there are books like C++ Coding Standards: 101 Rules, Guidelines, and Best Practices (there are in fact 101 rules in there), and Effective C++ containing 55 pieces of advice. These books don’t deal with esoteric situations, they are aimed at normal everyday code. That’s a lot of extra knowledge!

While other languages have their best practices and idioms too, I think their number is quite a lot smaller.
So what’s the point?

My goal isn’t to complain about how huge and incomprehensible C++ is. I believe there is no alternative to C++ for large projects with strict hardware constraints or performance requirements when you take the availability of modern tools, libraries and developers into account.

However, I do think that it’s important to highlight what programming in C++ entails because it has implications for how it’s taught and when it should be chosen for a project.

It isn’t a language that can be picked up quickly. It takes a long time to learn and even longer to master. Because of this, I think there is a lot of value in learning C++ “from the top down”.

With C++11, it has become easier to start with the modern high level subset of C++ (and the standard libraries), and then gradually add on the intricacies and the low level features. In other words, std::shared_ptr comes before raw pointers, lambdas come before functors, and std::array comes before C style arrays.

When choosing C++ for a new project, it’s a good idea to consider the level of experience of the developers or the time available for learning if C++ is new to them.

I think that it’s also good to keep in mind that the complexity of C++ results in a significant disparity in the level of language knowledge between developers, which has to be taken into account in interviews and in providing training. Significant knowledge disparity within a team isn’t pleasant for people on either end of the spectrum.

Finally, here are the diagrams side by side for a quick visual comparison:



Link: http://www.cpprocks.com/cpp-ruby-coffeescript-language-complexity/

Very interesting analysis; visual representation always drives the point home the way nothing else can.

What the article calls complexity is simply a measure of how high level each of the measured languages is. Therefore, CoffeScript naturally weighs in as the least complex (as would languages like JavaScript and PHP); Ruby naturally pops up midway between the high level CoffeScript and low level C++.

The nearer a language is to the metal, the more granular the control it gives the developer.

awesome C++

Beaf: Therefore, CoffeScript naturally weighs in as the least complex (as would languages like JavaScript and PHP); Ruby naturally pops up midway between the high level CoffeScript and low level C++.

Correction: C++ is a high level language.

The nearer a language is to the metal, the more granular the control it gives the developer.

Right on the marble.

The Arbiter:

Correction: C++ is a high level language.

Lol! Bro, I can see this developing into one heluva argument; so lemme kick it off:
Technically, neither of us is correct. C++ is really an intermediate-level language.

Beaf: Lol! Bro, I can see this developing into one heluva argument; so lemme kick it off:
Technically, neither of us is correct. C++ is really an intermediate-level language.

It's relative. Languages become more high level over time. When C was released, it was a high level language. Then C++ came out, making C seem low level. Then Java came out, making C++ seem low level. Now languages like PHP/Python/Ruby/Javascript are reigning, and even Java seems low level compared to them. By 1970s standards, all the programming languages we use today are high level languages, but that makes the whole language level nomenclature completely useless, really.

Interesting. I can see where this is heading. Lets chew on this a little:

"The easiest way to categorize a programming language as "high level" is to actually determine whether or not it is a low-level language. The typical definition of a low-level language is one which does not require a compiler or interpreter to run. Basically, a high-level language is one which needs to be turned into a low-level language (bytecode/assembly instructions) before it can execute."

Based on the above argument C++ is most definitely a high level language. It is widely accepted that C++ inherited features of its low level predecessor C. However, this does not categorize it as an intermediate language because:

"In computer science, an intermediate language is the language of an abstract machine designed to aid in the analysis of computer programs. The term comes from their use in compilers, where a compiler first translates the source code of a program into a form more suitable for code-improving transformations, as an intermediate step before generating object or machine code for a target machine." (Wikipedia)

Also

"A variation in the meaning of this term is to refer to those languages used as an intermediate language by some high-level programming languages which do not output object or machine code, but output the intermediate language only, to submit to a compiler for such language, which then outputs finished object or machine code. This is usually done to gain optimization much as treated above, or portability by using an intermediate language that has compilers for many processors and operating systems, such as C. Languages used for this fall in complexity between high-level languages and low-level languages, such as assembly languages."

Seun's position reflects the evolutionary trend of programming languages which reflect shifts in concepts of 'High' vs 'Low' language representations. This can seen in the context of development of C++, Ruby and then cofeescript. The latter is seen to offer ease of coding in a more 'human language' while still offering the functionality of the other two languages. I however beg to disagree with the 'relative' concept. The definition of programming languages still retains its hardline meanings. Until a new definition removes the necessity of a compiler between high and low level languages, the current classification of programming languages will not change anytime soon.

Seun:
It's relative. Languages become more high level over time. When C was released, it was a high level language. Then C++ came out, making C seem low level. Then Java came out, making C++ seem low level. Now languages like PHP/Python/Ruby/Javascript are reigning, and even Java seems low level compared to them. By 1970s standards, all the programming languages we use today are high level languages, but that makes the whole language level nomenclature completely useless, really.

I agree. Thats why I told The Arbiter that he was kicking off a huge argument. The level of abstraction is relentlessly increasing as the decades match on, even JavaScript will be able to access native functions with Windows 8; who'd a thunk it?

The Arbiter: "The easiest way to categorize a programming language as "high level" is to actually determine whether or not it is a low-level language. The typical definition of a low-level language is one which does not require a compiler or interpreter to run. Basically, a high-level language is one which needs to be turned into a low-level language (bytecode/assembly instructions) before it can execute."

There are quite a few faults with your definition. Lets takes them one at a time:

"The typical definition of a low-level language is one which does not require a compiler or interpreter to run." This really isn't correct as all low level languages (aside machine code, but including assembler) are compiled - they need a compiler; they cannot just run. However, they do not need an interpreter or compiler to be converted to machine code.

"Basically, a high-level language is one which needs to be turned into a low-level language (bytecode/assembly instructions) before it can execute." This is partially wrong as bytecode needs a virtual machine (or other interpreter) to interprete it to native code.

The Arbiter: "In computer science, an intermediate language is the language of an abstract machine designed to aid in the analysis of computer programs. The term comes from their use in compilers, where a compiler first translates the source code of a program into a form more suitable for code-improving transformations, as an intermediate step before generating object or machine code for a target machine." (Wikipedia)

C++ is directly converted to machine code, so the above makes it a low or intermediate level language.

Seun: It's relative. Languages become more high level over time. When C was released, it was a high level language. Then C++ came out, making C seem low level. Then Java came out, making C++ seem low level. Now languages like PHP/Python/Ruby/Javascript are reigning, and even Java seems low level compared to them. By 1970s standards, all the programming languages we use today are high level languages, but that makes the whole language level nomenclature completely useless, really.

Beaf: I agree. Thats why I told The Arbiter that he was kicking off a huge argument. The level of abstraction is relentlessly increasing as the decades match on, even JavaScript will be able to access native functions with Windows 8; who'd a thunk it?

Abstraction is a characteristic of high level languages but it is not a defining one since even assembly languages have certain levels of abstraction. Differences in abstraction lead to the generational classification of languages which remains accepted. If i were to infer the above statements imply high level languages have increased in abstraction over the years, i agree 100%. I still maintain that as long the current definition remains, nothing changes much.

Beaf: "The typical definition of a low-level language is one which does not require a compiler or interpreter to run." This really isn't correct as all low level languages (aside machine code, but including assembler) are compiled - they need a compiler; they cannot just run. However, they do not need an interpreter or compiler to be converted to machine code.

Delving into this will really blur the lines for the not so technical as the arguments are more academic (theoretical). In layman's terms a compiler takes an abstract (high level) language and translates it to a low level (machine code) language, while an assembler translates assembly (symbolic) code to machine code.

Computer science recognizes a distinct division in low level languages. Assembly (symbolic) language (with its levels of abstraction) which requires translators and native (machine) language which can be directly executed. This is clearly evident to those who have done FPGA programming.

Beaf: "Basically, a high-level language is one which needs to be turned into a low-level language (bytecode/assembly instructions) before it can execute." This is partially wrong as bytecode needs a virtual machine (or other interpreter) to interprete it to native code.

Thanks for catching that one. Copy and paste devil. the correct statement should be "Basically, a high-level language is one which needs to be turned into a low-level language (native instructions) before it can execute."

Beaf: C++ is directly converted to machine code, so the above makes it a low or intermediate level language.

I shall ignore the erroneous general implications of your statement and focus on the issue at hand. It is acknowledged that C++ inherited elements of C's low level features (which i have already admitted to) but this are highly insignificant compared to the level of abstraction the language provides. As i have conclusively shown in my statements, C++ is a high level language. This fact is incontestable unless if the definition of programming languages undergoes a radical change.