[Haskell-cafe] Interoperability with other languages and haskell in industry

[Vincenzo aka Nick Name]

On Thursday 16 September 2004 20:27, Andy Moran wrote:
> I'd like to say that this approach has worked for us time and time
> again, but, to date, we've never had to rewrite a slow component in C
> :-)  For us, C interoperability has always been a case of linking to
> third party software, or for writing test harnesses to test generated
> C.
>

The point is that perhaps we will not have a prototype but a single 
implementation (not that I think it's a good idea in the general case, 
but we will write a relatively simple bookkeeping application). However 
I realize that one can write a great part of the software in a single 
language. The point is providing an escape to java, C++, C#, python or 
other in vogue languages in case we find that it's difficult to 
interface with legacy systems, or we don't find a coder to hire in the 
future. So the point is not to rewrite something in C for efficiency, 
but rather to be able to say "ok, this component is written in haskell 
and will stay this way, but the rest of the system won't be haskell 
anymore". However:

> Things are different if your application is multi-process and/or
> distributed, and you're not going to be using an established protocol
> (like HTTP, for instance).  In that case, you might want to look at
> HDirect (giving access to CORBA, COM, DCOM), if you need to talk to
> CORBA/COM/DCOM objects.  There are many simple solutions to RPC
> available too, if that's all you need.

I see that there is for example xmlrpc that should fit my little 
interoperability needs, and would have liked to hear some experience on 
that route. Your reply is incouraging, though, since you didn't need 
any other language at all. That's my hope, too.

Bye and waiting for that other famous hakell-using company that I didn't 
mention to attend this discussion :)

Vincenzo