If anyone was in any doubt that the LOC metric viewed in isolation is meaningless, I'd nominate this example as proof.
Not that I'm taking either side in the Java/Scala debate, but the last time I had to manually add, or edit an import declaration, or read through the list of imports, was about four years ago when I started using an IDE. For me now, the imports in a source file practically don't exist. Comparing LOC could only make sense when the import declarations are discounted from both sets of code*. So if there is to be any meaningful discussion based on LOC, the count has to be more sophisticated than "Source.java contains x lines, Source.scala contains y.". Unfortunately this seems to be the kind of thing that can't be discovered when studies aren't published :-( Kind regards, Graham * This is assuming Scala tools can handle imports as well as Java tools: I don't know if they can or not. > From: Ricky Clarkson <[email protected]> > > To: [email protected] > > 1 : 3 is quite conservative. 1 : 5 is more realistic. You only need to > look at your own examples of Java+Lombok to appreciate that case classes > make a massive LOC difference. > > Type inference ends up removing a few imports per file, too, as you don't > need to import a type if all you would use it for is to declare a > variable. > > Importing n types from 1 package uses 1 line in Scala, compared to n lines > in Java. import java.util.{ArrayList, List, Map, HashMap} > > The lack of checked exceptions also makes a difference to LOC. > > Lest I be named disingenuous, I should point out that for loops often take > more lines in Scala. -- You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
