38 replies to this topic

[dilyan_rusev]

I've worked on a sizable C#/.NET project (and a few smaller), and to be fair, it wasn't the language itself that mattered. It was the entire .NET library, and the fact that it has most of the stuff you'll ever need in a business application. I have no experience writing games in .NET, but I gues most of the stuff would still apply. Tooling provided by Microsoft is good, and practically free for many business development companies (for startups, for students, for gold partners, etc). What I don't like in .NET is that every few years Microsoft is jumping ship, and abandoning a good technology for something flashier. They create a lot of hype around a project, and then abandon it after a few years. It's really sad, because the language and the platform are really good.

I have limited experience with other "advanced" programming languages, like Java and Python. Python is cool, but the library is a mess: a slew of coding conventions, duplicated libraries, etc. It simply isn't coherent - some libraries are thin wrappers around C libraries, others provide a "pythonic" higher-level abstraction.

Java seems to be very pleasant to work with, and am impressed by SWT so fart. Still, I'm quite a novice Java programmer, and haven't used most of the libraries yet (actually, nothing outside SE). It seems that a lot of thought was put into it, and a bit over-engineered in places (e.g. to create an XML document, you need to create 2 factories, if I remember correctly). This is the big difference in Java vs .NET in my experience so far: Java feels academic work, and .NET feels like industry work. Apart from the obvious differences, of course.

C++ isn't a bad language. Especially with the stuff introduced in C++11. My problem with it is the ancient compiler/linker infrastructure. In almost all other languages, you can declare variables anywhere you want, so long as scoping is OK. In C/C++, header files are just copy-pasted. I hate that I need to use header files at all. Also, unless you are using an engine/toolkit that does everything for you, you are going to die in pain. Every library has been built differently - from naming conventions, to strings, to unicode, to threading, to exceptions vs return codes vs error out flags... It's just a holy mess.

Anyways, as others have said it, it's not just the language. It's the libraries as well. Modern languages come with "batteries included", but these usually cover the needs for business applications, not games (or at least not all of those needs). Also there is the fact that the means of communication between different language APIs is still C, which is directly usable from C++ without any conversion tools or introspection voodo magic.

[Dmytry]

What i believe is the case is that in practice the differences between high level programming languages are so tiny as not to warrant use of other language for any reasons beyond "that's what I know"; the C++ has libraries written in it. The few issues in C++ that other programming languages solve, are very minor comparatively to the rest of the complexities in the big software. Ultimately, the issues like 'managing the memory' or 'multi threaded execution', etc. are very difficult for beginners and are nontrivial in small projects, but are trivially tiny part of the job in a big project.

Let me ask you something; how much time have you spent working with something like C#? And I don't mean "made a small program" I mean 'developed a sizable and complex system with it'?

Let's not resort to methods prone to massive placebo effect. The C# has numerous advantages over C++, and I do expect some increase in productivity, albeit much less significant than people tend to state, and actually, less than I am likely to believe - I do hate doing reflection in C++, for instance, and while it is not a significant burden, it is quite a big annoyance. Likewise not having to use smartpointers = less keyboard use, etc etc. If you let people remove some insignificant but noticeable weights attached to their legs the walking is going to feel a lot easier (for relatively short time) even if speed and endurance changed by only a couple percent.

I would say, C# is more ergonomic, in the sense of being less annoying, to much larger extent than it is 'better' by other metrics. edit: Basically, i would say that the parts which C# improves, are not a very significant burden in the sense of percentile of the difficulty; they are, however, very annoying sides of C++ and itch in the sense that you can very clearly see that some of your work has to be done only because language is being stupid.

Edited by Dmytry, 27 May 2012 - 09:00 PM.

[dilyan_rusev]

Actually, if you are using the Microsoft tools for development, .NET is supported much better. Up until very recently (vs10), C++ was largely ignored. It suffered from horrendous code completion, on/off navigation, etc. In .NET you've got even refactoring capabilities built-in.

The advantage of using C#/.NET is primarily coherence and the fact that you have a lot of functionality at your fingertips. I don't really think the language itself matters that much. They are almost the same, anyway. Also, another benefit of using .NET over native is that you get far superior tooling support. There are a lot more plugins to choose from, there are even some free ones, there is the invaluable Reflector (and now ILSpy), and the vanilla IDE is also a lot better. You've got ms-build, which is awesome for automation. But you can use nant instead, which is also awesome.

Another problem with C++ and performance (as in coding) would be legacy. Take a look at Google's coding conventions document. They are banning exceptions because the old code isn't built with exception-safety in mind. There is also the problem with Unicode: some use utf-8 (e.g. all non-java Linux and open-source stuff), others use utf-16 (Windows). There is ICU, of course, but I haven't met a library that uses it. And not to forget, there is the vastness of C libraries you might need, which you might need to wrap in order to use efficiently in your code base.

