Had to share this as an example of what a determined coder can fit into a small space: this entire video is from a 4k executable. That's right, 4 kilobytes. 
 

Had to share this as an example of what a determined coder can fit into a small space: this entire video is from a 4k executable. That's right, 4 kilobytes. 
 

Damn forum, lol. 

There isn't much of a correlation between executable size and lines of code. First of all, what do you count as a line of code? Does that include comments? A well-written program will be heavily commented, and some of those comments will have taken as long to write as the code they describe. Do you include third-party components? For many applications, 90-95% of the program will be external libraries written by somebody else. As noted above, different programming languages will require more or fewer lines of code to achieve the same end (a 1,000-line assembly routine might be functionally duplicated in a single line of VB code, for example).
 
Secondly, there isn't much direct correlation between lines of code and development time, which would be more important to you. It used to be that a good programmer could produce 10 lines of commented and debugged code per day. I know there are days when I don't achieve that. Other days, if the requirements are well-understood and don't cover new ground, I can churn out a couple thousand lines of tested code in a day. Also note that two programmers don't produce twice as much code as one. Application development doesn't always lend itself to parallel divisions of labor.
 
My main application that I sell for a living has been in development since 1993, with the first installation in 1996 (about as long as Pro Audio / SONAR). The executable is 12MB in size, about the same size as SONARPDR.exe. The source code consists of nearly 600 modules and well over a million lines of code (I haven't actually counted them in a while) that I actually wrote myself (as opposed to third-party modules). That works out to about 130 lines of code per day, and believe me those 20 years have included some very long days! And this is just the main application, not counting ancillary utilities.
 
I'd suggest adopting the highest-level programming language that serves the purpose. If that's Python, then go for it - although Python will run out of steam pretty quickly for complex applications. Divide the code into time-critical and non-time-critical sections. The non-time-critical parts can be written in a higher-level language to cut down on development time. Save your C++ and assembly time for those bits that must be highly efficient. Of course, if you're writing a VST plugin, that means 99% of it. 

bitflipper
A well-written program will be heavily commented, and some of those comments will have taken as long to write as the code they describe.

OK, can't resist jumping in here.  When I've taught programming, I always try to convey the notion that the best documentation is that which isn't there because it isn't needed in the first place.  You can get that with well thought out class, function and variable names.
 
Changing subjects to an aspect that hasn't been mentioned yet, the issue of amount of code needed for a given function can be much dependent on how well the coders/designers understand and apply object oriented software practice.  For my money, this is the most significant software advancement that's happened during my 45 year career as a software developer.  You can't tell from the outside whether a piece of software uses OO internally (other than it will probably have fewer bugs), but it can make a world of difference in how fast the software gets written and tested.  And when properly utilized, it can significantly cut down on source code length.

@DMBaer: Ha ha. We always joke that no documentation is needed. If you can read code, you can always know what it does, so what's the problem? Giggle. And the depth of understanding involved is usually huge from surface to seabed. Anyway, keeping documentation is PIA and it's almost always out of date. Look at Sonar's help file. LOL.
 
Sometimes I think it would be an improvement to make that helpfile updateable ... or at least where we could suggest improvements that they could accept or reject.
 

Probably around a gazillion (give or take a trillions).
 
Jim

sharke
Had to share this as an example of what a determined coder can fit into a small space: this entire video is from a 4k executable. That's right, 4 kilobytes. 
 

 
as someone who has worked on demos in the past 8 bit wise, YES the compressed code is 4k.. but you'll find the uncompressed code for it is far bigger. It is generating more code / tables etc at runtime , or by using the GPU for processing etc.  data structures and recursion algorithms do come into it to compress the code / gfx. pretty much like a coiled spring. Even with sound, some of the players they use for audio , the actual instruments that are generated aren't many bytes.
 
much like the game "elite" on 8 and 16 bits had a massive universe... all in 32k of mem.. it was all down to the formula's that would generate far more data on the fly. http://www.youtube.com/watch?v=Rapa3VfUWfs
 
16:45 minutes in
 
 
 
 

Fog

sharke
Had to share this as an example of what a determined coder can fit into a small space: this entire video is from a 4k executable. That's right, 4 kilobytes. 
 

 
as someone who has worked on demos in the past 8 bit wise, YES the compressed code is 4k.. but you'll find the uncompressed code for it is far bigger. It is generating more code / tables etc at runtime , or by using the GPU for processing etc.  data structures and recursion algorithms do come into it to compress the code / gfx. pretty much like a coiled spring. Even with sound, some of the players they use for audio , the actual instruments that are generated aren't many bytes.
 
much like the game "elite" on 8 and 16 bits had a massive universe... all in 32k of mem.. it was all down to the formula's that would generate far more data on the fly. http://www.youtube.com/watch?v=Rapa3VfUWfs
 
16:45 minutes in
 
 
 
 

 
Great vid. I must admit I didn't like Elite when it first came out, probably because the Commodore 64 version which I had was vastly inferior to the BBC version. But I played it again when the Amiga version of Elite II came out and I was hooked. Another 8-bit masterpiece in the same vein was Mercenary by Paul Woakes. A huge 3D wireframe world to explore with incredibly absorbing game play. That one lasted me all 6 weeks of a summer holiday. 
 
Britain was indeed a mecca of video game production. It's still a major player. A friend of mine from years back, whom I shared an apartment with at one point, landed a "dream job" as a game tester for Codemasters. He worked his way up and became one of their top game producers, working on some of the biggest first person shooters of the last few years. He left eventually and has now set up his own consultancy firm for video game producers. I really wish that I'd taken that road 25 years ago or so, because it looks like a lot of fun. 

dmbaer

bitflipper
A well-written program will be heavily commented, and some of those comments will have taken as long to write as the code they describe.

OK, can't resist jumping in here.  When I've taught programming, I always try to convey the notion that the best documentation is that which isn't there because it isn't needed in the first place.  You can get that with well thought out class, function and variable names.
 

Let's hear it for DoStuff(), Process(), and Calc()!

Changing subjects to an aspect that hasn't been mentioned yet, the issue of amount of code needed for a given function can be much dependent on how well the coders/designers understand and apply object oriented software practice.  For my money, this is the most significant software advancement that's happened during my 45 year career as a software developer.  You can't tell from the outside whether a piece of software uses OO internally (other than it will probably have fewer bugs), but it can make a world of difference in how fast the software gets written and tested.  And when properly utilized, it can significantly cut down on source code length.

That's of course the key - proper utilization of OO techniques.  Having an OO language is not going to help if the classes are tightly coupled, if you let your class hierarchy get out of control, etc.