Salut, This is one of the reasons I introduced a check into scalastyle <http://www.scalastyle.org>for public methods that have an inferred return type. The ostensible reason is that public methods form part of an interface, so if you change the return type by 'accident', it can have unintended consequences, but it does help with understanding the code as well.
Matthew Farwell. 2012/8/28 Kevin Wright <[email protected]> > 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. > -- 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.