I think arguing about languages bringing productivity is not very fair. When somebody says C#/Java/Python, they usually mean the associated platform, not just the language. And it's the platform design and what's included, that matters. Developers will always find work-arounds for weak spots in the language. With time, you get to employ those work-arounds automatically, and they stop mattering to your productivity. At least that's my experience.

[ChaoSXDemon]

it has a little thing called "pointer"

So does every language in existence.

Uhh... no?

Uhh... yes? lol you just can't directly manipulate them in other languages... but they ALL USE POINTERS

[Reflexus]

I hope someone understands this:
http://www.jelovic.c...ava_is_slow.htm

Personally, (although I am most experienced with C++) I don't like C++ much. I agree strongly with dilyan_rusev. I don't think C, either, is all that shiny enough for the C++ designers to completely ignore people's problems with it, just so they can continue to be fanatic about C's legacy. I would say C++'s contributions aren't much either. There's a chance that if you limit yourself to utilizing C++'s capabilities, you can complete your project(s) much sooner. C++'s meta-language just sucks; I disagree that it improves any of the programmer's productivity. I tried "D", but I honestly didn't try very hard, because it makes some big mistakes that Java has also made.

[ChaoSXDemon]

Edited by ChaoSXDemon, 02 June 2012 - 02:20 AM.

[Olof Hedman]

it has a little thing called "pointer"

So does every language in existence.

Uhh... no?

Uhh... yes? lol you just can't directly manipulate them in other languages... but they ALL USE POINTERS

Of course every language need to handle memory adresses, since it has to run on a computer...
But the whole point of the pointer concept is that you can manipulate them directly.
If you can't, I don't agree that you should call them "pointers", then you usually call them "references".

[Zlodo]

C++'s meta-language just sucks; I disagree that it improves any of the programmer's productivity.

C++ template programming have a somewhat steep learning curve, but when you start being productive with it it is very good. It allows to rather quickly build powerful abstractions that have no runtime cost compared to a more classical (and time consuming) implementation. So yes, it does improve programmer productivity significantly.

C++11 have also improved template programming significantly when it comes to ease of use and readability.

[Ameise]

I hope someone understands this:
http://www.jelovic.c...ava_is_slow.htm

Personally, (although I am most experienced with C++) I don't like C++ much. I agree strongly with dilyan_rusev. I don't think C, either, is all that shiny enough for the C++ designers to completely ignore people's problems with it, just so they can continue to be fanatic about C's legacy. I would say C++'s contributions aren't much either. There's a chance that if you limit yourself to utilizing C++'s capabilities, you can complete your project(s) much sooner. C++'s meta-language just sucks; I disagree that it improves any of the programmer's productivity. I tried "D", but I honestly didn't try very hard, because it makes some big mistakes that Java has also made.

That is a nice article and frankly, it's got a point. However, I would like to point out that who ever wrote this is still thinking in an older mind set. Garbage Collection (GC) was a hot topic back in its birth dates just like how multi-core programming and languages that supports multi-thread optimally is a hot topic today. People back then wasn't sure if GC can be implemented on software or it needs hardware acceleration. Eventually, software was all that it needs. The point of bring this is the word "NEED". If you know your software NEEDS that 0.1s of optimization by using cache, then use C/C++ and do those crazy things! So why don't we NEED that optimization today?

The article mentioned that Java uses more memory. Is that a problem? NO...who isn't on a 64-bit machine that has more than 4096MB of RAM? Maybe people who DON'T CARE for that speed and some who just can't afford that cheap memory would still use an older system with less RAM. With that much RAM, we can AFFORD Java's heavier memory usage. Additionally, SSD are becoming more and more popular and page swapping on those isn't that bad. With that in mind, we should be focused on other things such as "Design Patterns", "Production Flow", "Prototyping" etc.

Unless you are writing some low level CORE library, honestly, WHO CARES?

CXD

Actually, Java using more memory can very much be a problem depending on what you're doing. Mobile devices (Android's Dalvik comes to mind) or large industry systems may see this. I have a friend who works for one of the large database providers, and with so many virtual instances running, their Java implementation constantly drives down the available system memory. Even in normal game development, Java tends to simply eat up memory, and depending on what you're doing, memory might be in short supply. I do a lot of procedural work, and end up using a lot of memory. I've hit the 4 GiB limit in the past with C++; Java would have been worse.

Your point about caching seems... well, wrong. Most VM/JIT implementations tend to be relatively cache unfriendly, and that can and will significantly hamper performance. Java isn't appropriate for many games because of its system-agnostic nature - the programmer can and often will write better abstraction code than a JIT will generate.

