No.

First pass at the code tends to take time according to the number of function points. A line of perl code that I fully understand before I write it takes the same amount of time to think about as the 30 to 40 lines of assembler code it is equivalent to, with which I'm equally familiar. Typing the assembler code takes a bit longer, but they're pretty short lines and keyboard-memory takes over, so back when I was writing the assembler it would probably take me only 5 times as long to write the 30-40 lines of code as it does now to write 1 line of perl code.

Other features can also have a massive effect - when I started writing that assembler application, the assembler itself was hardwired to print out a full listing and concordance, and for the application I was dealing with that took about 7 hours. Since at that point we were just starting to get hold of hard disks, modifying the assembler to spool the listing to disk reduced the turnaround to around 5 minutes, which had a massive effect on how you could go about writing and debugging programs.

Similarly, how long it takes to find and fix a bug is in my experience much less dependent on LOC or language, and much more on the problem domain and the tools and techniques available - only the passage of time allows me to look back without shuddering at a stack corruption bug I once had in a keyboard interrupt handler, which took over a month of full time work to resolve.

Hugo