...

I was wondering how many haskell consultants and contractors (ie. freelance programmers) there are and how much demand there is for their work.

I've done three Haskell contracts last year and this year, all in the financial industry in the New York area. Two of them were for the same client, developing a couple of modeling systems for products like swaps and bonds, and the other was an upgrade of an existing Haskell trading-related system.

Do you guys know this? http://www.rentacoder.com I wonder if hackage 2.0 could be made into such a thing for Haskell developers :) Best, Maurício

Paul Johnson wrote:

On 15/12/09 21:19, Anton van Straaten wrote:

...

Without that advocacy, this client would have used Java by default. As it was, the first of those two systems was developed in parallel with a Java version, and we used the two versions to verify each other's results. For the second system, a Java version wasn't deemed necessary, partly because the comparison succeeded in making Haskell's advantages sufficiently clear.

Can you give us some more details on this dual-language project? I'm trying to collect objective evidence of the relative advantages of Haskell and Java (or any other languages) and this kind of comparison is gold dust. Very few companies are prepared to develop the same system twice.

SLOC counts are good objective evidence (preferably from a standard SLOC counter such as http://www.dwheeler.com/sloccount/). Days of effort in development and defect counts are also powerful (although more subject to random noise: give several developers the same job and developer effort seems to vary even more than SLOC). Also any specific anecdotes about changed requirements, defects discovered by QuickCheck can also be useful. They are not objective evidence, but people listen to stories more readily than statistics.

This project wasn't a controlled experiment, so even an SLOC comparison would require some effort, since there were various differences between the two versions. E.g., the Java version generated PDF output for investor consumption, whereas the Haskell version provided a web interface for internal use. One of the initial goals of the Haskell version was as a way to provide a cross-check for the Java version with relatively low effort. Because of that, the Haskell version initially had no user interface, other than GHCi, and running a test involved writing code to set up the necessary input. As a result, the development of the two versions had quite different trajectories. The Haskell version did uncover a number of bugs in the Java version, and there were at least a couple of cases where the reverse occurred, as well as a few cases in which a discrepancy revealed some issue with the specification. I'd have to trawl through old records to get actual counts. My memory is that QuickCheck only discovered one real bug, in some custom date handling code. However, I didn't use QuickCheck all that much, since the emphasis was on the cross-check with the Java version. Working on the project, it was fairly easy to see the advantages Haskell had, but documenting that objectively requires more effort. Agility was certainly one of the advantages, since the specification of the model was being developed along with the code, partly in response to the results produced by the code. Some detailed comparison of source code might reveal some interesting differences, but I don't have access to the Java code at present (although getting access is not out of the question.)

Of course if you can reveal the client's name that would also be very useful, for the same reason. But I understand that may not be possible.

The name isn't one that people would recognize. They currently have active deals under development, and assuming some of those complete in 2010, I should be able to talk more about specifics. Anton

Gregg Reynolds wrote:

On Tue, Dec 15, 2009 at 3:19 PM, Anton van Straaten mailto:anton@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

2009/12/15 Anton van Straaten :

My sense is that at the moment, with a few exceptions, anyone wanting to do freelance Haskell work would need to advocate its use themselves, or use it in situations where the client is more focused on the solution than the language used.

I've done one Haskell contract this year, for legal document processing. This was a case where the client was definitely "more focused on the solution than the language used" and really cared a lot more about a good CLI and clearly defined output for each processing step. -- Jason Dusek