ALSO, is there a REASON that you SEEM to enjoy PLACING EMPHASIS on things USING caps so OFTEN?

Uhh... yes? lol you just can't directly manipulate them in other languages... but they ALL USE POINTERS

Java doesn't have pointers, it has handles. They don't support manipulation, and do not necessarily point to a memory address. They point to an arbitrary object. This is why Java doesn't call them pointers - because they don't behave exactly as such. Java is still pass-by-value (just like C), but they mask away much of the functionality. Not all languages even have these pseudo-pointers - some only have concepts equivalent to C++ references, which work via pass-by-reference.

Edited by Ameise, 01 June 2012 - 12:02 PM.

[metsfan]

My guess is ubiquity. It's been around a while, there are thousands of libraries written for it, there's a lot of programmers that know it, it's taught in schools, it's a very refined language that has been optimized by 2 generations of computer programmers, ect. It's not the only language that CAN be used to write games, hell you can write a game in any language that can draw to the screen, but it certainly has proven the test of time in terms of performance, adaptability, and compatibility, unlike a lot of other languages that have been cooked up since 1984 and now.

[GameOne]

C++ is the most attractive language when measured in power, flexibility and speed. As power, flexibility and speed increase, the detracting elements like manual memory management, dealing with header files and in general writing more code than in other languages become lesser.

Company A develops software using C++/CLI. They have a managed Windows Forms front end on top of native C++ class libraries. They tap into the benefits of .NET on the managed side and vintage C++ libraries like VTK and ACIS on the native side all in one solution. The common thread is C++.
What other language can do this?

[ChaoSXDemon]

I hope someone understands this:
http://www.jelovic.c...ava_is_slow.htm

Personally, (although I am most experienced with C++) I don't like C++ much. I agree strongly with dilyan_rusev. I don't think C, either, is all that shiny enough for the C++ designers to completely ignore people's problems with it, just so they can continue to be fanatic about C's legacy. I would say C++'s contributions aren't much either. There's a chance that if you limit yourself to utilizing C++'s capabilities, you can complete your project(s) much sooner. C++'s meta-language just sucks; I disagree that it improves any of the programmer's productivity. I tried "D", but I honestly didn't try very hard, because it makes some big mistakes that Java has also made.

That is a nice article and frankly, it's got a point. However, I would like to point out that who ever wrote this is still thinking in an older mind set. Garbage Collection (GC) was a hot topic back in its birth dates just like how multi-core programming and languages that supports multi-thread optimally is a hot topic today. People back then wasn't sure if GC can be implemented on software or it needs hardware acceleration. Eventually, software was all that it needs. The point of bring this is the word "NEED". If you know your software NEEDS that 0.1s of optimization by using cache, then use C/C++ and do those crazy things! So why don't we NEED that optimization today?

The article mentioned that Java uses more memory. Is that a problem? NO...who isn't on a 64-bit machine that has more than 4096MB of RAM? Maybe people who DON'T CARE for that speed and some who just can't afford that cheap memory would still use an older system with less RAM. With that much RAM, we can AFFORD Java's heavier memory usage. Additionally, SSD are becoming more and more popular and page swapping on those isn't that bad. With that in mind, we should be focused on other things such as "Design Patterns", "Production Flow", "Prototyping" etc.

Unless you are writing some low level CORE library, honestly, WHO CARES?

CXD

Actually, Java using more memory can very much be a problem depending on what you're doing. Mobile devices (Android's Dalvik comes to mind) or large industry systems may see this. I have a friend who works for one of the large database providers, and with so many virtual instances running, their Java implementation constantly drives down the available system memory. Even in normal game development, Java tends to simply eat up memory, and depending on what you're doing, memory might be in short supply. I do a lot of procedural work, and end up using a lot of memory. I've hit the 4 GiB limit in the past with C++; Java would have been worse.

Your point about caching seems... well, wrong. Most VM/JIT implementations tend to be relatively cache unfriendly, and that can and will significantly hamper performance. Java isn't appropriate for many games because of its system-agnostic nature - the programmer can and often will write better abstraction code than a JIT will generate.

ALSO, is there a REASON that you SEEM to enjoy PLACING EMPHASIS on things USING caps so OFTEN?

Uhh... yes? lol you just can't directly manipulate them in other languages... but they ALL USE POINTERS

Java doesn't have pointers, it has handles. They don't support manipulation, and do not necessarily point to a memory address. They point to an arbitrary object. This is why Java doesn't call them pointers - because they don't behave exactly as such. Java is still pass-by-value (just like C), but they mask away much of the functionality. Not all languages even have these pseudo-pointers - some only have concepts equivalent to C++ references, which work via pass-by-reference.

Yeah for mobile device that's probably true And I didn't know that about Java pointers so thanks for the info

