Sign in to follow this  
TheResolute

Why is it faster to develop in certain languages over others?

Recommended Posts

I see a lot of comments about how writing code in something like C# is faster than C++, and I fail to understand why. This has nothing to do with performance of applications; simply the difference in taking say 3 weeks to develop in a certain language and 6 in another. Also, I am really just concerned with mainstream languages such as C#, C++, VB, Java, Lua, Python, etc.


Is it just about compile time, which seems to be the reason that developing in a scripting language is faster than a compiled one?
Does it have to do with memory management and garbage collection, because it just takes forever to remember to delete your pointers?
Possibly it involves inherent access to libraries or functions such as the printf("") in Python as compared to cout << "" in C++, is that the case?

Basically, I am trying to understand why the general consensus seems to be that writing code in C# (for example) is better than writing code in C++ (for example), but the performance of that running code is worse.

Share this post


Link to post
Share on other sites
[quote name='TheResolute' timestamp='1347589644' post='4979922']
Is it just about compile time, which seems to be the reason that developing in a scripting language is faster than a compiled one?
[/quote]

Not _just_ but it helps.

[quote name='TheResolute' timestamp='1347589644' post='4979922']
Does it have to do with memory management and garbage collection, because it just takes forever to remember to delete your pointers?
[/quote]

That helps, but isn't a huge contributor.

[quote name='TheResolute' timestamp='1347589644' post='4979922']
Possibly it involves inherent access to libraries or functions such as the printf("") in Python as compared to cout << "" in C++, is that the case?
[/quote]

This is a big one. Even basic stuff like unicode strings and a sane date class are simply non-existent in core C++.

Another big contributor is the lack of tooling (static analysis, good intellisense, good refactoring support, good debugger tie ins) that C++ suffers from due to issues in its design. So C# developers fix syntax errors quicker, identify bugs faster, and generally spend more time making stuff go than figuring out what C++ bear trap they stepped in now.

[quote name='TheResolute' timestamp='1347589644' post='4979922']
the performance of that running code is worse.
[/quote]

While that is the consensus, it is (at the very least) debatable. Skill of the developer and the problem at hand matter a lot more to that sort of thing than some inherent language disparity.

Share this post


Link to post
Share on other sites
[quote name='Telastyn' timestamp='1347591611' post='4979928']
Even basic stuff like unicode strings [...] are simply non-existent in core C++.
[/quote]
Just to expand on this: [font=courier new,courier,monospace]std::basic_string[/font] doesn't really care about encoding, and although C++ has some support for unicode (like [font=courier new,courier,monospace]char[/font] being required to be at least 8 bits so it can be used in UTF-8 strings), it (and other algorithms/functions in C++ that deal with strings) doesn't work with actual unicode code points. [font=courier new,courier,monospace]std::string::length()[/font] won't return the number of UTF-8 code points in the string; it just returns the number of code units. Gotchas like this can make something that seems like it should be a simple operation into a rather complex and time consuming (development wise) one.

Share this post


Link to post
Share on other sites
Thank you for these clarifications so far, and I would like to note that I asked this exact question on Stack Overflow and watched it be mocked and closed within minutes. Kudos to the GameDev.net community! Edited by TheResolute

Share this post


Link to post
Share on other sites
[quote name='TheResolute' timestamp='1347589644' post='4979922']
I see a lot of comments about how writing code in something like C# is faster than C++, and I fail to understand why. This has nothing to do with performance of applications; simply the difference in taking say 3 weeks to develop in a certain language and 6 in another. Also, I am really just concerned with mainstream languages such as C#, C++, VB, Java, Lua, Python, etc.
[/QUOTE]

Which of the following could you do faster:
1) Write an essay with perfect grammar/spelling on the First World War in English?
2) Write an essay with perfect grammar/spelling on the First World War in Japanese; using a textbook and translation software?

Obviously, you will be able to deal with the English essay much faster (unless, by some chance, you're a native Japanese speaker). English is what makes sense to you. It's grammar (syntax) is familiar to you and just seems "right", as you've grown up speaking, reading and writing it. You focus your time on the quality and content of the essay, rather than struggling with the [i]language[/i] itself. Likewise, some programming languages are more familiar to humans while others are more cryptic and difficult to read/comprehend.

Take a look at the language called [url="http://en.wikipedia.org/wiki/Brainfuck"]brainfuck[/url]...yes, it's a real language and I'm not trying to use profanity on the forums. It's incredibly cryptic... designed to be obfuscated and virtually unreadable to amuse and challenge programmers. Now, if you will, imagine how much longer it would take you to write a Windows application in [i]brainfuck [/i]than it would in C++. C and C++ are much more "human-friendly" and understandable, so you can turn the ideas in your head into [i]working code[/i] more easily than you can convert it into cryptic brainfuck or x86 assembly language. This is precisely the answer to your question. As newer languages come out and grow to maturity, many of them become more "human-friendly" than their ancestors. C#, for instance, is a lot more "elegant" and readable than C.

[quote name='TheResolute' timestamp='1347589644' post='4979922']
Is it just about compile time, which seems to be the reason that developing in a scripting language is faster than a compiled one?
Does it have to do with memory management and garbage collection, because it just takes forever to remember to delete your pointers?
Possibly it involves inherent access to libraries or functions such as the printf("") in Python as compared to cout << "" in C++, is that the case?
[/QUOTE]

"Compile time" means one of two things: 1) the amount of time it takes to compile code 2) the time [i]when[/i] code is compiled. For example:

