You have "utmost confidence" in the numbers? See, saying things like that makes me discount your personal experience as irrelevant, because it must be very flawed. How can you have utmost confidence in a secret, one-sided, clearly non-scientific comparison done by people who are _extremely_ biased in favour of scala?
This is no insult to Bill Venners and Martin Odersky. Far from it, though I am disappointed they even try to quote such numbers with a straight face. Let me try to teach you about why scientists take double blind studies seriously, and why you should absolutely NOT have "utmost confidence" in that 30% number quoted by Bill and Martin. Psychology has (scientifically!) proven that it is human nature to emphasize results that confirm our beliefs, and disregard, excuse, or simply fail to notice results that don't. This isn't malice, spite, or willful twisting of facts, it's human nature - and generally a human is not even aware they are doing it. That's why proper scientific study is so obsessed with double blind studies. A good scientist is aware that he can't even trust his own judgements if there was any chance that personal bias leaked in. It's immaterial if he is a paragon of honesty. It's a largely unconscious effect. So let's look at what it would take to make a reasonable real-world claim that scala helped reduce LOC (I'm skipping, for now, the notion that equating LOC to complexity, or readability, or maintainability, is a bad idea). Here are some factors that will clearly influence the end result to such an extent that any statistics derived from the experiment are utterly useless. How can I be sure Bill and Martin have ensured none of these affected the end result? I'm absolutely positive they haven't. If they did, they'd have written many papers. * The scala version was a rewrite of a java version, therefore the scala version got the benefit of experience. Comparing the old java code to the brand new scala version is a meaningless apples to oranges comparison. Could be fixed by having two teams BOTH rewrite the same thing, or by writing something from scratch. * The programmers that worked on the scala code just got educated in programming by such paragons as Bill Venners and Martin Odersky. If they HAVENT become better programmers as a result of that, that'd be a bit ironic, no? * Standard experiment bias: In medical studies, the constant care and attention of doctors is all by itself responsible for measurable improvement. They eliminate it by using placebos, while the attending staff has no idea who is getting the placebo and who isn't. A good experiment even takes great pains to ensure the placebo and the real medicine are not easily distinguished by smell, texture, or colour. A similar thing may well be occurring here: The mere fact that programmers get to play with a new language and 2 of the foremost promoters of it are closely watching them do it is undoubtedly going to affect their drive and dedication, which is going to make a gigantic difference in code quality, which in turn will doubtlessly be measurable in LOC. * Libraries and knowledge changes over time. The java code is perhaps the result of 10 years of coding, switching libraries, refactoring bits here and there, sneaking some crappy workarounds in to meet a deadline, and filled with domain knowledge built up over years and years of bug reports. The scala code has been freshly written against a single set of libraries, no deadlines, and no bug reports, with state of the art knowledge about good coding practice. * The programmers are now older and more experienced. * The programmers working in scala are more passionate about programming and hence likely much better at it, than the people who decided not to spend some time meeting Bill and co. Or, at a somewhat larger scale, the corporations that are switching to scala now have a programming team that is measurably different in sensibilities than your average corporation, and this difference has an effect on the pro/ con analysis between java and scala. i.e. the result of one coding team may not be a good yardstick for what some other coding team is going to do. * Something as simple as coding style that's been changed. Perhaps the switch to scala was also used to switch from open-brace-on-next-line style to open-brace-follows-condition style. That's a 20% reduction on the spot, which is of course meaningless! The list goes on, of course. Even failing to handle one item on that list is plenty distraction to make the end result meaningless. NB: Note that if some foss project DID switch from java to scala, you'd still have absolutely nothing to go on, for all the reasons stated in the above list! On Sep 18, 12:14 pm, Kevin Wright <[email protected]> wrote: > 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 > > ... > > 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]. For more options, visit this group at http://groups.google.com/group/javaposse?hl=en.
