5 ms·

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

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

by runT1ME 16y ago

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.