1) "The compile time for this project is unbelievable! We need to speed up our builds somehow!"
2) "In C#, a [i]readonly[/i] variable is assigned at compile-time."

This doesn't have anything to do with how fast you can finish a project in a language because the languages humans find hardest to understand (assembly language, C, C++, etc) tend to compile faster than a managed language like C#.

[quote name='TheResolute' timestamp='1347589644' post='4979922']
Basically, I am trying to understand why the general consensus seems to be that writing code in C# (for example) is better than writing code in C++ (for example), but the performance of that running code is worse.
[/quote]

That used to be the "consensus", but not so much anymore... And it has [i]never [/i]been a consensus that any practical language was necessarily "better" than another...

About speed, you will be surprised at what a modern C# application can do. I'm amazed every time I do a new project. The real overhead with a .NET application is in the JIT ("Just In Time") compiling process... this is, essentially, when code is compiled on-the-fly as the application runs. The JIT compiler only compiles portions of the IL assembly that are needed. For instance, if the "PrintDocument(string name)" method is never called it is never compiled. JIT compiling slows the application down a bit, but this tends to only occur when the application is starting and everything is being "JIT'ed" or when a particular method is compiled for the first time. Wanna see it yourself? Write a C# method that takes a long time to iterate through a large sequence. Wrap it in the "Action" delegate-type and use a System.Diagnostics timer/stopwatch to time the code. Call it 5x's in a row and record the time it takes to complete. The first call will seem sluggish, but the following 4 will be almost indistinguishable from native code in terms of speed. Why? Because the JIT compiler turned the IL [i]into[/i] native code behind the scenes!

I have seen many occassions where a C# application can not only out-perform but [i]burn[/i] a C or C++ application (and surprisingly, sometimes even assembly language as hand-written instructions aren't always optimized for speed). The first notable instance I saw of C# outperforming C was when I had to write a special tool for creating software patches for a larger project. My C version performed very well, but we weren't quite pleased with it... Rewrote the entire thing in C#, optimized the code and disabled some of the CLRs checks, and the damn thing outran the C version. But [i]why[/i]?

A C# application has a smaller "memory footprint"... only the [i]needed[/i] code is compiled to begin with. The CLR manages objects and collects garbage transparently, not only reducing general programming errors and memory leaks but greatly increasing memory [i]efficiency[/i]. Once the code is run through the JIT process it is essentially a native binary image itself, with all the added benefits of being a managed application. Imagine how much faster C and C++ would be if they had highly efficient garbage collection, automatic memory management and reduced memory footprints! This is just part of the reason, but some of the most important things.

Of course, results can vary from application to application, programmer to programmer and algorithm to algorithm. But don't fall into the trap of thinking languages have "fixed" performance... they can perform as good (or as awful) as you make them, to a certain extent.

Share this post


Link to post
Share on other sites
[quote name='TheResolute' timestamp='1347597251' post='4979939']
Thank you for these clarifications so far, and I would like to note that I asked this exact question on Stack Overflow and watched it be mocked and closed within minutes. Kudos to the GameDev.net community!
[/quote]
Quick off-topic but in their defense, this wasn't an ideal question for Stack Overflow - even if I agree that they tend to be a bit overzealous with respect to their FAQ. However, it would have made for an excellent Programmers.SE question... Glad you posted here though.

Share this post


Link to post
Share on other sites
The essential difference is more or less what Paul Graham described as the [url="http://paulgraham.com/avg.html"]Blub paradox[/url] (approximately half way down, though the overall essay is worth reading too).

If you've ever transitioned from using one language to another, you know this feeling. In the newer language, when you eventually get to the comfortable point, you will generally find that you are either more or less productive than you were (hopefully more, but you might be moving to maintaining something like [url="http://thedailywtf.com/Articles/A_Case_of_the_MUMPS.aspx"]this[/url]).

I felt it when I moved from a Basic dialect to C++, but I didn't know how to program at all back then. Likewise when using Java or C#, I find I get more done than when I write C++. Now, when using something like Ruby I can complete entire programs in a fraction of the time it would take me to write them in Java or C# - an hour instead of half a day (mostly small utilities, I don't believe this particular productivity ratio scales linearly!).

