[Haskell-cafe] consulting and contracting
Anton van Straaten
anton at appsolutions.com
Wed Dec 16 01:14:33 EST 2009
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
>> <anton at appsolutions.com <mailto:anton at appsolutions.com>> 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...
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
More information about the Haskell-Cafe