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