Paul Chiusano | 1 Dec 21:56 2008
Picon

Scala job in Boston writing quantitative finance software

Hi folks,

The company I work for, ClariFI (http://clarifi.com/), is looking to hire developers with a strong background in functional programming to do a mixture of Scala and Java programming. The ideal candidate would be someone who really "gets" FP and who we could turn loose designing and implementing clean, functional code in Scala. You'd also work on extending existing Scala modules and integrating the library code you write with application code written in Java. For more info, check out our official job posting: http://www.clarifi.com/About-ClariFI-Careers.php#SoftwareEngineer

Some background on us: ClariFI is a small company (about 15 developers) that specializes in software for quantitative investment management. Our chief product, ModelStation, is used by portfolio managers for handling all stages of the quant process: building and backtesting of factors, portfolio optimization, simulation of trading strategies, performance and risk attribution, overall data management (including organizing huge amounts of time series data pulled from a diverse set of raw sources), and lots more. We don't expect you to have a background in finance but you should be willing and able to learn a lot once you start. 

This position is in our Boston office, so you must live or be willing to relocate here in order to be considered. If you're interested, send an email to myself or my boss, Scott McFarland (smcfarland <at> clarifi.com), along with your resume. Also, feel free to contact either of us if you just have questions about the position.

Cheers,
Paul

Zemian Deng | 1 Dec 22:19 2008
Picon

Re: Scala job in Boston writing quantitative finance software

It's so sweet to see companies are starting to hire Scala developers!

<at> Paul, I didn't see Scala been mentioned on your job description though. It would be nicer to see that there. :)

Best regards,
-Z

On Mon, Dec 1, 2008 at 3:56 PM, Paul Chiusano <paul.chiusano <at> gmail.com> wrote:
Hi folks,

The company I work for, ClariFI (http://clarifi.com/), is looking to hire developers with a strong background in functional programming to do a mixture of Scala and Java programming. The ideal candidate would be someone who really "gets" FP and who we could turn loose designing and implementing clean, functional code in Scala. You'd also work on extending existing Scala modules and integrating the library code you write with application code written in Java. For more info, check out our official job posting: http://www.clarifi.com/About-ClariFI-Careers.php#SoftwareEngineer

Some background on us: ClariFI is a small company (about 15 developers) that specializes in software for quantitative investment management. Our chief product, ModelStation, is used by portfolio managers for handling all stages of the quant process: building and backtesting of factors, portfolio optimization, simulation of trading strategies, performance and risk attribution, overall data management (including organizing huge amounts of time series data pulled from a diverse set of raw sources), and lots more. We don't expect you to have a background in finance but you should be willing and able to learn a lot once you start. 

This position is in our Boston office, so you must live or be willing to relocate here in order to be considered. If you're interested, send an email to myself or my boss, Scott McFarland (smcfarland <at> clarifi.com), along with your resume. Also, feel free to contact either of us if you just have questions about the position.

Cheers,
Paul



--
http://www.jroller.com/thebugslayer

Paul Chiusano | 1 Dec 23:08 2008
Picon

Re: Scala job in Boston writing quantitative finance software

Hi, just to clarify a bit about the job description.


The "official" job description doesn't specifically mention Scala as we are primarily a Java shop and we haven't (up until recently) been looking to hire Scala programmers. Over the past year we've started rolling out significant parts of our code in Scala and we're now looking to improve our collective Scala knowledge as we expand our Scala usage. To give you an idea of the Scala/Java balance, I personally write maybe 80% of my code in Scala. Unfortunately, I'm the main Scala / FP developer here and I'm fast becoming a bottleneck. I've been teaching a few other developers Scala, but folks are busy with other responsibilities and aren't getting up to speed a s fast as we need. Hence, we're trying to hire more Scala people.

Best,
Paul

On Mon, Dec 1, 2008 at 4:19 PM, Zemian Deng <thebugslayer <at> gmail.com> wrote:
It's so sweet to see companies are starting to hire Scala developers!

<at> Paul, I didn't see Scala been mentioned on your job description though. It would be nicer to see that there. :)

Best regards,
-Z


On Mon, Dec 1, 2008 at 3:56 PM, Paul Chiusano <paul.chiusano <at> gmail.com> wrote:
Hi folks,

The company I work for, ClariFI (http://clarifi.com/), is looking to hire developers with a strong background in functional programming to do a mixture of Scala and Java programming. The ideal candidate would be someone who really "gets" FP and who we could turn loose designing and implementing clean, functional code in Scala. You'd also work on extending existing Scala modules and integrating the library code you write with application code written in Java. For more info, check out our official job posting: http://www.clarifi.com/About-ClariFI-Careers.php#SoftwareEngineer

Some background on us: ClariFI is a small company (about 15 developers) that specializes in software for quantitative investment management. Our chief product, ModelStation, is used by portfolio managers for handling all stages of the quant process: building and backtesting of factors, portfolio optimization, simulation of trading strategies, performance and risk attribution, overall data management (including organizing huge amounts of time series data pulled from a diverse set of raw sources), and lots more. We don't expect you to have a background in finance but you should be willing and able to learn a lot once you start. 

This position is in our Boston office, so you must live or be willing to relocate here in order to be considered. If you're interested, send an email to myself or my boss, Scott McFarland (smcfarland <at> clarifi.com), along with your resume. Also, feel free to contact either of us if you just have questions about the position.

Cheers,
Paul



--
http://www.jroller.com/thebugslayer


Bruno Oliveira | 2 Dec 04:46 2008
Picon
Picon

Type Synonyms in Scala

Hello,

I am wondering why the following is not allowed in Scala:

object Test {
  trait A
  trait B

  

  type AB = A with B

  

  trait C extends AB
}

Here, the declaration for C fails with a "class type required" error. However, if I change the definition to:

trait C extends A with B

(that is, by manually copying the definition of AB) then no such error occurs. Is there any fundamental problems of using type synonyms with the extends clause? 
Can't we just consider type synonyms like these as shorthands to their definitions?

I would personally find this very convenient.

Thanks for the help!

Bruno
Geoffrey Alan Washburn | 2 Dec 10:42 2008
Picon
Picon

Re: Type Synonyms in Scala

Bruno Oliveira wrote:

> Here, the declaration for C fails with a "class type required" error. 
> However, if I change the definition to:
> 
> trait C extends A with B

But that is not the same as

   type AB = A with B

   trait C extends AB

the correct expansion/substitution would be

   trait C extends (A with B)

However, (A with B) is still not a class type.

> Can't we just consider type synonyms like these as shorthands to their 
> definitions?

As I explain above, this is already the case.  It is just that you did 
not expand away the definition in the correct fashion.

Bruno Oliveira | 2 Dec 11:59 2008
Picon
Picon

Re: Type Synonyms in Scala

Hi,

Thanks for the explanation.

On 2 Dec 2008, at 09:42, Geoffrey Alan Washburn wrote:

> Bruno Oliveira wrote:
>
>> Here, the declaration for C fails with a "class type required"  
>> error. However, if I change the definition to:
>> trait C extends A with B
>
> But that is not the same as
>
>   type AB = A with B
>
>   trait C extends AB
>
> the correct expansion/substitution would be
>
>   trait C extends (A with B)
>

Yes, you are right; it does make a difference. However, I still don't  
quite understand why this second version does not work ... What kind  
of type is something like "(A with B)" and why is it important to  
distinguish it from a type like "A" (which is a trait)?

Bruno

Geoffrey Alan Washburn | 2 Dec 12:13 2008
Picon
Picon

Re: Type Synonyms in Scala


> Yes, you are right; it does make a difference. However, I still don't 
> quite understand why this second version does not work ... What kind of 
> type is something like "(A with B)" 

(A with B) is a compound type.

> and why is it important to distinguish it from a type like "A" (which is a trait)?

It has to do with the underlying compilation model.  In the Java 
bytecode all classes must extend only classes and may only implement 
interfaces.  A type like (A with B) does not have a corresponding class 
or interface in the compiled bytecode, therefore it cannot be used as a 
parent of a class or trait in the source code.

Note that we cannot solve this problem by just generating classes and 
interfaces for all types like this, because then you run into problems 
with separate compilation because the class "backing" (A with B) in
your project may not be the same class "backing" (A with B) in my project.

There really is not much that can be done about this as long as we 
continue to target the JVM (and probably .NET as well).

Bruno Oliveira | 2 Dec 12:24 2008
Picon
Picon

Re: Type Synonyms in Scala

Ok, thanks Geoffrey. I think your answer nicely answers my questions.  
It's quite a shame that Scala needs to be that way because of the  
compilation model, but I guess that's a very small price to pay for  
all the other goodies of the JVM.

Bruno

On 2 Dec 2008, at 11:13, Geoffrey Alan Washburn wrote:

>
>> Yes, you are right; it does make a difference. However, I still  
>> don't quite understand why this second version does not work ...  
>> What kind of type is something like "(A with B)"
>
> (A with B) is a compound type.
>
>> and why is it important to distinguish it from a type like  
>> "A" (which is a trait)?
>
> It has to do with the underlying compilation model.  In the Java  
> bytecode all classes must extend only classes and may only  
> implement interfaces.  A type like (A with B) does not have a  
> corresponding class or interface in the compiled bytecode,  
> therefore it cannot be used as a parent of a class or trait in the  
> source code.
>
> Note that we cannot solve this problem by just generating classes  
> and interfaces for all types like this, because then you run into  
> problems with separate compilation because the class "backing" (A  
> with B) in
> your project may not be the same class "backing" (A with B) in my  
> project.
>
> There really is not much that can be done about this as long as we  
> continue to target the JVM (and probably .NET as well).
>
>

Ricky Clarkson | 2 Dec 12:34 2008
Picon

Re: Re: Type Synonyms in Scala

Would I be correct in saying that to support what Bruno wants without problems Scala would have to introduce its own classloader?

2008/12/2 Geoffrey Alan Washburn <geoffrey.washburn <at> epfl.ch>

Yes, you are right; it does make a difference. However, I still don't quite understand why this second version does not work ... What kind of type is something like "(A with B)"

(A with B) is a compound type.


and why is it important to distinguish it from a type like "A" (which is a trait)?

It has to do with the underlying compilation model.  In the Java bytecode all classes must extend only classes and may only implement interfaces.  A type like (A with B) does not have a corresponding class or interface in the compiled bytecode, therefore it cannot be used as a parent of a class or trait in the source code.

Note that we cannot solve this problem by just generating classes and interfaces for all types like this, because then you run into problems with separate compilation because the class "backing" (A with B) in
your project may not be the same class "backing" (A with B) in my project.

There really is not much that can be done about this as long as we continue to target the JVM (and probably .NET as well).



Geoffrey Alan Washburn | 2 Dec 12:38 2008
Picon
Picon

Re: Type Synonyms in Scala

Ricky Clarkson wrote:
> Would I be correct in saying that to support what Bruno wants without 
> problems Scala would have to introduce its own classloader?

Using a custom classloader might work.  However, based upon what Martin 
has told me, the Java classloader design is completely broken because it 
is not compositional.  Therefore, requiring a custom classloader for 
Scala programs completely rules out the ability to use Scala in a number 
of important places, like Eclipse, where an alternate classloader cannot 
be specified.


Gmane