5 ms·

I wonder if another, equally valid, way of looking at the lines of code vs time is that if two programmers using different languages both complete the task in r

I wonder if another, equally valid, way of looking at the lines of code vs time is that if two programmers using different languages both complete the task in roughly the same amount of time, but one uses only half the total lines of code... that implies _not_ that that programmer is better, but that each of their lines of code took roughly twice as long to produce. One of the things I used to do when working in large teams was wander around and look to see if anyone was having trouble debugging. Sometimes you'd find someone who'd been stuck on a bug for several days. So what I'd do was I'd sit down with them, and start putting in all the 'fluff' like indenting their code, splitting lines with multiple variable declarations each onto their own line etc. Essentially putting in all the 'long cuts' that they'd taken 'short cuts' around in order to 'speed up' the programming. Often either they or I would see the problem immediately. These days of course there are tools that do the auto-formatting, but I still try to optimise for readability, simplicity and elegance in my code. Back to the lines of code as a metric issue (tm) in that scenario where it takes 2x as long to write a line in language X, and that line does twice as much, it is probably at least twice as complex as the 'more verbose' language... and I think this implies that it will be harder to debug and maintain later on. So arbitrarily complex languages are optimal for some internet 'toss off' (one off, toss away) competition, but not necessarily optimal for long term efforts. Some of these languages that allow you to redefine the language itself on the fly allow you to do 'cool stuff' (tm) but tend to attract people who think they are much cleverer than they actually are. I think it is a regional variation, but all the Ruby fans in my city scare me. The thought of what would happen if I'd spent days or weeks on a bug only to find out it was caused by someone else 'tweaking' one of the core classes and not bothering to tell anyone else... twitch

ay 16y ago
"scenario where it takes 2x as long to write a line in language X, and that line does twice as much, it is probably at least twice as complex as the 'more verbose' language... " I think this is debatable. After all - a function call compresses multiple lines into one as well.. And you want programmers to factor the repeated code into function calls. The "dynamic redefinition of the language" is the same thing except at a different level. The problem is not with the lines of code per se - it is whether the semantic compression is worth the learning curve, and the "surprise" factor. Think C++ templates, for example, with a "+" operator that would do something "non-intuitive". The "non-intuitiveness" may vary - and it is a fine art to not cross the line. FWIW, I've done the exercice in Lua, ~ 1 hour and 107 lines (and for some reason a different order of outputs, which I did not want to debug since I went for a nice dinner with a couple of beers earlier today) - https://gist.github.com/752460 https://gist.github.com/752460
kbd 16y ago
I question your assumption that if something is done in 1/2 the lines of code then each line of code is twice as complex. You're equivocating on "complex". Each line may be "more complex" in the sense "does more", but not necessarily more complex as in "harder to understand" (and therefore more prone to bugs). Code in a more productive (i.e. higher level) language is concise because it hides extra complexity you don't need to think about at the time, and is therefore simpler, not more complex (in the second sense).
- DrJosiah 16y ago
  A perfect example of this is setting up iteration in Python vs. C++. In Python: for obj in seq: ... In C++: std::base_class<template_type>::iterator obj; for (obj=seq.begin(); obj != seq.end(); seq++) {...} The reduction in lines for Python doesn't make it more complicated, it makes it cleaner and easier to express ideas.
- rmc 16y ago
  Code in a more productive (i.e. higher level) language is concise because it hides extra complexity you don't need to think about at the time, and is therefore simpler, not more complex (in the second sense). Another example of where this is true is automatic memory management. A line of Java code can do all the memory management that would take many lines in C. This is a mostly good thing. In this case, less lines = better.
RyanMcGreal 16y ago
> start putting in all the 'fluff' like indenting their code One of the many nice things about Python is that whitespace - specifically, indenting - is significant.
- samratjp 16y ago
  And that feature alone makes for readability in large projects :-)
