Which brings us full circle, back to the claim that Scala is more programmer-oriented than Java!
As a programmer, that list would motivate me to work for a company the uses Scala As an employer, it would motivate me to hire Scala developers On 18 September 2010 14:17, Reinier Zwitserloot <[email protected]> wrote: > 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]<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.
