fallenrogue.com

Huh ? Game preformence ? did you measure game performence of XNA (or and DirectX managed code / c# game) to normal C++ where you can really say it's an advantage on today's platforms ? or it this another fart out of the hat with no clue on what you are talking about ?

Well, lame, I haven't checked out the XNA... which is pretty new and since I'm not a game dev by trade, I'm not really looking into it. It is largely regarded by the current developer community that unmanged code runs faster than it's managed counterpart. If this is not the case with C# and XNA I'm sorry but I spoke with my current knowledge. If you have documentation stating otherwise please feel free to share.

Making a argument for C++ perf would be maybe in real-time market (real real-time, not games and anything else). In almost anything else if a language can save you tons on coding, and Q&A and what not (because of it's methods compared to previous ones, in which C++ and C and C# can be compared, but not ruby), and the outcome is that you lose 5% of performence, I think it's a valid choice, and would be stupid (and not economic) to persuite old ways / language.

Case being, if Microsoft release XNA for PC and XBOX 360 it means they belive that managed code performence lose isn't so critical compared to the benefits, so even if you lose some minor performernce (which is getting to be less of an issue this days as cpu aren't bottlenecks anyhow for gaming performence for a long time).

Also, you can check for the fun of it:
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=811866&SiteID=1
http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=795669&SiteID=1
Where people are happy about the manage code performence.

Lame, thanks for your follow up! I will certainly give it a try. Personally I love C# vs. C++ and if I could whip up a few PC games using it and XNA then I'd love to try!

Good deal; more along the lines of my own opinion.

Most of the time (as real-world developers) our code is either decided by the client or by necessity. It's a rare occasion that we get to whip something up from scratch in whatever language we like.

Your article was actually spot on. I've written piles of code (or 'developed a number of large systems from scratch') in C, C++, C# (well, only a little bit of C#), Java, Perl5, Ruby and for the past 6 months Javascript.

Productivity in a language depends a lot on your familiarity with it, the team's familiarity with it, the existing codebase and the problem domain you're tackling.

However, a programmer familiar with Ruby will solve an identical problem an order of magnitude faster than an equally skilled C#/Java programmer. The reason is simple - Ruby is dynamic and expressive.

You can do more and you can do it with less typing.

I've noticed this myself, but I've also noticed it with two interns I guided through Javascript projects. At first they thought Javascript was a 'toy' language (happens a lot, I'm afraid), but after teaching them the language they started happily flinging closures left and right (following the guidelines, naturally).

One went on to a C# project and the other to a Java project. And both of them came back and more or less told me "It's so frustrating, you have to type for hours to get anything done and on top of that it seems that most of the typing is for working around deficiencies in the language!"

Which is of course the case. The only people I hear disputing this are people who only know Java/C# (or C++, Delphi, etc).

In Ruby (or Javascript, or Haskell, or Scheme, etc) you can come up with an idea and often just implement it in a few lines.

In Java and friends, you first have to build some random SuperIdeaObjectClassFactoryGenerator monstrosity which eats up so much time you might have forgotten why you were building it in the first place.

I've worked on Java projects where testing was done with JUnit (of course), but where a 'live hammering' of the exposed API was not part of the project spec. It would take too much time, cost too much money, etc. I asked the project lead for one day and hammered out a Ruby client and a decent test suite. It found a couple of crippling bugs (DB related race conditions, mostly) that were pretty trivial to fix.

There is no way I could have pulled that off in Java. Or C#. Or Haskell, for that matter, but I'm not a Haskell programmer, so that doesn't mean anything.

This doesn't mean I advocate using Ruby everywhere, by the way. Just select the right language for the right situation. Hacking together a pile of perl code for a VB shop is just mean and stupid. It also reflects badly on your coding skills and shows that you are an incompetent, unprofessional moron. (Yeah, I've done a lot of 'cleanup projects').

C#, the best? I certainly like it more than Java, C++, or Visual Basic; and Haskell _is_ hard to start programming in. But I can think of no reason to prefer C# over OCaml, except for access to the .Net library. And if you want to use the .Net library, there is Nemerle, which already has all features of C# 3.0 and quite a few more. Or F#, for that matter, which is a straight port of OCaml to .Net.