# Lines of code language comparisons

This topic is 1231 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

## Recommended Posts

Edit:

After realizing that I'm rather horrible at explaining things textually, I'm going to eventually make a video that explains what I'm talking about. I'm also going to do all of the research myself and I'll be presenting my final estimate equation in that future video. Thanks for all replies, though. I appreciate you guys taking your time.

Moderators feel free to close/lock this thread.

So, there's already a fair understanding of how efficient a language is machine-wise, but what about the other way around? Have anyone ever tried to make estimate comparisons between languages in terms of how user-friendly they are and thus, how fast a given programmer will be able to produce a given result, compared to another?

A concrete example:

Java Joe is going to write Braid in Java.
Christopher C will write it in C. (omg "will write"? Get it? LOL)
Both have the exact same writing speed, and the only difference is the language that they're writing in and perhaps the estimated amount of writing errors. Whatever IDE they're using, its strengths and weaknesses is ignored for now (because it depends on what IDEs you're using).

Who completes Braid first?

Now, I don't expect anyone to answer that, because it's too specific and may not answer the bigger context. But what I really wanna know is if anyone has ever made some estimates across a long list of coding languages and how efficient each of them are on the human level. For now, let's start with the number of characters written to produce a game.

One reason behind this question is something I heard from John Blow in one of his videos, that he wrote Braid in roughly 90000 lines of code. But how many characters is there in a "line of code"? and how many lines of code would it be if some other language was used (I believe Braid was written in C or C++). Because if I can write Braid in, say, 60k lines of code in Java, then that means that I could add another 30k lines of additional content if 90k lines was the launch goal I wanted to reach.

Another reason for me asking is because I'm making a game in Java and I'm rather surprised at how few lines of code I'm writing to get certain things done, even though I'm creating an engine from scratch (using only the most basic built-in methods etc and no 3rd party APIs, at least for now).

So are anyone here able to point me in the right direction? Thanks.

##### Share on other sites

One reason behind this question is something I heard from John Blow in one of his videos, that he wrote Braid in roughly 90000 lines of code. But how many characters is there in a "line of code"? and how many lines of code would it be if some other language was used (I believe Braid was written in C or C++). Because if I can write Braid in, say, 60k lines of code in Java, then that means that I could add another 30k lines of additional content if 90k lines was the launch goal I wanted to reach.

Especially this :

then that means that I could add another 30k lines of additional content if

Dude you don't have ANY limit on how many lines you can write. Also you are not taking in account how much time you have to spent understanding/writing one line. Those measurements are dumb as hell and totally pointless. + you cant write Braid in java. it wont work on xbox(for example).

And one final thing (obviously my OWN opinion) : I really like Braid and i applaud J. Blow for his huge success, but i think that his ideas for that new programming language sucks.

##### Share on other sites

In AAA games performance is important, so C++/C will have to be the answer for low level stuff.

Big studios already have people working there who are experts in the language, and they have code from prior projects that has to be maintained, and can be reused.

There would have to be some very significant reason (besides making employees work long hours) for changing language.

People who are working from home in spare time have a very good reason to compare time that it takes to write a game based on language they choose.

For example I started with plain google android SDK, and spent a lot of time making a very poor engine for 3 games I did in it.

Then I moved to Corona engine ... it was way better than what I wrote.

Now I'm on Unity (I don't want to compare them, but my preference is with Unity at this point).

Game engines save you time, so if you're coding an engine, then you shouldn't really worry if it will take longer in Java or C, because you can just get a better engine now (unless you're expert in engines, then maybe you'll make a better more specialized engine).

In general, the more high-level code you have, the less time you'll spend coding. For example it's a lot easier to make a list in C#, than in C, just because there's no standard structure for list in C (yes, there's in C++, but not in C I believe).  Also if you don't have to worry about memory management, it means you will never spend time debugging a bug related to it.

I'm using C# in Unity, and very happy with it. Compared to how long things took me in Java in Android SDK, there's a huge difference. I don't think the difference is in C# vs Java, but rather my own engine vs. Unity (most time in Unity is spent looking up which function is appropriate, but they work very well once I find the one I need).

##### Share on other sites

