Re: [Haskell-cafe] Interoperability with other languages and haskell in industry
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 ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Interoperability with other languages and haskell in industry
Again, I will try to take benefit of the thread on the senior list to ask a question to everybody who uses haskell in industry (so you people at Galois Connection can't avoid to answer, I know you are there :D ): are your solutions entierely written in haskell, or are there parts written in other languages? If so, how do you let all parts interoperate? Do you use some form of RPC, or CORBA, do you just use a database to store common data, do you use custom protocols (e.g. command line arguments) or what? Do you have experience with wrong ways to achieve this goal? I ask this because it might be that in the next years our sleeping company will produce some software, and I can easily convince other people to use new languages, if I can ensure them that in case it proves difficult for any reason, we can finish with a certain module and implement the rest of the system using more conventional technologies. Thanks Vincenzo ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interoperability with other languages and haskell in industry
On Thursday 16 September 2004 02:46 pm, Vincenzo aka Nick Name wrote: Again, I will try to take benefit of the thread on the senior list to ask a question to everybody who uses haskell in industry (so you people at Galois Connection can't avoid to answer, I know you are there :D ): are your solutions entierely written in haskell, or are there parts written in other languages? If so, how do you let all parts interoperate? Do you use some form of RPC, or CORBA, do you just use a database to store common data, do you use custom protocols (e.g. command line arguments) or what? Do you have experience with wrong ways to achieve this goal? Almost all of our projects are written entirely in Haskell. The reminder use the excellent GHC FFI mechanisms to call out to C, and in one case, Tcl (via TclHaskell). We don't develop multi-process applications, distributed or otherwise, so we have no need for RPC or more complex middleware(*), or other more baroque solutions. I ask this because it might be that in the next years our sleeping company will produce some software, and I can easily convince other people to use new languages, if I can ensure them that in case it proves difficult for any reason, we can finish with a certain module and implement the rest of the system using more conventional technologies. Here's what you say: Let's prototype it in Haskell, and then replace any performance bottlenecks with C. For some application areas (like tools), you won't have to bother with the last step. If you do need to rewrite some component in C, the FFI is there to help. 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. 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. Cheers, Andy (*) We have prototyped our own secure middleware, which had an elegant, powerful, class-based RPC for Haskell processes, but we haven't really used that in other projects. -- 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[EMAIL PROTECTED] ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
