I think you are also misunderstanding hoe the software development lifecycle works. You don't just bash out code from A to Z and everything you type makes it into the game. You have to refactor. You have to optimize. It may be that one language requires less lines of code to do a task but at the same time if there is a bug it could be very tricky to locate it. Or that one language has infinatly more options available. There is also the issue that there is literaly tons of good game programming resources available that are written in C or C++.

For me a productive day usually means that I remove lines of code from a project and not add them.

Dude you don't have ANY limit on how many lines you can write.

Game developers usually want to eventually release their games, and not stay in development forever. Writing 100k lines of code takes time.

I've never heard or read anyone saying "I'll write x number of lines at most, I need to finish my game this year" as a real requirement, only in some competitions and just for fun or curiosity ("Let's write Pong in as few lines as possible! You can do any weird and unreadble stuff you need!").

Also, if you end up with 100k lines of code, you probably wrote from 150k to 200k lines during the whole project, you'll never write anything in the exact way you need it so you end up throwing or modifiying whole pieces of code, and that's one of the main problems of using LOC to measure anything. Also, you won't spend time ONLY coding, your game needs art, texts, testing (not the test a developer does, a real stress test), etc, etc, etc. Maybe you've finished all the code, but the game is not finished because you need more levels.

Every language/API/Framework/Engine shows in some degree how fast it is to use it ("this is how you write a "hello world!" app with C, but with Z you just need this line!"), but it's always a very trivial and specific block of code, becuase that's the only way you can compare both.

I've never heard or read anyone saying "I'll write x number of lines at most, I need to finish my game this year" as a real requirement, only in some competitions and just for fun or curiosity ("Let's write Pong in as few lines as possible! You can do any weird and unreadble stuff you need!").

Oh boy...

I'm not talking about a competition, I'm talking about how one can make the game development industry more efficient in general, by getting a more extensive understanding of what it takes to do things with less time and effort - whether you write 100k lines of code or 5 billion, and whether you spend 1 year or 5 years. Braid was the example that I provided because I know some data about what it took to make it - about 2 years, 90k lines of code and someone like John Blow's level of efficiency. So now, as a small example exercise that illustrates my point, let's "write it again in a different language", or perhaps a combo of languages. Would there be some way to write Braid faster or, if someone want to write a similar game in the future, are there some languages to avoid because you're going to end up wasting time that you could've otherwise spent fleshing out the game? I don't expect a clear answer from anyone, I'm just wondering if there is one.

In science, you generally want to isolate all factors (to get their relevant effects confirmed or refuted) before you add them together for the big picture. So in order to see how relevant the number of codelines are, one obviously need to isolate that in a proper environment. My Braid example was such an environment.

The point is that you don't have an infinite amount of time at your disposal if you want to actually release a game in this century. The point is that different languages finish similar/identical projects in different amounts of time, depending on the syntax and also, as some mentioned in this thread, how one programmer is better at that specific language compared to the other (because that's the language he's been using for the last two decades).

Because it it's a big deal if you could substantially cut production costs by choosing the right language for the job. Perhaps not for Pong, but then again most professional game developers aren't writing Pong, are they. And I'm sure you're not implying that Destiny, Farcry 4 or Dying Light are Pong-clones.

You don't just bash out code from A to Z and everything you type makes it into the game. You have to refactor. You have to optimize.

Yes, and different languages have different syntaxes, different OO structuring and different amounts of built-in functions that you don't have to write from scratch. So it's logical to assume that the time you spend refactoring and optimizing varies from language to language, yes? And based on that information, the language you choose for yourself can mean the difference between less or more time spent producing the exact same functional result. Not to mention your own skill level with that given language. A faster language could be slower, if you're uncomfortable with it and thus write it much slower than usual.

Lines of code per hour is in no way a useful number.

I've never been constrained in my time to complete a task by my typing speed!

That may definitely be true, but time is still spent writing the code, and the less time you potentially spend writing that exact same functionality, the more time you got writing the rest of the program, right?

But is this universally true? Does [lines of code] * [thought per line] always equal the same, roughly speaking of course? Or are some languages superior to others when taking both of those factors into account?

I'm looking for the comparisons themselves across all relevant factors (of which LOC is just one). I'm seeing people compare languages all the time, but it's always that one or two factors that those people give personal value and not all relevant factors in unison, as a neutral, scientific study.

So the way I see it, identifying a given programmers common refactorings could be a way to tweak someone's choice of language for a given task. At least as a way to play around with his efficiency if he uses Lua instead of C++ or vice versa (whenever it actually makes sense, of course, and the "more time refactoring" isn't just negligible compared to other, more pressing concerns).