<div>Thank you for your advice, </div><div><br></div>Actually, I'm not comfortable with C# at all... I'm gonna be learning it as I develop<div>the application.</div><div><br></div><div>> Also helpful are various Haskell-inspired features added to C# in the</div>
<div>> last few years, making it feasible to port a large subset of Haskell<br>> to C# fairly directly.</div><div><br></div><div>What kind of features are those you mention? I'd like to know in advance in order</div>
<div>to search them before I start to do anything, even if I'm not going to use Haskell,</div><div>knowing those features might help me to get a high level of abstraction in C# (or not).<br><br><div class="gmail_quote">
On Wed, Sep 8, 2010 at 4:46 PM, C. McCann <span dir="ltr"><<a href="mailto:cam@uptoisomorphism.net" target="_blank">cam@uptoisomorphism.net</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div>On Wed, Sep 8, 2010 at 3:38 PM, Hector Guilarte <<a href="mailto:hectorg87@gmail.com" target="_blank">hectorg87@gmail.com</a>> wrote:<br>
> If somebody can point out really good reasons on why I should use Haskell to<br>
> do my work, please let me know them, they might help me convincing my<br>
> bosses. On the other hand, if you believe Haskell is a bad language for this<br>
> kind of task, and why C# or any other .NET language would be better, I'm<br>
> welcome to hear your reasons, they might convince me.<br>
<br>
</div>Well, how comfortable are you with Haskell? If you're roughly as<br>
proficient in it as you are in C#, you could probably bang out a<br>
prototype using Haskell in a fraction of the time with fewer bugs.<br>
Most software projects get massively revised from the initial version<br>
anyway, so using a more productive language and then rewriting for the<br>
production version can still be a net win, especially since you can<br>
use the prototype as a specification or reference implementation<br>
(e.g., you get some QA for free by running the two on identical input<br>
and checking for identical output). And of course, maintenance and<br>
scalability don't matter in a prototype.<br>
<br>
If it goes well, you'll have proven that Haskell has value (without<br>
forcing a long-term, up-front commitment to it), probably improved the<br>
quality of the C# version, and gotten the chance to write Haskell at<br>
work.<br>
<br>
Furthermore, in this particular case, you say it's a mapper between<br>
data description languages. While I obviously don't know the details,<br>
applying transformations to complex, easily-inspected data structures<br>
is a classic example of a problem ideally suited to a functional<br>
language with pattern matching, be it Haskell, F#, or any other<br>
ML-influenced language--thus making Haskell even more advantageous for<br>
rapid prototyping.<br>
<br>
Also helpful are various Haskell-inspired features added to C# in the<br>
last few years, making it feasible to port a large subset of Haskell<br>
to C# fairly directly.<br>
<font color="#888888"><br>
- C.<br>
</font></blockquote></div><br>
</div>