Out of curiosity checked the number of lines in the source code of Sol, and um... 35252 lines right now. And it's not going to get much bigger at this point (where it's literally just getting tweaks). That's taking into account many of those lines are blank or comments, and taking into account that this includes the game and the engine (since it's custom) and the level editor (since it's integrated). I guess my code is small. The libraries it uses are a lot larger though =P

Then again the easiest algorithms to maintain are simple ones, and those tend to lend themselves to take up less lines of code ;) (and I'm a lazy bastard so of course I go for the lazy approach wherever I can afford it)

##### Share on other sites
There have been studies correlating LOC to bug count; TLDR is that fewer lines usually means fewer bugs. This does hit diminishing returns pretty fast, though, as you quickly reach levels of obfuscation (cough, APL) that actually make it harder to code rather than more efficient from a human standpoint.

Personally, I don't think there's anything interesting to know about languages and productivity. I just don't see any correlation. I know programmers who can churn out C++ at lightning speed and with blinding degrees of correctness on the first try; I know other programmers who can plod over C++ for hours and produce a small buggy function. Switch to, say, Python, and those two measurements actually might invert - the C++ expert getting mired in the annoyances of dynamic typing, and the slower C++ coder breezing along precisely because he can take advantage of dynamic typing.

The important factor in productivity is virtually never language. It's almost always down to the people involved. At a team level, certain team dynamics are more effective than others... for some teams. Bottom line is that there is no one size to fit all.

If you're looking to lead a team, know your people first and foremost. That is the only thing you can do that will lead towards success in the long run. It won't avoid minor failures, or even occasional massive failures, but if you don't know your people, you will get nothing but failure.

If you're curious for yourself, well, that's a different matter. Try a lot of languages and learn what works best for you. Don't get complacent, though; try bending your mind to new paradigms or thought patterns when you get a chance, because that's important for staying relevant and sharp. Just remember that the only person you can meaningfully compare yourself with is yourself.

##### Share on other sites

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.

you cant write Braid in java.

Braid is a game like any other. I can assure you that you can write it in java. But that wasn't the point of my topic.

##### Share on other sites

you cant write Braid in java.

Braid is a game like any other. I can assure you that you can write it in java. But that wasn't the point of my topic.

You're taking my word out of topic.

You've missed :

it wont work on xbox
Edited by imoogiBG

##### Share on other sites

Anyways, I appreciate the various feedback. For my own plans, I guess this stuff isn't too important after all. But it would've been nice to see some graphs, especially with regards to scripting languages or similar that are more light-weight, compared to the real heavy-weighters. I mean, if I could spend 1 year getting the same result as spending 2 years with another language, that's not negligible.

I'm doing ok with Java though, and for the bigger projects down the line I'm looking into C++.

##### Share on other sites

You've missed :

it wont work on xbox

Then pick any other two languages that work for XBOX and any other game that is possible to make for both XBOX and PC.

My example was incidental.

##### Share on other sites
Keep in mind that modern C++ and the C++ most game development books and articles are written in are quite different. The number of lines of code needed to do simple things is much lower and general programmer productivity is much higher when you fully embrace modern C++ idioms.

Sadly, even on this site we still have new featured articles showing up that are written with C++98 (and not even necessarily _good_ C++98). Edited by SeanMiddleditch

##### Share on other sites

I'd say it has more to do with how you choose to go along with your project. Libraries used matter.

Not all languages are popular for developing games (which doesn't means that some languages are inherently better for games than others!), thus with such languages its more likely that you'll find the right library that will solve your problems with certain game specific system (whether that is physics, rendering, sound, AI, resource management, networking, etc).

If you grabbed C/C++, yeah, you could argue that writing resource management code won't be that simple, and maybe you'll trip over some catch here and there, but you'd be hard pressed not to find good game development libraries or entire engines for them, that can cut down the development time a lot.

(NOTE: I'd still wouldn't use it, but for people that don't mind it, C/C++ popularity as game making languages is a big plus).

Edited by TheChubu

##### Share on other sites

There have been studies correlating LOC to bug count; TLDR is that fewer lines usually means fewer bugs. This does hit diminishing returns pretty fast, though, as you quickly reach levels of obfuscation (cough, APL) that actually make it harder to code rather than more efficient from a human standpoint.

I imagine the real reason for this is actually fewer operations, not fewer lines (it's just that the latter tends to be a side-effect of the former). It's definitely harder to screw up with less operations, at least until you start skipping stuff you should be doing =P

##### Share on other sites

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.

##### Share on other sites

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.

Edited by DiegoSLTS

##### Share on other sites

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.

##### Share on other sites

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.

##### Share on other sites

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?

There's many languages that use less lines of code (or characters) than your average bit of C code... but they also possibly require more thought per line...

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?

Yes, different languages will be more/less productive in different situations, but simply comparing LOC counts misses all the important nuance of a true comparison.

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.

At my last console development job, we used both Lua and C++.

Lua was used because for high level gameplay code, it seems to be more productive -- i.e. less careful thought is required (and yes: less lines of code) to implement a task.

However, this isn't always true; For some more complex systems, it can actually be more productive (i.e. you get the task done faster) when using C++...

Then there's parts of the game where Lua just isn't a valid choice, so C++ would win by default...

Were you able to isolate what those complex systems were specifically, in which C++ was more productive? I've heard about how Lua and C++ is being combined in other games and it sounds like a good example of what I'm looking for. So, using the Lua/C++ combo as a template, it would be nice if there existed some larger documentation about what is advisable to write in Lua compared to C++. There's bound to be some ambiguity and personal taste in that, but I can't imagine there not being at least some universalities.

Also interestingly, when refactoring code late in the project, it was much easier to refactor the C++ systems due to the strong typing and the fact that C++ IDE's are very smart/useful. Refactoring the Lua code was extremely time consuming, and a lot of bugs were accidentally introduced in the processes, which wasted more time QA'ing, reproducing and fixing!

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

##### Share on other sites

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.

I'm not sure if you read the rest of my post, and not sure if you understood what I meant.

Just to be clear, I'll repeat what I quoted:

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.

What I read there is, in other words, "Game developers usually set limits on the number of lines of code they'll write to make sure they finish the development in a time frame that makes sense". Am I right? That's what you meant? Because that's the only thing I can see there.

That's the only point I was talking about, no one sets a limit for lines of code in real situations, never. I know you wheren't talking about competitions, I just wanted to point out that a limit of LOC is so arbitrary that only work as a challenge, a puzzle, but no one cares in a buisness because it doesn't mean anything.

If you really think that you can isolate LOC and get scientific results you're wasting your time. I'm not trying to be rude, but really, LOC might be the less important thing in the whole process, by far. Even worse, at least if you where looking at all the lines of code (even the ones the developer deleted) you might have a value that slightly relates to coding efficiency, but it looks like you're talking about the final count of LOC, only the ones that end up in the release version of the code.

I obviously not saying that AAA games are simple games, I know companies should choose a language (and every other tool!) that's better for them. You know they already do that, right? They don't go with C++ "just because", they use a lot of factors and experience to make the choices, and I'm pretty sure that they don't consider LOC.

Also, you talked about refactoring and optimization and somehow related them to LOC too. I know you're trying to set up an hipotetic impossible situation where LOC is the only factor, but you're taking it too far. Refactoring rarelly has anything to do with the language you choose, and some times refactoring could even mean writing MORE lines of code.

Anyway, since you're approaching this from a scientific point of view I'd like too see what are the next subjects before reaching the conclusion. If I understood you correctly, you're trying to cut down costs of production? or time? or both? You'll choosing only the language or the other tools? Because tools will affect the development time a lot more than the language itself. You'll consider human and legal factors? Experience, groups, hierarchy, all those things affect the development time possible even more than any programming choice made (a bad managment could lead to a project being canceled after 9 years of development).

EDIT: I read again some of your posts, I see you're not trying to reach a bigger conclusion, only to know if there are some studies comparing real-sized problems solved using equally skilled developers in different languages. I'm sure that doesn't exists, you can't even chose 2 people and say "this to developers are equally skilled", and even if you could, you can't say "they'll make the most optimium code so that lines of code at the end are only affected by the language they know". I consider myself a pretty average developer but I think I could write Braid using Unity in less than 10k C# lines of code, does it count?

Edited by DiegoSLTS

##### Share on other sites

what I really wanna know is if anyone has ever made some estimates across a long list of coding languages and how efficient each of them are on the human level.

any software engineer who wants to be productive will always consider write-ability when choosing a language. but other considerations such as run-time performance tend to be more important in games.

i use a macro processor / code generator to increase productivity. for me - typing is the #1 bottleneck in core dumps of largely ready to rock code from my brain to the computer. my brain thinks in code at warp speed, but my fingers are sub-light only.

the macro processor i use is designed to reduce keystrokes required to enter c++ code.

##### Share on other sites

"then that means that I could add another 30k lines of additional content"

Except that is discounting the further design time which those additional lines would represent (your going to code WHAT now .. beyond the original specs ?? ).

You can find that the other project elements can add up to substantial 'time' and effort - example is looking into the libraries you will use (if thats in the project and its not all from scratch) to make sure they do what you need them to do (often writing test code to prove it sufficiently before proceding).

SO the lines of code or speed of producing them is just a starting point

Different languages also have certain advantages (or easier doing of certain ways of doing things)  -- example in C (or C++ I write like it was C)  I can write the entire program without a single bit of dynamic allocation which as you might expect eliminates memory leak problems a great deal and if you have to spend additional time chasing down memory leak problems or garbage collection spasms in the program THAT  is also an important issue to the project being successful (meeting deadlines/quality expectations).

As someone else said  where a few more lines that make the program logic clear/obvious rather than some 'crofty' code that someone else cant immediately decypher (Including you a year later).

Comments also arent usually included in 'lines of code' metrics but can be quite important  to creating a 'proper' project  in its lifecycle.

Edited by wodinoneeye

##### Share on other sites

Just to be clear *snip*

And judging from all the other replies by people like Hodgman, frob and the rest, you seem to be the only one seeing it like that. Anyways, I give up. If you're not seeing what I'm asking about, then we're simply speaking two different languages and there's nothing I can say to you that will change that. So sorry if my thread doesn't make sense to you, but I can assure you that I'm not trying to do any of the things that you think I'm trying to do. Believe what you wish.

##### Share on other sites

Well, here's an empirical fun fact I basically get to observe every day: a bad programmer solves trivial problems in less time and with more lines of code than a good programmer. Why? Because rather than putting some thought into it, he simply brute forces it. Because he doesn't bother with refactoring his result for better readability and maintainability. Because rather than refactoring, he just copy/pastes existing blocks of code all over the place.

So by producing way more code in less time, he's clearly more productive, right? If your answer is 'yes', you are probably a project manager...