Yes - you can informally add Navigenics to the list since we have some
production Scala code out there. I would love to re-write the whole
code base in Scala, but it's not practical - however tests and new
modules are easy to integrate with Scala instead of Java - the first
rule when you are in a hole is to stop digging :-).
I did find a very real, very tangible advantage to using Scala.
I have noticed that the "scala is too complicated" meme is firing up
again, with a lot of new statically typed languages starting to give
simple examples. So far, those simple examples are every bit as simple
in Scala, the real test is when you start getting to the complex
problem domains. In that situation, scala does increase in complexity,
but it also gives you a higher level of abstraction to meet those more
complex demands.
When using Scala on a recent project, I was struck by how I was
writing code as short-hand and readable as python, but with the added
benefit of the compiler alerting me to errors in my assumptions about
types. Throw NetBeans into the mix and suddenly every time I saved a
file I could see if that thing I was expecting back from a third party
API was a List, or String, etc.
For example, looking at something fairly simple, like a code snippet
taken from my Funky Java, Objective Scala talk - this code is a way to
predict a probability of disease risk based on some genetic results -
it's simplified over what we really use, but in practice the result of
the more complex requirements is an even bigger win for Scala code in
a functional style.
So, in Java's imperative style, this might look something like below:
public double getGciScore(Condition condition, Map<String, CallInfo>
callMap) {
double gci = 1.0; // start with identity multiplier
for (SnpDetail snpDetail : condition.snpDetails) {
if (callMap.containsKey(snpDetail.testRsId)) {
CallInfo callInfo = callMap.get(snpDetail.testRsId);
if (callInfo.isFine()) {
Genotype geno = snpDetail.getGenotypeForCall(callInfo.call);
gci = gci * snpDetail.getOddsRatioForGenotype(geno);
}
}
}
return gci;
}
What this is doing is:
given a condition (disease) which lists a set of IDs of gene locations
- known as Test RS ID, find, in some genetic results, the raw calls
for that location (ID), let's say it looks something like "AG" (one
nucleotide of A, one of G)
One of these would be considered a "risk" outcome, and the other not,
so we convert this to what we call a normalized genotype - in this
case RN (risk, nonrisk)
this normalized genotype has a risk value assigned to it by quite
clever science people who figure such things out - let's say RR is
5.0, RN is 2.0 and NN is 1.0 (for the sake of argument)
We take the AG, map it to RN, then find out the value for RN which is
2.0
repeating this for all of the IDs specified by the condition, we end
up with a list of risks (called odds ratios) which we multiply
together, giving a product of all of these for a given condition. We
then compare it to the "average" population, and the likelihood of a
particular condition, and out pops the likelihood of that condition
for a given set of results.
The code above works fine, and is understandable, but quickly gets to
be quite obtuse as you deal with real world genetic data which has a
fair few exceptions and more complicated requirements.
An equivalent in Scala, using a functional "map/reduce" approach might
look more like this:
def gciScore(condition: Condition, callMap: Map[String, CallInfo]) = {
val matchingDetails = condition.snpDetails.filter(details =>
callMap.contains(details.testRsId) &&
callMap(details.testRsId).isFine)
val oddsRatioScores = matchingDetails.map { detail =>
detail.getOddsRatioForGenotype(detail.getGenotypeForCall(callMap(detail.testRsId)))}
oddsRatioScores.reduceLeft((a, b) => a * b)
}
What this does is:
the function definition takes the same arguments as the Java method
above, we don't have to specify a return type as it can be inferred by
the compiler, but the compiler knows what the type is supposed to be
(and does full checking for the rest of the program)
The next line filters out only those SNP details for the condition
that have a matching, fine call in the callMap provided - so we will
only work on those items throughout the rest of the function. We end
up with a list of those details that are satisfied by the call map
provided
Next, we take the details, and get the odds ratio for the normalized
genotype, which is also obtained from the snp details (inside the
parens) by using the getGenotypeForCall method, which takes the
matching call from the call map (obtained inside the second parens
using the test RS ID for the snp details). This is done for each of
the matching details we figured out in the line before. The result is
a list of double numbers representing the odds ratios for each call
result.
finally, we use a reduce operation (reduceLeft) over the list of those
odds ratio numbers, and multiple each of them with the running total,
so if we had 2.0, 3.0, 4.0 in that list we would end up with 2.0 * 3.0
* 4.0 = 24.0
The results of a last statement in a function are considered to be the
return value if you use an = when defining the function (as we did
here), and the compiler can figure out that this is going to be a
double, so the result of the method will be that number, and the
return type will be double
Note that the only place any type information occurs in this example
is for the parameter list in the function definition. Everywhere else
the compiler can work it out for you, but it is not the same as a
dynamically typed language - the compiler knows at all times what each
of the intermediate types in use is, and is ensuring that the methods
may be called and are called correctly on that type. That's where the
static type checking helps you out - you see immediately when there is
a problem, and the IDE can tell you what it is, and what type you are
working on as well.
Scala has a lot of advantages in terms of boiler plate reduction,
reduced type specification (and duplication - Java often 2 type
specifications for every variable - in both the declaration and in the
creation), but it particularly shines when applied to scientific or
mathematical problem domains.
Hope that demonstrates one case where it is useful. If you can get to
JavaOne, I will be doing my Funky Java, Objective Scala talk there,
and I hope I can make my case more strongly :-).
Dick
On Jul 30, 3:11 am, Kevin Wright <[email protected]> wrote:
> Currently it's being used by:
> twitter
> Novell
> LinkedIn
> Xerox
> EDF Trading
> Cisco
> Nature News
> Sony Pictures
> Office Depot
> SAIC
> eBay
> Siemens
> TomTom
> SAP
> Foursquare
>
> and that's just the bigger names who are willing to go public.
> I'm also informally aware of a number of Biotech firms and banks who are
> using Scala but don't want to talk about it..
>
> To address the concerns you raised:
>
> 1. Scala is still mainly an academic language and it is not mature
> enough for production;
>
> Maybe this was true 2 years ago. The Scala Foundation is currently being
> formed to help co-ordinate "enterprise" requirements.
> There are also a number of companies now willing and able to offer support
> for the language.
> In the US, Bill Venners our very own Dick Wall are offering Scala training
> and support
> In Europe, Martin Odersky & Co. have formed Scala Solutions to provide
> training and support
> In the UK, Miles Sabin has been doing this for a while, and also writing the
> Eclipse plugin for Scala
>
> So it has the best of both worlds, not only is commercial support available,
> but it has a strong academic heritage.
> It was created by the same man as the current generation of java compilers,
> and has a type system designed by people who have seriously studied type
> systems
>
> 2. When we will need to hire it will be far more difficult (and
> expansive) to find Scala developers than Java ones;
>
> I make it a matter of principle to favour candidates with more that one
> language anyway!
> Experience has shown that they're more adaptable, more willing to learn, and
> generally better coders.
>
> Asking candidates to have at least one functional language will both attract
> the more talented developers, and help weed out the weaker ones
>
> 3. The effort and cost to convert Java developers in Scala ones
> greatly overcome the advantages of writing software in Scala instead
> of in Java.
>
> Studies have shown around 4 weeks exposure before a developer becomes more
> productive than they were in Java.
> But these were done before 2.8 was released, with its better tooling and
> documentation, so this figure may well be lower now :)
>
> Honestly, if there's one thing you should take for granted that a good
> developer can do with ease, it's learning a new language.
> The transition to agile (for example) is a much bigger proposition.
>
> I think the bigger problem is how the risk is perceived. Many managers were
> themselves once active Java developers, some still are (part time).
> Such fear they'll lose control when developers migrate to a new language,
> because they'll still be stuck on Java and don't want to move out of that
> comfort zone.
>
> My advice, when selling any idea to management, find a risk then sell Scala
> as being the way to mitigate it.
> One of the biggest risks that many firms encounter is not enough unit
> testing, yet many in Management still have this gut feeling that unit tests
> somehow aren't producing something of value.
> (this is a bit like law firms imagining that due diligence isn't worth
> the hassle, it's insane!)
>
> So... sell 'em on ScalaTest as a way to write tests more productively.
> Simultaneously playing to the fear that Unit Tests take too long to write,
> yet there aren't enough of them.
> You'll also find the various styles available to be very popular
> (http://www.scalatest.org/quick_start)
>
> Once other devs are happy with Scala in testing, you can look at wider
> adoption.
>
> Also, make sure you're acquainted with Scala's faults, be honest and frank
> about them. It show's you've considered all the risks before recommending
> Scala, and still think it's a good choice.
>
> On 30 July 2010 10:28, Blanford <[email protected]> wrote:
>
>
>
>
>
> > Twitter is the only company I know of using Scala.
>
> > Unfortunately it is not working for them.
> > Their code is more buggy and unstable than ever.
>
> > On Jul 30, 4:09 am, Mario Fusco <[email protected]> wrote:
> > > Hi,
>
> > > I study and play at home with Scala from more than a year. I don't
> > > know if it will be the Next Big Language, but I know I enjoy it a lot.
> > > I also think it improves both my productivity and the readability of
> > > my code since it gives some constructs and features I miss a lot in
> > > Java.
>
> > > For these reasons I tried to introduce it at a least a couple of times
> > > in my real world job, but I found a lot of resistance from a part of
> > > the technical guys (who basically are too lazy to learn a completely
> > > new language) and especially from non-technical people who gave the
> > > following justifications:
>
> > > 1. Scala is still mainly an academic language and it is not mature
> > > enough for production;
> > > 2. When we will need to hire it will be far more difficult (and
> > > expansive) to find Scala developers than Java ones;
> > > 3. The effort and cost to convert Java developers in Scala ones
> > > greatly overcome the advantages of writing software in Scala instead
> > > of in Java.
>
> > > Of course I don't agree with this points (especially the first one),
> > > but in the end I had to give up so I am still obliged to do the 100%
> > > of my work in Java.
>
> > > After this long premise, my questions are:
>
> > > 1. How many of you are the same position of mine? And conversely, how
> > > many are using Scala in their day by day job?
> > > 2. For who is using Scala, do you find a real advantage in that?
> > > 3. How could I convince people in my company to do part of our
> > > development in Scala?
>
> > > Cheers,
> > > Mario Fusco
> > > twitter: @mariofusco
>
> > --
> > 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%2bunsubscr...@googlegroups
> > .com>
> > .
> > For more options, visit this group at
> >http://groups.google.com/group/javaposse?hl=en.
>
> --
> Kevin Wright
>
> mail/google talk: [email protected]
> wave: [email protected]
> 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.