- p_nathan 16y ago
  I've had multiple bugs based on whitespace being significant. A C-descended language which had braces around the block would not have had the bug at all. Another problem with it is that I can't just comment out, say, an if, and have the code under it run automatically. I have to go through and reformat the business, leading to potential bugs. This also plays into refactoring as well. Basically, I find the whitespace rule something that should have been left in the 60s with punch cards. I am not a fan of Python. I consider Common Lisp and Perl to be fundamentally less ambiguous languages.
  - RyanMcGreal 16y ago
    > I've had multiple bugs based on whitespace being significant. Interesting. In several years programming with Python, I've had exactly zero bugs based on whitespace being significant. > I can't just comment out, say, an if What I do is comment out the if statement and add another if statement under it, like so: #if condition: if 1 == 1: # FIXME temp code for testing do_something() I always grep my code for FIXMEs before pushing to production, and have my text editor configured to highlight FIXMEs and TODOs.
srean 16y ago
I am a scheme neophyte. In my personal experience it has been a very thought compressible language. By that, what I mean is this: if you give more thought to a program one tends to be able to say more and more but with less and less, and without making the code incomprehensible or complex. Interestingly, when I show my code to a scheme veteran, he would often re-write it to make it even shorter and clearer. So I have a long way to go. So line for line , yes it takes me more time to churn out scheme, but if I give the same amount of time to c++/java it doesnt compress as much. But, and here is the cool part, if it does, I can often trace it back to scheme way of thinking. This has happened a lot when programming with C++/STL.
rmc 16y ago
I still try to optimise for readability, simplicity and elegance in my code. That's a good goal. One advantage of Python is that indentation etc. are required. You can't take a 'short cut' and write messy code, cause your code won't run.
- sigzero 16y ago
  I am not arguing this but I think programming is in a sense "expressing oneself" and the "one way" and the "rigidity" of Python might turn some people off. Sometimes...you need to take that "short cut".
- ewjordan 16y ago
  One advantage of Python is that indentation etc. are required. This is such baloney. I've written hundreds of thousands of lines of code in Algol-esque languages, and just about every last line (by which I mean > 99.9%, with possibly exceptions once in a blue moon where I accidentally hit tab before I compile or something like that, which just gets cleaned up the next time I reformat anyways...) of that was properly indented. It's just too easy not to do, and I'd fire, almost immediately, anyone that was checking in code that wasn't indented properly. Really. Where are all these horrible developers that don't sanely indent their code? To hear the Python folks tell it, they're fucking up codebases all over the place with their carelessness, but I've never personally experienced any pain whatsoever over this. Certainly nothing that a simple CMD+i can fix... Hell, different newline types interacting badly with version control have caused me so much more trouble than indentation, and Python's not immune to that. Nor is it immune to people's editors globally forcing tabs to spaces or vice versa.

ay 16y ago

"scenario where it takes 2x as long to write a line in language X, and that line does twice as much, it is probably at least twice as complex as the 'more verbose' language... " I think this is debatable. After all - a function call compresses multiple lines into one as well.. And you want programmers to factor the repeated code into function calls. The "dynamic redefinition of the language" is the same thing except at a different level. The problem is not with the lines of code per se - it is whether the semantic compression is worth the learning curve, and the "surprise" factor. Think C++ templates, for example, with a "+" operator that would do something "non-intuitive". The "non-intuitiveness" may vary - and it is a fine art to not cross the line. FWIW, I've done the exercice in Lua, ~ 1 hour and 107 lines (and for some reason a different order of outputs, which I did not want to debug since I went for a nice dinner with a couple of beers earlier today) - https://gist.github.com/752460 https://gist.github.com/752460

kbd 16y ago

I question your assumption that if something is done in 1/2 the lines of code then each line of code is twice as complex. You're equivocating on "complex". Each line may be "more complex" in the sense "does more", but not necessarily more complex as in "harder to understand" (and therefore more prone to bugs). Code in a more productive (i.e. higher level) language is concise because it hides extra complexity you don't need to think about at the time, and is therefore simpler, not more complex (in the second sense).

