<story><title>Python as an Alternative to Lisp or Java, Peter Norvig revisited</title><url>http://dr-josiah.blogspot.com/2010/12/python-as-alternative-to-lisp-or-java.html</url></story><parent_chain><item><author>Stormbringer</author><text>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.&lt;p&gt;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&apos;d find someone who&apos;d been stuck on a bug for several days.  So what I&apos;d do was I&apos;d sit down with them, and start putting in all the &apos;fluff&apos; like  indenting their code, splitting lines with multiple variable declarations each onto their own line etc.  Essentially putting in all the &apos;long cuts&apos; that they&apos;d taken &apos;short cuts&apos; around in order to &apos;speed up&apos; the programming.&lt;p&gt;Often either they or I would see the problem immediately.&lt;p&gt;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.&lt;p&gt;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 &apos;more verbose&apos; 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 &apos;toss off&apos; (one off, toss away) competition, but not necessarily optimal for long term efforts.&lt;p&gt;Some of these languages that allow you to redefine the language itself on the fly allow you to do &apos;cool stuff&apos; (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&apos;d spent days or weeks on a bug only to find out it was caused by someone else &apos;tweaking&apos; one of the core classes and not bothering to tell anyone else...  &lt;i&gt;twitch&lt;/i&gt;</text></item></parent_chain><comment><author>kbd</author><text>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&apos;re equivocating on &quot;complex&quot;. Each line may be &quot;more complex&quot; in the sense &quot;does more&quot;, but not necessarily more complex as in &quot;harder to understand&quot; (and therefore more prone to bugs).&lt;p&gt;Code in a more productive (i.e. higher level) language is concise because it &lt;i&gt;&lt;/i&gt;hides&lt;i&gt;&lt;/i&gt; extra complexity you don&apos;t need to think about at the time, and is therefore &lt;i&gt;&lt;/i&gt;simpler&lt;i&gt;&lt;/i&gt;, not more complex (in the second sense).</text></comment>
<story><title>Python as an Alternative to Lisp or Java, Peter Norvig revisited</title><url>http://dr-josiah.blogspot.com/2010/12/python-as-alternative-to-lisp-or-java.html</url></story><parent_chain><item><author>Stormbringer</author><text>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.&lt;p&gt;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&apos;d find someone who&apos;d been stuck on a bug for several days.  So what I&apos;d do was I&apos;d sit down with them, and start putting in all the &apos;fluff&apos; like  indenting their code, splitting lines with multiple variable declarations each onto their own line etc.  Essentially putting in all the &apos;long cuts&apos; that they&apos;d taken &apos;short cuts&apos; around in order to &apos;speed up&apos; the programming.&lt;p&gt;Often either they or I would see the problem immediately.&lt;p&gt;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.&lt;p&gt;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 &apos;more verbose&apos; 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 &apos;toss off&apos; (one off, toss away) competition, but not necessarily optimal for long term efforts.&lt;p&gt;Some of these languages that allow you to redefine the language itself on the fly allow you to do &apos;cool stuff&apos; (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&apos;d spent days or weeks on a bug only to find out it was caused by someone else &apos;tweaking&apos; one of the core classes and not bothering to tell anyone else...  &lt;i&gt;twitch&lt;/i&gt;</text></item></parent_chain><comment><author>srean</author><text>I am a scheme neophyte. In my personal experience it has been a very &lt;i&gt;thought compressible&lt;/i&gt; language.&lt;p&gt;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.&lt;p&gt;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.&lt;p&gt;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.</text></comment>