[Haskell-cafe] consulting and contracting
Anton van Straaten
anton at appsolutions.com
Tue Dec 15 18:30:27 EST 2009
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
> 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
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.
More information about the Haskell-Cafe