It's difficult to find give hard evidence here, but not because it doesn't exist. 30% reduction seems to be the most quoted number when comparing idiomatic Scala to idiomatic Java, and this definitely matches my own experience.
So where does the figure come from? Presentations mostly, by figures such as David Pollak, Bill Venners, Martin Odersky and Miles Sabin, all of whom have experience of working directly with large companies that have made the conversion in large scale real-life commercial projects. and therein lies the problem... these same companies are (quite understandably) also not going to release their proprietary code for analysis by a third party. For now, I can only hope we'll see a suitably large open-source project make the same conversion, then we'll have some hard numbers freely available for anyone to compare. In the meantime, I have to ask myself "Do I trust that Martin is honest and professional enough to quoting genuine figures and not just making them up?". Ultimately, he has nothing to gain by doing so, and an entire reputation to lose if he's been lying and the statistics are later shown to be "pure bullpuckey". So do I wish I had harder evidence to cite? Of course I do... I the meantime, do I instead have utmost confidence in the numbers that I am seeing quoted from "official" sources? Absolutely! On 18 September 2010 10:46, Viktor Klang <[email protected]> wrote: > > > On Sat, Sep 18, 2010 at 10:25 AM, Reinier Zwitserloot > <[email protected]>wrote: > >> A 1 : 3 reduction in LOC? Don't make preposterous claims. >> >> 1 : 3 rates is what happens when you rewrite a project, from scratch, >> now knowing exactly what you've learned. That's obviously not a fair >> comparison. >> >> In my own experience, Scala code tends to be about ~85% to ~90% of the >> lines that java source code is. But LOC is an extremely flawed measure >> of code complexity, so I'm not sure this is a useful construct. >> > > What is the basis of this claim, I want examples. > > >> >> The answer to your question is much, much simpler: Your 1 : 3 rate is >> bullpuckey. >> > > Are you honestly fighting unsubstantiated claims with unsubstantiated > claims, why waste your time? > > > There's too much opinions and too little facts in this thread, which makes > it for some quite sad reading. > I'm going to stop read the JavaPosse ML if the level of reasoning isn't > improved. > > >> On Sep 18, 9:54 am, Kevin Wright <[email protected]> wrote: >> > Every summary I've seen for a project converted from Java to Scala >> reports, >> > at minimum, a 1 : 3 reduction in LOC. >> > >> > If this isn't from making invisible / automating trivial detail (as per >> your >> > definition of higher level) then where's all the code going? >> > It can't *all* be in the semicolons! >> > >> > On 18 September 2010 04:03, Reinier Zwitserloot <[email protected]> >> wrote: >> > >> > >> > >> > > Ah, that was it; variable declarations are expressions but their value >> > > isn't what you might think. I knew there was some reason for not >> > > trying to use them as one. >> > >> > > Your extends example doesn't make any sense to me. It's the same in >> > > java: >> > >> > > interface X { >> > > int property(); >> > > } >> > >> > > class Y implements X { >> > > public int property() { >> > > return 32; >> > > } >> > > } >> > >> > > I gave you a useful definition of 'higher level'. I don't really see >> > > how saying "But I think scala IS higher level" without either defining >> > > what you mean or giving examples that fit my particular definition is >> > > a good idea, given that we just got into a 200+ post mess due to >> > > confusion about the term "complexity". >> > >> > > On Sep 17, 5:50 pm, Kevin Wright <[email protected]> wrote: >> > > > On 17 September 2010 16:18, Reinier Zwitserloot <[email protected] >> > >> > > wrote: >> > >> > > > > Correction: In java, as in scala, all expressions "return" a value >> > > > > (not really the right term, that. Expressions *have* a value is >> closer >> > > > > to the mark). It's just that in scala more things are expressions. >> > > > > Like "if": Expression in scala, statement in java. Not ALL things >> in >> > > > > scala are expressions. Variable declarations aren't, for example. >> > >> > > > Hot from the Scala REPL: >> > >> > > > scala> val x = { val y = 32 } >> > > > x: Unit = () >> > >> > > > So even variable assignments evaluate to a value. >> > >> > > > > In any java library that isn't completely worthless, the code is >> > > > > "getField()". If you get annoyed at writing out the accessor, use >> > > > > lombok. Claiming that as a benefit to scala seems like you're >> grasping >> > > > > for reasons. >> > >> > > > It's a major benefit: >> > >> > > > trait X { >> > > > def property : Int >> > >> > > > } >> > >> > > > class Y extends X { >> > > > val property = 32 >> > >> > > > } >> > >> > > > When I use `property` from an object of type X, it really doesn't >> matter >> > > if >> > > > it's implemented via a field of if it's computed. >> > > > That freedom from having to know (or care) is a simplification to >> me. >> > >> > > > > A useful definition for "higher level" is that it makes invisible >> / >> > > > > automated whatever's trivial detail. This is a double-edged knife, >> > > > > though: Whether or not a detail is trivial depends on the problem. >> For >> > > > > example, C conveniently abstracts away the concept of stack, but >> in >> > > > > the process of doing so, removes the ability to store stacks. The >> JVM >> > > > > abstracts away memory management, but in the process of doing so >> > > > > introduces non-determinism due to gc runs. >> > >> > > > > However, with that definition scala isn't much higher than java. >> There >> > > > > aren't many things that you can no longer do in scala but which >> you >> > > > > can do in java, and on the flipside, there aren't many things that >> are >> > > > > orders of magnitude simpler in scala than java because something >> has >> > > > > been abstracted away. Scala is more a sideways step: It's >> operating at >> > > > > the same general level of abstraction as java, but with a >> different >> > > > > syntax, which includes more emphasis on function objects >> (something >> > > > > java CAN do, but not with particularly nice syntax), as well as a >> less >> > > > > rigid syntax structure, and a general more functional outlook. >> > >> > > > Function objects are just a tiny part of it, not only does Scala >> have >> > > > functions that are objects, but also any arbitrary object can be >> made >> > > into a >> > > > function. >> > > > On top of this there's pattern matching, implicits (which allow for >> type >> > > > classes), higher-kinded types and by-name params. >> > > > Closures alone don't make a language higher level than Java, but >> Scala >> > > > really isn't about just closures... >> > >> > > > Just compare the implementation of a heterogenous list in both >> languages: >> > > >> http://apocalisp.wordpress.com/2008/10/23/heterogeneous-lists-and-the.... >> > > .. >> > >> > > > > On Sep 17, 3:28 pm, Kevin Wright <[email protected]> >> wrote: >> > > > > > I'm recently taking the position that it's impossible to state >> which >> > > of >> > > > > two >> > > > > > languages is "simpler", the term is just too heavily overloaded. >> > >> > > > > > Just pick your definition and it's trivial to show that assembly >> is >> > > > > simpler >> > > > > > than LISP, or vice-versa, but you've still achieved nothing. If >> we >> > > use >> > > > > the >> > > > > > term "higher-level" instead of "simpler", then this difficulty >> > > > > evaporates. >> > >> > > > > > Personally I feel that Scala is simpler than Java, but that >> statement >> > > > > means >> > > > > > nothing without also explaining the particular definition of the >> term >> > > > > that >> > > > > > matters to me. In this case, it's two features of that language >> that >> > > > > really >> > > > > > stand out, and show Scala to be the higher-level language.. >> > >> > > > > > 1. It has constructs that closely match the way I think about >> > > problems. >> > > > > > When I have to mangle the design in my head so that it matches >> the >> > > > > features >> > > > > > of the target language, I perceive that as an unneccessary >> > > complication >> > > > > in >> > > > > > the design+implementation process. >> > > > > > 2. Scala has a smaller general-purpose syntax that I can use >> accross >> > > a >> > > > > wide >> > > > > > range of problems, instead of a larger number special-case >> > > constructs. >> > > > > For >> > > > > > example: >> > >> > > > > > - Java has the ?: operator, but Scala has the much more general >> idea >> > > that >> > > > > > all expressions return a value. >> > >> > > > > > - Java has a switch statement over numbers, enums and (soon) >> Strings, >> > > > > wheras >> > > > > > Scala has pattern matching that isn't limited to any type. >> > >> > > > > > - Java has primitives, and operators are limited to only working >> with >> > > > > > primitives. Everything in Scala is an object, and operators are >> just >> > > > > > methods. >> > >> > > > > > - Java has special behaviour for concatenating an object or >> primitive >> > > to >> > > > > a >> > > > > > string, Scala can do this with implicit conversions - a feature >> > > that's >> > > > > > useful in many more situations. >> > >> > > > > > - To fetch a value from an object in Java, I must first know if >> it's >> > > a >> > > > > fixed >> > > > > > value or if it'll be calculated, and so use field or getField() >> as >> > > > > > appropriate, Scala doesn't force this distinction and so it's >> enough >> > > to >> > > > > know >> > > > > > I'm fetching a value, the underlying logic could even be changed >> in >> > > the >> > > > > > future without breaking my code. >> > >> > > > > > The ability to work with general concepts and not have to chose >> > > exactly >> > > > > > which special feature I need in a given situation... I see that >> as >> > > > > > simplifying the task of programming. >> > > > > > I could say more, but it's probably just "simpler" to point >> here: >> > > > > >> http://stackoverflow.com/questions/727078/whats-so-great-about-scala/. >> > > .. >> > >> > > > > > On 17 September 2010 11:30, Reinier Zwitserloot < >> [email protected]> >> > > > > wrote: >> > >> > > > > > > That just sounds like equating "simple" to "less verbose". >> > >> > > > > > > For example, with optional () for args-less method calls, you >> get a >> > > > > > > number of things which one might deem "simpler": >> > >> > > > > > > - Less characters to type and read >> > > > > > > - The ability to not have to care about whether the doClick >> member >> > > is >> > > > > > > a method or a field >> > >> > > > > > > On the other hand, you also get a few things which are >> decidedly >> > > more >> > > > > > > complicated: >> > >> > > > > > > - A stylistic choice about whether or not you add the (). >> Having >> > > to >> > > > > > > make an irrelevant choice of any sort clearly seems like a >> lack of >> > > > > > > simplicity to me. >> > > > > > > - The INability to tell if doClick is a field or a method. In >> > > certain >> > > > > > > circumstances it matters, and having to look it up is more >> > > complicated >> > > > > > > than being able to tell at a casual glance. >> > >> > > > > > > These are clearly conflicting requirements. Forcing you to >> care >> > > > > > > whether doClick is a field or a method is needless >> complexity.... >> > > > > > > unless it isn't, in which case not being able to tell is >> needless >> > > > > > > complexity. Offering the programmer the choice doesn't help, >> > > because >> > > > > > > the choice in it self is needless complexity, and by existing >> we >> > > still >> > > > > > > can't tell, given "foo.doClick", if doClick is a field or a >> method. >> > > > > > > We'd have to rely on a programmer following the local style >> > > guidelines >> > > > > > > (if, say, these state that non-fields ought to be called with >> > > parens), >> > > > > > > which you can' even unit test. Now we're introducing needless >> > > > > > > complexity there. >> > >> > > > > > > Oh, how complicated. >> > >> > > > > > > There's also the issue of moving complexity around to the >> problem >> > > > > > > domain. My usual retort to those complaining about the >> complexity >> > > of >> > > > > > > generics is simply this: Co- and Contravariance is >> _inherently_ >> > > > > > > complicated. When you have a problem where generics is >> required or >> > > > > > > seems quite useful, then the problem has this complexity, >> > > inherently. >> > > > > > > You can choose not to use generics, but then the complexity is >> just >> > > > > > > hidden away in javadocs and a bunch of casts. You can tweak >> > > generics a >> > > > > > > bit, declaration-site generics probably being the most >> drastic, but >> > > a >> > > > > > > truly "simple" generics will never be, because >> co/contravariance >> > > isn't >> > > > > > > simple. >> > >> > > > > > > So, did java become more complex when 1.5 was introduced? Yes. >> Does >> > > > > > > this mean java 1.5 is worse than 1.4? No - in fact, it's >> better. >> > >> > > > > > > So, in certain ways, a more complex language is actually a >> good >> > > thing. >> > >> > > > > > > Hence my conclusion that all this talk about "complexity" is >> not >> > > going >> > > > > > > to convince anybody one way or another, because its very very >> easy >> > > for >> > > > > > > anyone reading the word "complexity" and imagine whatever >> situation >> > >> > ... >> > >> > read more » >> >> -- >> 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]<javaposse%[email protected]> >> . >> For more options, visit this group at >> http://groups.google.com/group/javaposse?hl=en. >> >> > > > -- > Viktor Klang, > Code Connoisseur > Work: www.akkasource.com > Code: github.com/viktorklang > Follow: twitter.com/viktorklang > Read: klangism.tumblr.com > > > -- > 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]<javaposse%[email protected]> > . > For more options, visit this group at > http://groups.google.com/group/javaposse?hl=en. > -- Kevin Wright mail / gtalk / msn : [email protected] pulse / skype: kev.lee.wright twitter: @thecoda -- 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.
