[EMAIL PROTECTED] (Alex Martelli) writes: > Mike Meyer <[EMAIL PROTECTED]> wrote: >> > Every line = more labour for the developer = more cost and time. >> > Every line = more places for bugs to exist = more cost and time. >> There were studies done in the 70s that showed that programmers >> produced the same number of debugged lines of code a day no matter >> what language they used. So a language that lets you build the same >> program with fewer lines of code will let you build the program in >> less time. > Of course, these results only apply where the "complexity" (e.g., number > of operators, for example) in a single line of code is constant.
I'm not sure what you're trying to say here. The tests ranged over things from PL/I to assembler. Are you saying that those two languages have the same "complexity in a single line"? > for item in sequence: blaap(item) > > or > > for item in sequence: > blaap(item) > > are EXACTLY as easy (or hard) to write, maintain, and document -- it's > totally irrelevant that the number of lines of code has "doubled" in the > second (more standard) layout of the code!-) The studies didn't deal with maintenance. They only dealt with documentation in so far as code was commented. On the other hand, studies of reading comprehension have shown that people can read and comprehend faster if the line lengths fall within certain ranges. While it's a stretch to assume those studies apply to code, I'd personally be hesitant to assume they don't apply without some reseach. If they do apply, then your claims about the difficulty of maintaining and documenting being independent of the textual line lengths are wrong. And since writing code inevitable involves debugging it - and the studies specified debugged lines - then the line length could affect how hard the code is to write as well. <mike -- Mike Meyer <[EMAIL PROTECTED]> http://www.mired.org/home/mwm/ Independent WWW/Perforce/FreeBSD/Unix consultant, email for more information. -- http://mail.python.org/mailman/listinfo/python-list