The reasons for this are many, and include:[list]
[*]Simple syntax (e.g. [url="http://www.ozonehouse.com/mark/periodic/"]not perl[/url])
[*]Availability and easy of installing/linking to helper libraries (e.g. Ruby gems vs C libraries)
[*]Consistent naming/behaviour (curse your oily hides PHP/Javascript!)
[*]Strong conventions that eliminate style mismatches
(e.g. C++ libraries tend to be a mix of variations on old_c_convention with ModernCamelCase, rarely happens in Java or C#).
[*]Language features:
[list]
[*]Automatic garbage collection and foreach loop (reduce mental overhead)
[*]First class functions and closure (reduce boilerplate).
[*]etc...
[/list][*]Tool support (good IDE, debuggers, profilers ...)
[/list]

Share this post


Link to post
Share on other sites
[quote name='rip-off' timestamp='1347622222' post='4980017'][list]
[*]Consistent naming/behaviour (curse your oily hides PHP/Javascript!)
[/list]
[/quote]
Forgive me for going off topic, but this line made m LOL. It was a pained LOL, though, with plenty of bitterness. Because, yes. Curse them.
[quote]
[list]
[*]Language features:
[list]
[*]Automatic garbage collection and foreach loop (reduce mental overhead)
[*]First class functions and closure (reduce boilerplate)
[/list]
[/list]
[/quote]

These are the big ones for me, and why I increasingly use Lua over C++ even though I've been using C++ since the early 90s. It's interesting to see how much time you spend in lower-level languages just ensuring that you are allocating and managing your memory correctly, and tracking down the leaks that still slip through. And the boilerplate that rip-off mentions. You can spend so much time just building the structures upon which to hang things, then even more time building the things to hang on those structures, when the simple choice of using another higher-level language means that a lot of those structures are already built into the language, or are rendered redundant due to alternatives that are now available.

Of course, it all comes down to the exact task you are trying to perform. Languages all have their strong and weak points, and it is important to gain the experience to be able to match up a particular task with the language that most closely matches the requirements of the task. Otherwise, you get bogged down.

Share this post


Link to post
Share on other sites
The language matters but not as much as the library support and IDE.
When people say 'language' they generally mean 'platform' which includes the whole-shebang not just the language.

C++ was suppose to bring on lots of reuse and lots of libraries but this resulted [generally] in free low-quality libraries or very expensive high-quality libraries (with notable exceptions but generally).
So when you want to create a thread in C++ and have it execute within the context of your class... it's a PITA.
The language isn't thread-aware, the libraries aren't thread-aware, the language is barely object-aware, so you have to write a bunch of esoteric OS-level code to make it happen.
If you want it to be easily usable & dynamic then you have to write a complex template class and it will be buggy and require debugging, etc...

C# already had all of this built in. So creating a thread in C# is a 10 second task whereas it's a day or two of work in C++ if you're starting from scratch.
If you move jobs, you move code-bases, so now you have to relearn their C++ code-base.
Move jobs with C# and you create a thread the same way.


Intellisense was the single most productivity enhancing invention of the 1990's (regarding coding).
Using a language that doesn't have a modern IDE is painful and slows you down. Edited by Shannon Barber

Share this post


Link to post
Share on other sites
As pointed out, the lack of built in libraries is by far the biggest issue. There's also a fair bit of boilerplate involved in implementing proper "rule of 5" (formally known as the rule of 3...) classes, and the header system is relatively complicated and requires you to jump from source to header file as you're adding new methods. And debugging compiler errors in template classes is potentially a time waster, since they can be *very* cryptic, and usually you're not told which part of the calling code actually triggered the error.

c++ does allow you to implement RAII based memory management which is much better than garbage collected implementations when you need to control exactly when you release a resource. It's easy to make mistakes and leak memory building a c++ object, but when correctly implemented, the caller rarely has to worry about managing memory at all.

Share this post


Link to post
Share on other sites
Some languages target systems development, and some target software development.

C# primarily targets software development, so it implements a huge standard library. Everything in the library works together as a whole. You just use the appropriate classes and data types, and move on with implementing the main program.

When you need a lot of that stuff in C++, you need to write your own library, or hunt one down. Then it's up to you to keep track of all these library's license terms, versions, bugs, and ability to interact. Sometimes these libraries expect an entirely different programming style to how your program was implemented, and you have to write a glue layer to try and mesh 2 different concepts. Sometimes libraries all use different data structures to represent the same thing, and you have to find a way to convert them on the fly to pass them back and forth. All these libraries you use will be islands onto themselves. You spend a lot of time programming ways for them to communicate and work together. Edited by Daaark

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now

Sign in to follow this