[Haskell-cafe] BPMN and BPEL

C. McCann cam at uptoisomorphism.net
Wed Sep 8 17:16:40 EDT 2010

On Wed, Sep 8, 2010 at 3:38 PM, Hector Guilarte <hectorg87 at gmail.com> wrote:
> If somebody can point out really good reasons on why I should use Haskell to
> do my work, please let me know them, they might help me convincing my
> bosses. On the other hand, if you believe Haskell is a bad language for this
> kind of task, and why C# or any other .NET language would be better, I'm
> welcome to hear your reasons, they might convince me.

Well, how comfortable are you with Haskell? If you're roughly as
proficient in it as you are in C#, you could probably bang out a
prototype using Haskell in a fraction of the time with fewer bugs.
Most software projects get massively revised from the initial version
anyway, so using a more productive language and then rewriting for the
production version can still be a net win, especially since you can
use the prototype as a specification or reference implementation
(e.g., you get some QA for free by running the two on identical input
and checking for identical output). And of course, maintenance and
scalability don't matter in a prototype.

If it goes well, you'll have proven that Haskell has value (without
forcing a long-term, up-front commitment to it), probably improved the
quality of the C# version, and gotten the chance to write Haskell at

Furthermore, in this particular case, you say it's a mapper between
data description languages. While I obviously don't know the details,
applying transformations to complex, easily-inspected data structures
is a classic example of a problem ideally suited to a functional
language with pattern matching, be it Haskell, F#, or any other
ML-influenced language--thus making Haskell even more advantageous for
rapid prototyping.

Also helpful are various Haskell-inspired features added to C# in the
last few years, making it feasible to port a large subset of Haskell
to C# fairly directly.

- C.

More information about the Haskell-Cafe mailing list