Hi Heribert,

The questions they are asking include:

* Are there any references for using Haskell in industry?

Every project (bar two) that Galois has ever done has used Haskell. We've delivered tools, written in Haskell, to clients in industry and the U.S. government that are being used heavily. Three examples: Cryptol, our DSL for cryptography (with an interpreter and a compiler); a GUI debugger for a specialized chip, and a tool for easily embedding new syntax in the client's own language (sort of a suped-up Happy + OCaml's P4). As for references, as I write this, I'm also writing a talk for the Commercial Uses of Functional Programming (CUFP) workshop, entitled "Haskell in an Industrial Context" :-) (CUFP will be held this Saturday in conjunction with ICFP.) My talk focuses on the challenges that Galois' faces due to our use of Haskell, and some ways we (with lots of help) might overcome those challenges.

* Can Haskell code be integrated with .NET, in case the department should decide to base more of its software on this platform?

I'll let others handle this one in more detail, but I believe Sigbjorn ported his Hugs .NET support to GHC too.

* Will Haskell programmers be available 5 years from now to do the rather boring work of maintaining a then-legacy system?

This a fair question, and one we've been asked. So far the only answer we've come up with is "We sure hope so". It does seem likely, given that Haskell is being taught in lots of Universities. But what if Simon and Simon decide they'd rather build C# compilers? There's a gathering momentum in the Haskell community, but would it be enough? This is one of the biggest worries for the viability of Haskell in the long term.

* Can't much of the simplicity of the Haskell code also be reached by just switching from C++ to something like Java or C#?

It depends on how you quantify "much". There are benefits to moving to Java or C# from C++ (cleaner type systems, cleaner semantics, better memory management support). But languages like Haskell give you a lot more besides: they're much higher level, so you get more productivity, you can express more complex algorithms, you can program and debug at the "design" level, and you get a lot more help from the type system. These arguments have been made time and again though, and they're also pretty subjective. At Galois, it's also a big bonus that Haskell is close to its mathematical roots, because our clients care about "high assurance" software. High assurance software development is about giving solid (formal or semi-formal) evidence that your product does what it should do. The more functionality provided, the more difficult this gets. The standard approach has been to cut out functionality to make high assurance development possible. But our clients want high assurance tools and products with very complex functionality. Without Haskell (or some similar language), we wouldn't even be able to attempt to build such tools and products. Cheers, Andy -- Andy Moran Ph. (503) 626 6616, x113 Galois Connections Inc. Fax. (503) 350 0833 12725 SW Millikan Way, Suite #290 http://www.galois.com Beaverton, OR 97005 moran@galois.com

On Tuesday 14 September 2004 18:18, Heribert.Schuetz.extern@HVB.de wrote:

*       Can't much of the simplicity of the Haskell code also be reached by just switching from C++ to something like Java or C#? (Probably an example from the application domain will be most convincing. So I probably have to bite the bullet and reimplement some code in Java or C#. But if you have some examples, they might be helpful.

I don't have examples but I've been working with C# 8 hours per day for 6 months and I ensure you that no, they are not simple. C++ is simpler for enterprise uses than C#, IMHO, because you fundamentally reuse other people libraries and so worry _less_ about memory management than you'd expect, but YMMV. On the other hand, C# has NO parametric polymorphism and after a while I've begun to miss C++ templates. C# has functional programming, they say, but no you can't use a method name as a function. You first have to create an "event". Composing this with the absence of parametric polymorphism and type inference, here's what a _monomorphic_ "map" function looks like, with a possibly naive syntax because I don't have the compiler handy (and worked 8 hours today,too). ///// public delegate int myDelegate(int i); //This is a type declaration public ArrayList map(myDelegate fn,ArrayList list); // Note that the list is untyped, but the function is strongly typed. { ArrayList result = new ArrayList(); foreach (Object obj in list) { result.Add(fn(obj)); } return result; } ///// 6 rows of effective code, untyped, contrived and poorly reusable. And this is the way you call it (you already know, ok, but now I am having fun :)) public int increment(int i) { return i+1; } map(new myDelegate(increment),myList); // note the call to "new" The map function from the haskell prelude: map f xs = [f x | x <- xs] and how you call it: map (\ x -> x+1) myList It's strongly typed, polymorphic and reusable. And it's far more readable and clear in intent, too. Do I need to say more? If you have the possibility to use haskell, ocaml or SML at work, do so :) OK, I realize that you already knew haskell, but you asked first :) Vincenzo