
Hello, Does anybody knows if there is some work related to BPMN and/or BPEL done in Haskell? Maybe some research or some papers? I'm about to begin a mapper from BPMN to BPEL and Haskell is my first option for doing it, but since my company is somehow married to .NET and nobody else knows anything about Functional Programming or Haskell, using it might be a problem for maintenance and scalability. 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. I know about F#, but the "problem" is not that Haskell is not .NET, the "problem" is that it is functional programming and as I said before, nobody here knows a bit about it. If I were to do it using FP, I would use Haskell for sure, not F#. Thank you very much, Héctor Guilarte

On Wed, Sep 8, 2010 at 3:38 PM, Hector Guilarte
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 work. 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.

Thank you for your advice, Actually, I'm not comfortable with C# at all... I'm gonna be learning it as I develop the application.
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.
What kind of features are those you mention? I'd like to know in advance in
order
to search them before I start to do anything, even if I'm not going to use
Haskell,
knowing those features might help me to get a high level of abstraction in
C# (or not).
On Wed, Sep 8, 2010 at 4:46 PM, C. McCann
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
On Wed, Sep 8, 2010 at 3:38 PM, Hector Guilarte
wrote: 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 work.
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.
participants (2)
-
C. McCann
-
Hector Guilarte