correction: "I'm finding libraries written in Scala to be far more powerful and usable than libraries written in Java."
On 28 August 2012 10:18, Kevin Wright <[email protected]> wrote: > Speaking of which... > > Programming languages nowadays are rarely used in isolation. The size of > code and time taken to write it is determined in no small part by the > libraries/frameworks you'll be using. > > For me, much of the joy in Scala comes from the growing ecosystem as much > as from the language itself, and I'm finding libraries written in Scala to > be far more powerful and usable than libraries written in Scala. > > A lot of this comes from having a chance to learn from past experience, > and can be seen even without changing languages (e.g. log4j -> slf4j, > calendar -> JodaTime). But there's also a lot which comes from the richer > type system, from symbolic method names, and from the potential for DSLs. > > I'm still not sure if it would be possible to craft a study that can > compare two languages, *with their ecosystems*, and not be in some way > biased. > > > > On 28 August 2012 10:03, Matthew Farwell <[email protected]> wrote: > >> 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.
