Lines of Coding Per Day
Have I ever been happy with shipped code that - after taking into account debugging, polish, refactoring, and documentation - was produced at that speed? Hell no.
Considering what the others said, I felt that this quote sums it up quite well:
"Measuring programming progress by lines of code is like measuring aircraft building progress by weight."
-Bill Gates (Or so they say)
The number of lines of code and the efficiency of the code are quite often different.
Edit: Dang, Someone already posted that quote! Well this will reinforce it's importance ;)
It doesn't matter if you spend days to just change a single character in a single file, as long as the bug gets fixed.
In fact if you find yourself writing tons of code in a day then it's probably a bad sign, possibly in crunch mode.
Spend more time thinking and you'll end up writing less code that does the same job better.
I'm curious how many of the people who are suggesting >50 lines per day (averaged) have worked in a professional setting... And what kind of code they're writing...
I have, but my professional settings have perhaps been atypical. 2 greenfield projects, 3 projects involving machete refactoring that may have well been greenfield, and 1 job that largely involved writing disposible SQL queries. And I (and the host languages) tend to be verbose.
SQL is a domain-specific language used for database queries, not a general-purpose language, AFAIK.
Just as HTML (for example) is a domain-specific language for web-page markup.
Are there languages which make everyone who uses them write more lines per day compared to other languages? Are scripting languages this way?
Yes, scripting languages and other interpreted languages allow you to code faster, because there are no compile times.
Python is like that. This is why scripting languages are often used even in games written with compiled languages.
But lines of code is not the goal of scripting languages - the goal is to speed up the "code -> compile -> test -> repeat" by removing the "compile" part which causes a periodic jarring delay while in the middle of working. Scripting languages often allow you to then compile the script afterward to either bytecode or assembly, for faster execution (Resulting in a "code -> test -> repeat until satisfied -> compile" process).
But before worrying about faster development, it's far more important to learn how to develop quality code. If you focus too much on coding quickly instead of coding skillfully, you fall into a number of very bad programming practices, like making your projects unmaintable and hard to expand later, and fixing problems by monkeying with it 'until it works' instead of understanding the cause of the problem.
In a world increasingly immersed in software, the last thing we need is more programmers who just want to slap some code together without understanding the consequences, or who just care about 'getting the job done' leaving the mess for the next person who comes along, instead of doing the job right the first time.
Also, as software projects continue to increase in scale, slapping code together rapidly will be increasingly recognized as undesirable, and the market will shift (and has already started to, from what little I understand) to favor quality programmers. Good programmers can always "turn off" their skills and quickly write code to get something done (as much as they shudder at the thought). Bad programmers can't "turn on" skill when it's required, and you'd be setting yourself up for defeat in the marketplace, in my possibly-flawed prognostications*.
*Sweet! I finally managed to work that word into a sentence. *checks it off the list*. Next up: Onomatopoeia
But lines of code is not the goal of scripting languages - the goal is to speed up the "code -> compile -> test -> repeat" by removing the "compile" part which causes a periodic jarring delay while in the middle of working. Scripting languages often allow you to then compile the script afterward to either bytecode or assembly, for faster execution (Resulting in a "code -> test -> repeat until satisfied -> compile" process).
But before worrying about faster development, it's far more important to learn how to develop quality code.
How good is C# for the post-compile process? What about Python and Lua?
causes a periodic jarring delay while in the middle of working.
Is the delay in workflow, execution, or both?
I'm not sure about C#'s scripting capabilities - C# is normally a compiled language, but it has some kind of ability to use itself as a scripting language - someone else will have to answer with more details. Python can compile to assembly IIRC, and Lua can compile to a very fast byte-code.How good is C# for the post-compile process? What about Python and Lua?But lines of code is not the goal of scripting languages - the goal is to speed up the "code -> compile -> test -> repeat" by removing the "compile" part which causes a periodic jarring delay while in the middle of working. Scripting languages often allow you to then compile the script afterward to either bytecode or assembly, for faster execution (Resulting in a "code -> test -> repeat until satisfied -> compile" process).
Is the delay in workflow, execution, or both?causes a periodic jarring delay while in the middle of working.
Workflow, not execution. Mind focused, you're working hard, now you need to compile so you hit 'compile' and twiddle your thumbs for two minutes or more while you can't do much work. Personally, it breaks up the mental 'groove' I get into.