The line that most caught my attention was: *"One hypothesis (based on interviews) is that Scala’s automatic type inference actually made debugging more difficult."*
Anecdotally (I didn't do a study), this is absolutely true! One practice that I'm seeing repeated over multiple teams is to explicitly specify a type on a method whenever it isn't immediately obvious to a casual reader. Amongst other things, this helps the compiler catch any mistakes you make, it also speeds up compilation. This typically doesn't happen until a team is properly "bedded down" and has begun to establish some best practices. In my experience, 4 weeks is not enough to establish such a level of group intelligence. On 28 August 2012 07:51, Reinier Zwitserloot <[email protected]> wrote: > http://www.neverworkintheory.org/?p=375 > > Findings: > > * It takes longer to write the same thing in scala than in java, but the > difference is not that much. > > * The end result is less lines in scala than in java, but the difference > is not that much. > > * Programming skill was not a statistically relevant influence on how well > people managed to handle the scala side of the experiment. This goes > against widespread belief (including what I thought, and will continue to > presume might be true until more studies come out, but it has tempered this > belief for me) that scala is less suited to Joe 'I just work here' > programmer. > > * Scala code is just as performant as java code. (Is anyone who knows how > VMs work and what scala does under the hood surprised by this?) > > > It's just one study, and it is notoriously difficult to study > effectiveness of programming languages. Nevertheless, some highlights which > your random 'wow, I switched to (newlang) and my code is like 10% in size > and I can write it 5 times faster' anecdote failed to do: > > * Half the group, at random, programmed java first and scala second, and > the other half went the other way around. The considerable benefit of > having experience with the project domain in the second go around is thus > balanced. > > * The subject base is 13 people, not 1. > > * They measured things. No part of what this summary publishes involves > asking the test subjects any subjective questions. > > Of course, there are also some parts I noticed that aren't as nice: > > * It's a very specific domain: Implement this 17-page VSLI layout > algorithm specificatino (essentially: Here are a truckload of little > regions that all need to be fit and interconnected on a chip. Please write > an algorithm that'll pack it all in on the smallest possible surface. I'll > actually tell you how to do it in this 17 page document, but you have to > translate it to code). There are a million-and-one problem domains in > programming, and I wouldn't at all be surprised if the results for i.e. > code size in domain A is 50% in favour of scala (scala code half size), and > in domain B it's actually the other way around. So, we can extrapolate the > results of this to programming in general, or is this primarily useful only > if you are considering a project that is similar to writing VLSI layout > algorithms? > > * The 13 test subjects had 4 years of java experience coming into this > project, and no scala experience. They were, fortunately, given a warmup > assignment in scala to try and eliminate that part of the learning process, > but was it enough? Then again, if you're a java programmer trying to figure > out if you should switch, this part of the test means it should be more > accurate for you, so there's that. > > -- You received this message because you are subscribed to the Google Groups "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.
