• Announcements

    • khawk

      Download the Game Design and Indie Game Marketing Freebook   07/19/17

      GameDev.net and CRC Press have teamed up to bring a free ebook of content curated from top titles published by CRC Press. The freebook, Practices of Game Design & Indie Game Marketing, includes chapters from The Art of Game Design: A Book of Lenses, A Practical Guide to Indie Game Marketing, and An Architectural Approach to Level Design. The GameDev.net FreeBook is relevant to game designers, developers, and those interested in learning more about the challenges in game development. We know game development can be a tough discipline and business, so we picked several chapters from CRC Press titles that we thought would be of interest to you, the GameDev.net audience, in your journey to design, develop, and market your next game. The free ebook is available through CRC Press by clicking here. The Curated Books The Art of Game Design: A Book of Lenses, Second Edition, by Jesse Schell Presents 100+ sets of questions, or different lenses, for viewing a game’s design, encompassing diverse fields such as psychology, architecture, music, film, software engineering, theme park design, mathematics, anthropology, and more. Written by one of the world's top game designers, this book describes the deepest and most fundamental principles of game design, demonstrating how tactics used in board, card, and athletic games also work in video games. It provides practical instruction on creating world-class games that will be played again and again. View it here. A Practical Guide to Indie Game Marketing, by Joel Dreskin Marketing is an essential but too frequently overlooked or minimized component of the release plan for indie games. A Practical Guide to Indie Game Marketing provides you with the tools needed to build visibility and sell your indie games. With special focus on those developers with small budgets and limited staff and resources, this book is packed with tangible recommendations and techniques that you can put to use immediately. As a seasoned professional of the indie game arena, author Joel Dreskin gives you insight into practical, real-world experiences of marketing numerous successful games and also provides stories of the failures. View it here. An Architectural Approach to Level Design This is one of the first books to integrate architectural and spatial design theory with the field of level design. The book presents architectural techniques and theories for level designers to use in their own work. It connects architecture and level design in different ways that address the practical elements of how designers construct space and the experiential elements of how and why humans interact with this space. Throughout the text, readers learn skills for spatial layout, evoking emotion through gamespaces, and creating better levels through architectural theory. View it here. Learn more and download the ebook by clicking here. Did you know? GameDev.net and CRC Press also recently teamed up to bring GDNet+ Members up to a 20% discount on all CRC Press books. Learn more about this and other benefits here.
Sign in to follow this  
Followers 0
TheResolute

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

12 posts in this topic

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.
0

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.
2

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.
0

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
2

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.
1

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.
0

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]
2

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.
1

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.
0

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
1

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  
Followers 0