Hacker News Reader

Comment by jbarciauskas | Hacker News Reader

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.

View on HN

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.

Thus summarizes the negatives. Do you have any examples of languages with effective solutions to the expression problem?

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?

Haskell has type classes and type inference which seem like they would be helpful.

Scala has (limited compared to Haskell, but still powerful) type inference and a way to simulate type classes as well.

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_inf...

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.

Go also.

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/) generic programming, namely w.r.t generically using freely-overloadable functions. I believe Haskell achieves something similar to this using type classes.

> 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.

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.

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

>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.

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.

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/) ... but that is a long way from being mainstream enough to be useful in a wide range of situations.

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...

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.

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.

Reply on news.ycombinator.com