DrJosiah 16y ago
A perfect example of this is setting up iteration in Python vs. C++. In Python: for obj in seq: ... In C++: std::base_class<template_type>::iterator obj; for (obj=seq.begin(); obj != seq.end(); seq++) {...} The reduction in lines for Python doesn't make it more complicated, it makes it cleaner and easier to express ideas.
rmc 16y ago
Code in a more productive (i.e. higher level) language is concise because it hides extra complexity you don't need to think about at the time, and is therefore simpler, not more complex (in the second sense). Another example of where this is true is automatic memory management. A line of Java code can do all the memory management that would take many lines in C. This is a mostly good thing. In this case, less lines = better.

RyanMcGreal 16y ago

> start putting in all the 'fluff' like indenting their code One of the many nice things about Python is that whitespace - specifically, indenting - is significant.

samratjp 16y ago
And that feature alone makes for readability in large projects :-)
p_nathan 16y ago
I've had multiple bugs based on whitespace being significant. A C-descended language which had braces around the block would not have had the bug at all. Another problem with it is that I can't just comment out, say, an if, and have the code under it run automatically. I have to go through and reformat the business, leading to potential bugs. This also plays into refactoring as well. Basically, I find the whitespace rule something that should have been left in the 60s with punch cards. I am not a fan of Python. I consider Common Lisp and Perl to be fundamentally less ambiguous languages.
- RyanMcGreal 16y ago
  > I've had multiple bugs based on whitespace being significant. Interesting. In several years programming with Python, I've had exactly zero bugs based on whitespace being significant. > I can't just comment out, say, an if What I do is comment out the if statement and add another if statement under it, like so: #if condition: if 1 == 1: # FIXME temp code for testing do_something() I always grep my code for FIXMEs before pushing to production, and have my text editor configured to highlight FIXMEs and TODOs.

srean 16y ago

I am a scheme neophyte. In my personal experience it has been a very thought compressible language. By that, what I mean is this: if you give more thought to a program one tends to be able to say more and more but with less and less, and without making the code incomprehensible or complex. Interestingly, when I show my code to a scheme veteran, he would often re-write it to make it even shorter and clearer. So I have a long way to go. So line for line , yes it takes me more time to churn out scheme, but if I give the same amount of time to c++/java it doesnt compress as much. But, and here is the cool part, if it does, I can often trace it back to scheme way of thinking. This has happened a lot when programming with C++/STL.

rmc 16y ago

I still try to optimise for readability, simplicity and elegance in my code. That's a good goal. One advantage of Python is that indentation etc. are required. You can't take a 'short cut' and write messy code, cause your code won't run.

sigzero 16y ago
I am not arguing this but I think programming is in a sense "expressing oneself" and the "one way" and the "rigidity" of Python might turn some people off. Sometimes...you need to take that "short cut".
ewjordan 16y ago
One advantage of Python is that indentation etc. are required. This is such baloney. I've written hundreds of thousands of lines of code in Algol-esque languages, and just about every last line (by which I mean > 99.9%, with possibly exceptions once in a blue moon where I accidentally hit tab before I compile or something like that, which just gets cleaned up the next time I reformat anyways...) of that was properly indented. It's just too easy not to do, and I'd fire, almost immediately, anyone that was checking in code that wasn't indented properly. Really. Where are all these horrible developers that don't sanely indent their code? To hear the Python folks tell it, they're fucking up codebases all over the place with their carelessness, but I've never personally experienced any pain whatsoever over this. Certainly nothing that a simple CMD+i can fix... Hell, different newline types interacting badly with version control have caused me so much more trouble than indentation, and Python's not immune to that. Nor is it immune to people's editors globally forcing tabs to spaces or vice versa.