[Haskell-cafe] consulting and contracting

[Anton van Straaten]

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...
> 
> Anton
> 
> _______________________________________________
> Haskell-Cafe mailing list
> Haskell-Cafe at haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe