|
[scala] Scala as the long term replacement for java/javac?
Hello all,
Today I came across with this blog post:
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.htmlSeems like James has great faith in Scala. I do, too, as Scala has got
many amazing strengths. But to replace Java?
I've come across with this Introduction to Functional Languages
lately: http://java.dzone.com/articles/introduction-functional . One
statement was that "An important observation is that functional
languages are not a replacement for procedural or object-oriented
programming language", which I totally agree with. The “polygot
programmer” seems to be the future trend for me.
So what's your view on it?
Cheers,
--
Sai Yang
Beijing 51CTO Information Technology Ltd
|
|
Re: [scala] Scala as the long term replacement for java/javac?
Well, for my own project I'm happy I'm replacing my Java code with Scala code. Readability, lightness... and if you want a dysfunctional programming style, that's available too.
2009/7/6 Yang Sai <yangsai1119@...>Hello all,
Today I came across with this blog post:
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
Seems like James has great faith in Scala. I do, too, as Scala has got
many amazing strengths. But to replace Java?
I've come across with this Introduction to Functional Languages
lately: http://java.dzone.com/articles/introduction-functional . One
statement was that "An important observation is that functional
languages are not a replacement for procedural or object-oriented
programming language", which I totally agree with. The “polygot
programmer” seems to be the future trend for me.
So what's your view on it?
Cheers,
--
Sai Yang
Beijing 51CTO Information Technology Ltd
-- Thanks, -Vlad
|
|
Re: [scala] Scala as the long term replacement for java/javac?
Replacing Java with Scala doesn't mean you're trading in an object-oriented programming language for a functional programming language. Scala is an object-oriented programming language too. In fact, it has more advanced OO features (traits, singletons, path-dependent types, to name a few) than Java does.
You're trading an OO programming language for another OO programming language, with more advanced OO features, that also has some functional features.
--j
On Tue, Jul 7, 2009 at 12:38 AM, Yang Sai <yangsai1119@...> wrote:
Hello all,
Today I came across with this blog post:
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
Seems like James has great faith in Scala. I do, too, as Scala has got
many amazing strengths. But to replace Java?
I've come across with this Introduction to Functional Languages
lately: http://java.dzone.com/articles/introduction-functional . One
statement was that "An important observation is that functional
languages are not a replacement for procedural or object-oriented
programming language", which I totally agree with. The “polygot
programmer” seems to be the future trend for me.
So what's your view on it?
Cheers,
--
Sai Yang
Beijing 51CTO Information Technology Ltd
|
|
Re: [scala] Scala as the long term replacement for java/javac?
Hello, I read the post from James yesterday and in principle I share his statements. Scala has everything to replace Java in almost any area where Java is well suited, what doesn't mean, there is not place for other languages. But I think no one can say how it'll really be in the future, if the community will really switch to Scala. But despite how the future trends will look like, I'll use Scala instead of Java as much as I can.
Cheers, 2009/7/7 Yang Sai <yangsai1119@...>
Hello all,
Today I came across with this blog post:
http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.html
Seems like James has great faith in Scala. I do, too, as Scala has got
many amazing strengths. But to replace Java?
I've come across with this Introduction to Functional Languages
lately: http://java.dzone.com/articles/introduction-functional . One
statement was that "An important observation is that functional
languages are not a replacement for procedural or object-oriented
programming language", which I totally agree with. The “polygot
programmer” seems to be the future trend for me.
So what's your view on it?
Cheers,
--
Sai Yang
Beijing 51CTO Information Technology Ltd
-- Dr. Antonio R. Rodríguez Santiesteban Java-Plattform-Entwickler E-Mail: antonio.rodriguez@..., rodant68@...
|
|
Re: [scala] Scala as the long term replacement for java/javac?
Some parts of this message have been removed.
Learn more about Nabble's security policy.
In the comments it was pointed out that scala does not exercise every jvm capability (e.g. you can't write arbitrary static methods in scala). This is not a goal for scala but perhaps it should be for java.
In this view, java would remain the fundamental jvm language even though most code would eventually be written in other, higher-level languages, especially scala.
- Arnold
On Tue, 7 Jul 2009 16:54:17 Antonio Rodríguez S. wrote:
> Hello,
>
> I read the post from James yesterday and in principle I share his
> statements. Scala has everything to replace Java in almost any area where
> Java is well suited, what doesn't mean, there is not place for other
> languages. But I think no one can say how it'll really be in the future, if
> the community will really switch to Scala. But despite how the future
> trends will look like, I'll use Scala instead of Java as much as I can.
>
> Cheers,
>
> 2009/7/7 Yang Sai < yangsai1119@...>
>
> > Hello all,
> >
> > Today I came across with this blog post:
> >
> > http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.h
> >tml
> >
> > Seems like James has great faith in Scala. I do, too, as Scala has got
> > many amazing strengths. But to replace Java?
> > I've come across with this Introduction to Functional Languages
> > lately: http://java.dzone.com/articles/introduction-functional . One
> > statement was that "An important observation is that functional
> > languages are not a replacement for procedural or object-oriented
> > programming language", which I totally agree with. The “polygot
> > programmer” seems to be the future trend for me.
> >
> > So what's your view on it?
> >
> > Cheers,
> >
> > --
> > Sai Yang
> > Beijing 51CTO Information Technology Ltd
--
Arnold deVos
Langdale Consultants
|
|
Re: [scala] Scala as the long term replacement for java/javac?
Scala has done a lot to remove unnecessary Java features as well as adding new ones. "arbitrary static methods" is a good example of this. I personally can't stand the things, they're a hangover from the global state of procedural languages and the C++ heritage. If the singleton pattern had come along first then I seriously doubt that static methods would even exist.
Dropping this kind of baggage is as much a part of evolution as adding new functionality. Would you argue that we don't make good use of our genetic "virtual machines" because we lack tails and luxurious full-body hair?
On Tue, Jul 7, 2009 at 10:56 AM, Arnold deVos <adv-list-scala@...> wrote:
In the comments it was pointed out that scala does not exercise every jvm capability (e.g. you can't write arbitrary static methods in scala). This is not a goal for scala but perhaps it should be for java.
In this view, java would remain the fundamental jvm language even though most code would eventually be written in other, higher-level languages, especially scala.
- Arnold
On Tue, 7 Jul 2009 16:54:17 Antonio Rodríguez S. wrote:
> Hello,
>
> I read the post from James yesterday and in principle I share his
> statements. Scala has everything to replace Java in almost any area where
> Java is well suited, what doesn't mean, there is not place for other
> languages. But I think no one can say how it'll really be in the future, if
> the community will really switch to Scala. But despite how the future
> trends will look like, I'll use Scala instead of Java as much as I can.
>
> Cheers,
>
> 2009/7/7 Yang Sai < yangsai1119@...>
>
> > Hello all,
> >
> > Today I came across with this blog post:
> >
> > http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.h
> >tml
> >
> > Seems like James has great faith in Scala. I do, too, as Scala has got
> > many amazing strengths. But to replace Java?
> > I've come across with this Introduction to Functional Languages
> > lately: http://java.dzone.com/articles/introduction-functional . One
> > statement was that "An important observation is that functional
> > languages are not a replacement for procedural or object-oriented
> > programming language", which I totally agree with. The “polygot
> > programmer” seems to be the future trend for me.
> >
> > So what's your view on it?
> >
> > Cheers,
> >
> > --
> > Sai Yang
> > Beijing 51CTO Information Technology Ltd
--
Langdale Consultants
|
|
Re: [scala] Scala as the long term replacement for java/javac?
Some parts of this message have been removed.
Learn more about Nabble's security policy.
I think we are stuck with jvm legacy just as there is much biological legacy in our bodies. If we need to tinker with the primitive reptilean brain within, lets reserve java for that :-)
- Arnold
On Tue, 7 Jul 2009 20:33:25 Kevin Wright wrote:
> Scala has done a lot to remove unnecessary Java features as well as adding
> new ones.
> "arbitrary static methods" is a good example of this.
>
> I personally can't stand the things, they're a hangover from the global
> state of procedural languages and the C++ heritage. If the singleton
> pattern had come along first then I seriously doubt that static methods
> would even exist.
>
> Dropping this kind of baggage is as much a part of evolution as adding new
> functionality. Would you argue that we don't make good use of our genetic
> "virtual machines" because we lack tails and luxurious full-body hair?
--
Arnold deVos
Langdale Consultants
|
|
Re: [scala] Scala as the long term replacement for java/javac?
That's all well and good, but as long as other JVM languages are not
written with Scala in mind, we don't want them to have to write
Foo$.MODULE$.bar(), which is ugly in the prettiest untyped languages.
2009/7/7 Kevin Wright < kev.lee.wright@...>:
> Scala has done a lot to remove unnecessary Java features as well as adding
> new ones.
> "arbitrary static methods" is a good example of this.
>
> I personally can't stand the things, they're a hangover from the global
> state of procedural languages and the C++ heritage. If the singleton
> pattern had come along first then I seriously doubt that static methods
> would even exist.
>
> Dropping this kind of baggage is as much a part of evolution as adding new
> functionality. Would you argue that we don't make good use of our genetic
> "virtual machines" because we lack tails and luxurious full-body hair?
>
>
> On Tue, Jul 7, 2009 at 10:56 AM, Arnold deVos
> < adv-list-scala@...> wrote:
>>
>> In the comments it was pointed out that scala does not exercise every jvm
>> capability (e.g. you can't write arbitrary static methods in scala). This is
>> not a goal for scala but perhaps it should be for java.
>>
>> In this view, java would remain the fundamental jvm language even though
>> most code would eventually be written in other, higher-level languages,
>> especially scala.
>>
>> - Arnold
>>
>> On Tue, 7 Jul 2009 16:54:17 Antonio Rodríguez S. wrote:
>> > Hello,
>> >
>> > I read the post from James yesterday and in principle I share his
>> > statements. Scala has everything to replace Java in almost any area
>> > where
>> > Java is well suited, what doesn't mean, there is not place for other
>> > languages. But I think no one can say how it'll really be in the future,
>> > if
>> > the community will really switch to Scala. But despite how the future
>> > trends will look like, I'll use Scala instead of Java as much as I can.
>> >
>> > Cheers,
>> >
>> > 2009/7/7 Yang Sai < yangsai1119@...>
>> >
>> > > Hello all,
>> > >
>> > > Today I came across with this blog post:
>> > >
>> > >
>> > > http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.h>> > >tml
>> > >
>> > > Seems like James has great faith in Scala. I do, too, as Scala has got
>> > > many amazing strengths. But to replace Java?
>> > > I've come across with this Introduction to Functional Languages
>> > > lately: http://java.dzone.com/articles/introduction-functional . One
>> > > statement was that "An important observation is that functional
>> > > languages are not a replacement for procedural or object-oriented
>> > > programming language", which I totally agree with. The “polygot
>> > > programmer” seems to be the future trend for me.
>> > >
>> > > So what's your view on it?
>> > >
>> > > Cheers,
>> > >
>> > > --
>> > > Sai Yang
>> > > Beijing 51CTO Information Technology Ltd
>>
>>
>> --
>> Arnold deVos
>> Langdale Consultants
>
--
Ricky Clarkson
Java Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
|
|
Re: [scala] Scala as the long term replacement for java/javac?
Oh yeah, that one definitely needs a fix that will stay in trunk for more than 5 minutes... :) On Tue, Jul 7, 2009 at 12:56 PM, Ricky Clarkson <ricky.clarkson@...> wrote:
That's all well and good, but as long as other JVM languages are not
written with Scala in mind, we don't want them to have to write
Foo$.MODULE$.bar(), which is ugly in the prettiest untyped languages.
2009/7/7 Kevin Wright <kev.lee.wright@...>:
> Scala has done a lot to remove unnecessary Java features as well as adding
> new ones.
> "arbitrary static methods" is a good example of this.
>
> I personally can't stand the things, they're a hangover from the global
> state of procedural languages and the C++ heritage. If the singleton
> pattern had come along first then I seriously doubt that static methods
> would even exist.
>
> Dropping this kind of baggage is as much a part of evolution as adding new
> functionality. Would you argue that we don't make good use of our genetic
> "virtual machines" because we lack tails and luxurious full-body hair?
>
>
> On Tue, Jul 7, 2009 at 10:56 AM, Arnold deVos
> < adv-list-scala@...> wrote:
>>
>> In the comments it was pointed out that scala does not exercise every jvm
>> capability (e.g. you can't write arbitrary static methods in scala). This is
>> not a goal for scala but perhaps it should be for java.
>>
>> In this view, java would remain the fundamental jvm language even though
>> most code would eventually be written in other, higher-level languages,
>> especially scala.
>>
>> - Arnold
>>
>> On Tue, 7 Jul 2009 16:54:17 Antonio Rodríguez S. wrote:
>> > Hello,
>> >
>> > I read the post from James yesterday and in principle I share his
>> > statements. Scala has everything to replace Java in almost any area
>> > where
>> > Java is well suited, what doesn't mean, there is not place for other
>> > languages. But I think no one can say how it'll really be in the future,
>> > if
>> > the community will really switch to Scala. But despite how the future
>> > trends will look like, I'll use Scala instead of Java as much as I can.
>> >
>> > Cheers,
>> >
>> > 2009/7/7 Yang Sai < yangsai1119@...>
>> >
>> > > Hello all,
>> > >
>> > > Today I came across with this blog post:
>> > >
>> > >
>> > > http://macstrac.blogspot.com/2009/04/scala-as-long-term-replacement-for.h
>> > >tml
>> > >
>> > > Seems like James has great faith in Scala. I do, too, as Scala has got
>> > > many amazing strengths. But to replace Java?
>> > > I've come across with this Introduction to Functional Languages
>> > > lately: http://java.dzone.com/articles/introduction-functional . One
>> > > statement was that "An important observation is that functional
>> > > languages are not a replacement for procedural or object-oriented
>> > > programming language", which I totally agree with. The “polygot
>> > > programmer” seems to be the future trend for me.
>> > >
>> > > So what's your view on it?
>> > >
>> > > Cheers,
>> > >
>> > > --
>> > > Sai Yang
>> > > Beijing 51CTO Information Technology Ltd
>>
>>
>> --
>> Arnold deVos
>> Langdale Consultants
>
Ricky Clarkson
Java Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
|
|
Re: [scala] Scala as the long term replacement for java/javac?
On Tue, 7 Jul 2009 12:56:30 +0100
Ricky Clarkson < ricky.clarkson@...> wrote:
> That's all well and good, but as long as other JVM languages are not
> written with Scala in mind, we don't want them to have to write
> Foo$.MODULE$.bar(), which is ugly in the prettiest untyped languages.
I think that is actually not so much of a problem (disclaimer: So far I
haven't done much with Java<->Scala interoperation). Trying to call a
different language's constructs is always somewhat awkward at best. I
think if you write Scala code that's intended to be used by Java
code -- e.g. a library you're writing in Scala -- then a reasonable
course of action would be to provide proper bindings in that language.
That way you can hide the strange module names in a more-or-less thin
wrapper and at the same time provide a probably better-suited interface
to your actual code.
Carl-Eric
|
|
Re: [scala] Scala as the long term replacement for java/javac?
> On Tue, 7 Jul 2009 12:56:30 +0100
> Ricky Clarkson < ricky.clarkson@...> wrote:
>
>> That's all well and good, but as long as other JVM languages are not
>> written with Scala in mind, we don't want them to have to write
>> Foo$.MODULE$.bar(), which is ugly in the prettiest untyped languages.
>
> I think that is actually not so much of a problem (disclaimer: So far I
> haven't done much with Java<->Scala interoperation). Trying to call a
> different language's constructs is always somewhat awkward at best. I
> think if you write Scala code that's intended to be used by Java
> code -- e.g. a library you're writing in Scala -- then a reasonable
> course of action would be to provide proper bindings in that language.
> That way you can hide the strange module names in a more-or-less thin
> wrapper and at the same time provide a probably better-suited interface
> to your actual code.
>
Require explicitly write Java interface API (on Java) for all exported
functions is not a very good idea, from productivity point of view: any
simple listing of all methods will increase amount of work and require
time for switching between Java and Scala.
> Carl-Eric
>
|
|
Re: [scala] Scala as the long term replacement for java/javac?
On Tue, 7 Jul 2009 15:29:47 +0300 (EEST)
"Ruslan Shevchenko" < rssh@...> wrote:
> Require explicitly write Java interface API (on Java) for all
> exported functions is not a very good idea, from productivity point
> of view: any simple listing of all methods will increase amount of
> work and require time for switching between Java and Scala.
That's true, it's slightly more work. But without doing that you will
always have a level of awkwardness when calling into Scala from any
other language, because constructs won't necessarily match 1:1 anyway.
Whether that is a price you're willing to pay depends on the project
and the target audience. It's a trade-off, with both sides having their
merits, I think.
Carl-Eric
|
|
Re: [scala] Scala as the long term replacement for java/javac?
Java interop is core to scala's success, the ecosystem is one of the best reasons for choosing the JVM in the first place. Java may well be eventually replaced with scala, but it won't happen any time soon
We need to be able to: - Use classes and objects from 3rd party libraries
- Create classes and objects to be consumed by 3rd party libraries
- Create libraries that can be used by native java code
- Slowly migrate existing codebases, maybe even one class at a time
2009/7/7 Ruslan Shevchenko <rssh@...>
> On Tue, 7 Jul 2009 12:56:30 +0100
> Ricky Clarkson < ricky.clarkson@...> wrote:
>
>> That's all well and good, but as long as other JVM languages are not
>> written with Scala in mind, we don't want them to have to write
>> Foo$.MODULE$.bar(), which is ugly in the prettiest untyped languages.
>
> I think that is actually not so much of a problem (disclaimer: So far I
> haven't done much with Java<->Scala interoperation). Trying to call a
> different language's constructs is always somewhat awkward at best. I
> think if you write Scala code that's intended to be used by Java
> code -- e.g. a library you're writing in Scala -- then a reasonable
> course of action would be to provide proper bindings in that language.
> That way you can hide the strange module names in a more-or-less thin
> wrapper and at the same time provide a probably better-suited interface
> to your actual code.
>
functions is not a very good idea, from productivity point of view: any
simple listing of all methods will increase amount of work and require
time for switching between Java and Scala.
> Carl-Eric
>
|
|
Re: [scala] Scala as the long term replacement for java/javac?
On Tuesday July 7 2009, Ricky Clarkson wrote:
> That's all well and good, but as long as other JVM languages are not
> written with Scala in mind, we don't want them to have to write
> Foo$.MODULE$.bar(), which is ugly in the prettiest untyped languages.
Isn't a static import sufficient to ameliorate this ugliness?
Randall Schulz
|
|
Re: [scala] Scala as the long term replacement for java/javac?
I don't know why (and this is completely anecdotological evidence),
but when I tried to call into scala-compiled classes, netbeans
autocompletion failed badly. Rather peculiar. So, I had also some
trouble figuring out the MODULE$ part itself. But forget about calling
merely a *single* method, apis can be much more powerful than that.
Neil Gafter was also talking about the issue in some talk I posted
here months ago, i.e. not the problem of calling java from scala, but
the opposite.
For some historical context (if I have my facts and product names
correct), Microsoft Excel wasn't a huge success just because it could
import Lotus Spreadsheet, which most people were using at the time.
But it succeeded when it could also export to Lotus Spreadsheet, so
people could choose Excel to do their work, without disturbing their
coworkers or introducing incompatibilities. That's the important link:
to be able to seamlessly integrate your work to whatever the others
are using, not merely importing work done in the main platform (i.e.
java). One can do wonders in scala, but then java programmers would
look at the (java) api of it and say "this sucks" (let alone having to
read scaladocs instead of javadocs!), and they won't bother. Creating
a java facade is also undesirable. This is a hard nut to crack, it
would be very good for scala success to have a good story there.
Dimitris
2009/7/7 Carl-Eric Menzel < cm.scala-ml@...>:
> On Tue, 7 Jul 2009 12:56:30 +0100
> Ricky Clarkson < ricky.clarkson@...> wrote:
>
>> That's all well and good, but as long as other JVM languages are not
>> written with Scala in mind, we don't want them to have to write
>> Foo$.MODULE$.bar(), which is ugly in the prettiest untyped languages.
>
> I think that is actually not so much of a problem (disclaimer: So far I
> haven't done much with Java<->Scala interoperation). Trying to call a
> different language's constructs is always somewhat awkward at best. I
> think if you write Scala code that's intended to be used by Java
> code -- e.g. a library you're writing in Scala -- then a reasonable
> course of action would be to provide proper bindings in that language.
> That way you can hide the strange module names in a more-or-less thin
> wrapper and at the same time provide a probably better-suited interface
> to your actual code.
>
> Carl-Eric
>
|
|
Re: [scala] Scala as the long term replacement for java/javac?
1. No, as MODULE$ is a field, not a class and thus cannot have its
members statically imported.
2. No, as you'd still have to know that this library you're using was
written in Scala.
.NET has a "Common Language Subset" for this stuff, that each 'real'
.NET language needs to support. I'd suggest the JVM's should be Java.
2009/7/7 Randall R Schulz < rschulz@...>:
> On Tuesday July 7 2009, Ricky Clarkson wrote:
>> That's all well and good, but as long as other JVM languages are not
>> written with Scala in mind, we don't want them to have to write
>> Foo$.MODULE$.bar(), which is ugly in the prettiest untyped languages.
>
> Isn't a static import sufficient to ameliorate this ugliness?
>
>
> Randall Schulz
>
--
Ricky Clarkson
Java Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
|
|
Re: [scala] Scala as the long term replacement for java/javac?
Ricky Clarkson wrote:
1. No, as MODULE$ is a field, not a class and thus cannot have its
members statically imported.
I wonder for those times when you want to expose a use static method for Java code to invoke (admittedly a fairly rare requirement), couldn't we use a compiler plugin to generate a static method hiding the $ ninja stuff?
public class Foo {
// byte code generated by compiler plugin...
public static whatnot bar() {
return Foo$.MODULE$.bar();
}
...
}
|
|
Re: [scala] Scala as the long term replacement for java/javac?
I like that, but there are cases where it won't work. E.g.:
class Foo { def foo = 5 }
object Foo { @justGenerateStaticPLEASE def foo = 5 }
The class file format does not allow one class to define two methods
whose signature only differs by whether static is present or not.
2009/7/8 James.Strachan < james.strachan@...>:
>
>
> Ricky Clarkson wrote:
>>
>> 1. No, as MODULE$ is a field, not a class and thus cannot have its
>> members statically imported.
>>
>
> I wonder for those times when you want to expose a use static method for
> Java code to invoke (admittedly a fairly rare requirement), couldn't we use
> a compiler plugin to generate a static method hiding the $ ninja stuff?
>
> public class Foo {
>
> // byte code generated by compiler plugin...
> public static whatnot bar() {
> return Foo$.MODULE$.bar();
> }
>
> ...
> }
> --
> View this message in context: http://www.nabble.com/-scala--Scala-as-the-long-term-replacement-for-java-javac--tp24367434p24387854.html> Sent from the Scala mailing list archive at Nabble.com.
>
>
--
Ricky Clarkson
Java Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@...
|
|
Re: [scala] Scala as the long term replacement for java/javac?
Ricky Clarkson wrote:
I like that, but there are cases where it won't work. E.g.:
class Foo { def foo = 5 }
object Foo { @justGenerateStaticPLEASE def foo = 5 }
The class file format does not allow one class to define two methods
whose signature only differs by whether static is present or not.
Let the annotation have an optional name to be used for the static method (which would only be used in Java-land)
How about
class Foo { def foo = 5 }
object Foo { @javaMethod("getInstance") def foo = 5 }
Then in Java land the API would be
Foo.getInstance()
|
|
Re: [scala] Scala as the long term replacement for java/javac?
Ricky Clarkson wrote:
[snip]
--
Ricky Clarkson
Java Programmer, AD Holdings
+44 1565 770804
Skype: ricky_clarkson
Google Talk: ricky.clarkson@gmail.com
BTW Ricky is it time to add Scala into your signature too :)
|
