[email protected]
[Top] [All Lists]

Re: [Haskell-cafe] consulting and contracting

Subject: Re: [Haskell-cafe] consulting and contracting
From: Anton van Straaten
Date: Wed, 16 Dec 2009 01:14:33 -0500
I forgot to mention another important factor below: the fact that there are other well-known companies in the financial industry using Haskell, even if only in particular niches, makes the case quite a bit easier to make than if no-one else were known to be using it. Among other things, this makes it easier to make the case of a competitive advantage to be had -- if there were no other users, the question would be "if it's so good, why isn't anyone else using it?"
The existence of a few papers and presentations about use of Haskell use
in finance also helps.

Anton van Straaten wrote:
Gregg Reynolds wrote:
On Tue, Dec 15, 2009 at 3:19 PM, Anton van Straaten <[email protected] <mailto:[email protected]>> wrote:

    Without that advocacy, this client would have used Java by default.
     As it was, the first of


I'd be interested in how you pulled that off. Enlightened client, or slick sales pitch?
A combination of factors made it relatively easy in this case:

It was more of a quant job than a software development job, i.e. the main goal was to design and develop the model and be able to crunch the numbers, so it was solution-focused.
The choice to use Java in this case was in a sense one of last resort.
First choice would have been a tool more like Excel, Matlab, or
Mathematica, none of which were well-suited to handle the complexity and
computational requirements of this model. In this context, Haskell is a
strong contender, since it provides something similar to the
high-levelness of those mathematical tools, combined with the
performance and general programmability of a general purpose language.
There was also an assumption that the system wouldn't be needed in the
long term -- once the product was developed, they'd hire a team to
develop the necessary administration software, at which point the
original model would act as a spec. There's typically enough difference
between the requirements of these two phases for this not to be seen as
duplicate work.
(Of course, good software design would make it possible to use the same
model code for both purposes, but that's a separate issue which gets
more into questions like "...but who's going to maintain it?")
Sales pitch wise, I had previously given a brief presentation to the
client on some of the core concepts behind the Peyton Jones/Eber/Seward
financial contracts DSL, and highlighted some of the advantages Haskell
offered in that case. That laid some useful groundwork.
Finally, I had developed systems for this client previously, so there
was some history and a level of trust involved, although without some of
the above factors, this wouldn't have been enough.
Where I work I would consider it a minor miracle just to get people to consider using a wiki for collaboration.
I've experienced resistance introducing wikis before - I'd have to say
in this case, Haskell was an easier sell.
As an aside, I used the Gitit wiki as the user interface "container" for
the second model, which helped take care of things like uploading and
managing input parameter sets and data files for the model. So Haskell
systems could act as trojan horses for the introduction of wikis...
Anton

_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe
_______________________________________________
Haskell-Cafe mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/haskell-cafe

<Prev in Thread] Current Thread [Next in Thread>