CXD

[6510]

Actually, Java using more memory can very much be a problem depending on what you're doing. Mobile devices (Android's Dalvik comes to mind) or large industry systems may see this. I have a friend who works for one of the large database providers, and with so many virtual instances running, their Java implementation constantly drives down the available system memory. Even in normal game development, Java tends to simply eat up memory, and depending on what you're doing, memory might be in short supply. I do a lot of procedural work, and end up using a lot of memory. I've hit the 4 GiB limit in the past with C++; Java would have been worse.

Java does not tend to eat up memory.
Excessive memory usage has nothing to do with Java itself, it all depends on your very own coding style and that of used libraries.
Please do not feed age-old myths.
True is, that automated garbage collection can lead to mindless programming habits, but that usually has bad consequences in each and every language and environment.

[ChaoSXDemon]

Actually, Java using more memory can very much be a problem depending on what you're doing. Mobile devices (Android's Dalvik comes to mind) or large industry systems may see this. I have a friend who works for one of the large database providers, and with so many virtual instances running, their Java implementation constantly drives down the available system memory. Even in normal game development, Java tends to simply eat up memory, and depending on what you're doing, memory might be in short supply. I do a lot of procedural work, and end up using a lot of memory. I've hit the 4 GiB limit in the past with C++; Java would have been worse.

Java does not tend to eat up memory.
Excessive memory usage has nothing to do with Java itself, it all depends on your very own coding style and that of used libraries.
Please do not feed age-old myths.
True is, that automated garbage collection can lead to mindless programming habits, but that usually has bad consequences in each and every language and environment.

Thank you

[Ameise]

Actually, Java using more memory can very much be a problem depending on what you're doing. Mobile devices (Android's Dalvik comes to mind) or large industry systems may see this. I have a friend who works for one of the large database providers, and with so many virtual instances running, their Java implementation constantly drives down the available system memory. Even in normal game development, Java tends to simply eat up memory, and depending on what you're doing, memory might be in short supply. I do a lot of procedural work, and end up using a lot of memory. I've hit the 4 GiB limit in the past with C++; Java would have been worse.

Java does not tend to eat up memory.
Excessive memory usage has nothing to do with Java itself, it all depends on your very own coding style and that of used libraries.
Please do not feed age-old myths.
True is, that automated garbage collection can lead to mindless programming habits, but that usually has bad consequences in each and every language and environment.

You can tell my friend who works on database servers where the client interface is written in Java that. Or any Android mobile developer. Java eats up memory because objects aren't nearly as simple as C++ objects. No matter what a Java program will use more memory; it is impossible for it to use less. Even if it somehow generates perfect code for objects using JIT (which it won't) it still needs to maintain the JITs state in memory, as well as JVM state.

[6510]

You can tell my friend who works on database servers where the client interface is written in Java that.

Oh yes, loading the database into memory and blaming Java for being slow...

...Or any Android mobile developer.

FYI: You don't run Java on Android.

[ApochPiQ]

Alright, folks.

If we can't have a civil discussion without resorting to "yuh huh!" and "nuh uh!" all over the place, we're going to talk about something else.

[Ameise]

You can tell my friend who works on database servers where the client interface is written in Java that.

Oh yes, loading the database into memory and blaming Java for being slow...

I never said it was slow; I said it used up a large amount of memory. When your server(s) are handling tens of thousands of clients, the overhead of Java starts to become rather large, to the point that prototype C++ implementations use a substantial amount less. Java will use more memory no matter what, due to the need to store metadata for practically everything.

...Or any Android mobile developer.

FYI: You don't run Java on Android.

No, you run Dalvik bytecode (as I've said many times in the mobile forum). However, Dalvik is bound by the same constraints as the JVM in that to perform the same tasks (handling Java behavior, JIT) it still requires a substantial amount of overhead (in the form of metadata and a background running JIT).

Alright, folks.

If we can't have a civil discussion without resorting to "yuh huh!" and "nuh uh!" all over the place, we're going to talk about something else.

It was civil at one point. I'm trying to give experiences from my professional career; if he wants actual data, he needs only ask for it, instead of insisting that I'm wrong without any evidence of his own to the contrary. Also, his rather openly hostile attitude isn't helping.

Edited by Ameise, 04 June 2012 - 11:37 AM.

[Washu]

I'm going to close this thread, as its breaking down into a language war. I'm going to close with a quote from the one person who actually gave the reason for C++ being the industry 'standard language' as far as AAA games go.

Because it works on all the platforms a game studio needs to target. Specifically: Xbox 360, PS3, and sometimes PC.

Its not a matter of a "want" to use C++, but a matter of "what is required to operate on this platform?"

That being said, indie developers can use XNA to target the Xbox 360 platform, with limitations of course.