4 ms·

If you believe, as I do, that a given programmer can produce roughly the same number of lines of code per day independent of the language used, you can see how

If you believe, as I do, that a given programmer can produce roughly the same number of lines of code per day independent of the language used, you can see how this reduction of lines of code can translate into a substantial increase in productivity and a faster time-to-market. Do people actually believe this? It seems to me the time spent typing actual lines of code is dwarfed by an order of magnitude by the time spent thinking between writing each line or method, cut and pasting for refactoring, etc. To borrow Fred Brooks' terminology, I think the most common languages at this point - certainly Java, Ruby, and Python - are at a high enough level that we spend an order of magnitude more time on fundamental rather than incidental complexity.

route66 16y ago
I Agree. If one would take "concepts a day" or structures/modules/interfaces/whatever-intelligible-concept a day I could follow he author. But lines per day? Put this way developers seem coding monkeys using smaller paper in their typewriter to produce more pages.
swannodette 16y ago
Not true at all. I encounter incidental complexity all the time when writing code in Java, Ruby, and Python. Especially when I need to interface with other libraries and other frameworks. Ruby, Python, Java deal with the expression problem very poorly. The desire to write code generically is real so you have the mess of generics and people run to dynamic langs. In dynamic langs the desire to monkey-patch is real because you often need to extend objects whose source you do not control. In dynamic langs you often want an extension point, that does not a mean a list of methods to call, rather a list of method signatures to implement so I plug my own functionality in w/o reading through your source. All this adds up to countless hours wasted. These are real problems in real software today that current mainstream languages address very poorly.
- ghotli 16y ago
  Thus summarizes the negatives. Do you have any examples of languages with effective solutions to the expression problem?
  - swannodette 16y ago
    Scala (implicits, structural typing) and Clojure (protocols, extend-type) both have great solutions to these problems. Anyone know of other langs that deal with these issues properly?
    - Zaak 16y ago
      Haskell has type classes and type inference which seem like they would be helpful.
      - joshhart 16y ago
        Scala has (limited compared to Haskell, but still powerful) type inference and a way to simulate type classes as well.
        gtani 16y ago
        Scala type inference is still evolving (as are clojure, and, I think, haskell and F#) http://www.reddit.com/r/scala/comments/ectzr/why_no_type_inference_in_scala/ http://www.reddit.com/r/scala/comments/ectzr/why_no_type_inf...
    - rlmw 16y ago
      Haskell. Aside from usual functional facilities for code reuse such as polymorphism and Higher Order Functions, monads (specifically monadic composition) and Type Classes are quite useful for writing generic code.
    - vegai 16y ago
      Go also.
    - uros643 16y ago
      Am I correct in assuming that any language with support for overloading functions for new types, instead of extending existing types with new members/methods, would have a solution to such issues? This would then also cover: * anything CLOS-inspired: Common Lisp, Dylan, Factor, Clojure * but also presumably anything with C++- or Clay-like (http://tachyon.in/clay/ http://tachyon.in/clay/) generic programming, namely w.r.t generically using freely-overloadable functions. I believe Haskell achieves something similar to this using type classes.
- anamax 16y ago
  > In dynamic langs the desire to monkey-patch is real because you often need to extend objects whose source you do not control. And in static languages, you never need to extend objects whose source you do not control. I must be doing it wrong - I've only been tempted to monkey patch once, and that was because the folks who controlled the code explicitly said to monkey patch in certain circumstances.
contextfree 16y ago
My experience is that in e.g. multi-tier web apps fundamental complexity (often little more than CRUD at its core) is still usually completely swamped by incidental complexity.
- swannodette 16y ago
  So true. Rails are Django are massive improvements but they do not in anyway represent the endgame in terms of controlling incidental complexity.
zmmmmm 16y ago
I've always disliked that metric (constant lines / day) because I've never believed it took into account the real full lifecycle of code. For example, as much as people (mostly) dislike creating code in Java, when I inherit code to maintain I love it when it is Java. It is just so straightforward with such limited ability to confuse or abstract things (as much as the many frameworks try) that I know I can always easily get to the bottom of any problem. Not to mention things like awesome debugging facilities and runtime analysis tools. With other languages I'm just lost once they reach any level of complexity because they all start doing "magic". I hope that Scala perhaps retains a little of this through it's statically typed nature - but there's enough potential for "magic" there that I suspect it's partly lost. This is why I'm quite intrigued by Mirah (http://www.mirah.org/ http://www.mirah.org/) ... but that is a long way from being mainstream enough to be useful in a wide range of situations.
- runT1ME 16y ago
  You must have had the pleasure of not looking at a system using a ton of AOP, reflection, and injection. If anything can make looking at java using a good great debugger still a nightmare, it's AOP and other such magic...
runT1ME 16y ago
>Do people actually believe this? Well, it's interesting because my reply touches on that. I don't believe writing code is the hardest part of programming. Designing and thinking about code is the hard part. This was my reply: I find the LOC discussion of Sala fascinating. In my time working on my Open Source Scala project, I've found that it does take me longer to type out each line of Scala compared to if I had done java. This is probably because Java has so much needless verbosity that doesn't require much thought. So each line with scala is actually doing something significant, I need to give it more attention. However, the fact that my program is >3k LOC means I am never trying to remember what classes do what, or why a method works the way it does, or any of the other problems you have when working on an extremely large code base. I'm not sure I'd be able to grok a 10k LOC java project near as well as I do my 3k LOC Scala project, and I'm that much faster because of it. the TL;DR is Scala that the advantage of less LOC is not that I can produce more faster, it's that I can comprehend more and fit more code into my head.
- dkarl 16y ago
  This is very true in my experience. Java programs can have a dizzying profusion of classes that seem completely gratuitous until you start thinking, "How would I do this in Java myself?" Then the classes start to make sense. You have to think in terms of implementation because the structure of the code is more complex than the solution expressed by the code. One way to understand why is to see that when a language can't directly express the ideas a programmer devises to solve a problem, the gap must be made up by design patterns. To put it another way, code = concepts + design patterns. When you're trying to figure out the intent of code, what it actually does, you rearrange the equation to read, concepts = code - design patterns. You have to recognize the design patterns in the code and subtract them out to realize what the code actually does. The more design patterns your code uses, the less the code reflects the concepts, and the more work you have to do to isolate the concepts.
Dove 16y ago
Well, the typing is not the reason we're looking at lines. With exceptions for outliers like APL, a line of code is generally a decent approximation to a unit of thoughtstuff. Within any program, you have nitty gritty bits that deal with things like vector multiplication, and you have high and mighty bits that define the sequence of actions in the main loop. But writing code in those two places proceeds at a similar pace -- regardless of whether your function calls are doing a lot or a little. So it is with programming languages. Whether you can say a lot with a line of perl, or a little with a line of C, how much you have to think about that line, how much effort goes into organizing and composing a program from those lines . . . well, it turns out to be a pretty similar pace from language to language.

route66 16y ago

I Agree. If one would take "concepts a day" or structures/modules/interfaces/whatever-intelligible-concept a day I could follow he author. But lines per day? Put this way developers seem coding monkeys using smaller paper in their typewriter to produce more pages.

swannodette 16y ago

Not true at all. I encounter incidental complexity all the time when writing code in Java, Ruby, and Python. Especially when I need to interface with other libraries and other frameworks. Ruby, Python, Java deal with the expression problem very poorly. The desire to write code generically is real so you have the mess of generics and people run to dynamic langs. In dynamic langs the desire to monkey-patch is real because you often need to extend objects whose source you do not control. In dynamic langs you often want an extension point, that does not a mean a list of methods to call, rather a list of method signatures to implement so I plug my own functionality in w/o reading through your source. All this adds up to countless hours wasted. These are real problems in real software today that current mainstream languages address very poorly.

ghotli 16y ago
Thus summarizes the negatives. Do you have any examples of languages with effective solutions to the expression problem?
- swannodette 16y ago
  Scala (implicits, structural typing) and Clojure (protocols, extend-type) both have great solutions to these problems. Anyone know of other langs that deal with these issues properly?
  - Zaak 16y ago
    Haskell has type classes and type inference which seem like they would be helpful.
    - joshhart 16y ago
      Scala has (limited compared to Haskell, but still powerful) type inference and a way to simulate type classes as well.
      - gtani 16y ago
        Scala type inference is still evolving (as are clojure, and, I think, haskell and F#) http://www.reddit.com/r/scala/comments/ectzr/why_no_type_inference_in_scala/ http://www.reddit.com/r/scala/comments/ectzr/why_no_type_inf...
  - rlmw 16y ago
    Haskell. Aside from usual functional facilities for code reuse such as polymorphism and Higher Order Functions, monads (specifically monadic composition) and Type Classes are quite useful for writing generic code.
  - vegai 16y ago
    Go also.
  - uros643 16y ago
    Am I correct in assuming that any language with support for overloading functions for new types, instead of extending existing types with new members/methods, would have a solution to such issues? This would then also cover: * anything CLOS-inspired: Common Lisp, Dylan, Factor, Clojure * but also presumably anything with C++- or Clay-like (http://tachyon.in/clay/ http://tachyon.in/clay/) generic programming, namely w.r.t generically using freely-overloadable functions. I believe Haskell achieves something similar to this using type classes.
anamax 16y ago
> In dynamic langs the desire to monkey-patch is real because you often need to extend objects whose source you do not control. And in static languages, you never need to extend objects whose source you do not control. I must be doing it wrong - I've only been tempted to monkey patch once, and that was because the folks who controlled the code explicitly said to monkey patch in certain circumstances.

contextfree 16y ago

My experience is that in e.g. multi-tier web apps fundamental complexity (often little more than CRUD at its core) is still usually completely swamped by incidental complexity.

swannodette 16y ago
So true. Rails are Django are massive improvements but they do not in anyway represent the endgame in terms of controlling incidental complexity.

zmmmmm 16y ago

I've always disliked that metric (constant lines / day) because I've never believed it took into account the real full lifecycle of code. For example, as much as people (mostly) dislike creating code in Java, when I inherit code to maintain I love it when it is Java. It is just so straightforward with such limited ability to confuse or abstract things (as much as the many frameworks try) that I know I can always easily get to the bottom of any problem. Not to mention things like awesome debugging facilities and runtime analysis tools. With other languages I'm just lost once they reach any level of complexity because they all start doing "magic". I hope that Scala perhaps retains a little of this through it's statically typed nature - but there's enough potential for "magic" there that I suspect it's partly lost. This is why I'm quite intrigued by Mirah (http://www.mirah.org/ http://www.mirah.org/) ... but that is a long way from being mainstream enough to be useful in a wide range of situations.

runT1ME 16y ago
You must have had the pleasure of not looking at a system using a ton of AOP, reflection, and injection. If anything can make looking at java using a good great debugger still a nightmare, it's AOP and other such magic...

runT1ME 16y ago

>Do people actually believe this? Well, it's interesting because my reply touches on that. I don't believe writing code is the hardest part of programming. Designing and thinking about code is the hard part. This was my reply: I find the LOC discussion of Sala fascinating. In my time working on my Open Source Scala project, I've found that it does take me longer to type out each line of Scala compared to if I had done java. This is probably because Java has so much needless verbosity that doesn't require much thought. So each line with scala is actually doing something significant, I need to give it more attention. However, the fact that my program is >3k LOC means I am never trying to remember what classes do what, or why a method works the way it does, or any of the other problems you have when working on an extremely large code base. I'm not sure I'd be able to grok a 10k LOC java project near as well as I do my 3k LOC Scala project, and I'm that much faster because of it. the TL;DR is Scala that the advantage of less LOC is not that I can produce more faster, it's that I can comprehend more and fit more code into my head.

dkarl 16y ago
This is very true in my experience. Java programs can have a dizzying profusion of classes that seem completely gratuitous until you start thinking, "How would I do this in Java myself?" Then the classes start to make sense. You have to think in terms of implementation because the structure of the code is more complex than the solution expressed by the code. One way to understand why is to see that when a language can't directly express the ideas a programmer devises to solve a problem, the gap must be made up by design patterns. To put it another way, code = concepts + design patterns. When you're trying to figure out the intent of code, what it actually does, you rearrange the equation to read, concepts = code - design patterns. You have to recognize the design patterns in the code and subtract them out to realize what the code actually does. The more design patterns your code uses, the less the code reflects the concepts, and the more work you have to do to isolate the concepts.

Dove 16y ago

Well, the typing is not the reason we're looking at lines. With exceptions for outliers like APL, a line of code is generally a decent approximation to a unit of thoughtstuff. Within any program, you have nitty gritty bits that deal with things like vector multiplication, and you have high and mighty bits that define the sequence of actions in the main loop. But writing code in those two places proceeds at a similar pace -- regardless of whether your function calls are doing a lot or a little. So it is with programming languages. Whether you can say a lot with a line of perl, or a little with a line of C, how much you have to think about that line, how much effort goes into organizing and composing a program from those lines . . . well, it turns out to be a pretty similar pace from language to language.