Multithreaded stateful software
Often I've found that quite how wonderful a programming language is isn't clear until you've used it for a non-trivial project. So, I'm still battling on with Haskell. One of the projects I have coming up is a multi-threaded server that manages many clients in performing a distributed computation using a number of computers. So, we care about state, and control flow has some concurrent threads and is partially event-driven. Some possibilities come to my mind: (a) This really isn't what Haskell was designed for, and if I try to write this in Haskell I'll never want to touch it again. (b) This project is quite feasible in Haskell but when it's done I'll feel I should have just used Java or something. (c) Haskell's monads, concurrency stuff and TCP/IP libraries are really quite powerful and useful, and I'll be happy I picked Haskell for the task. Does anyone have any thoughts? (-: I have a couple of symbolic computation tasks too that use complex data structures, which I'm sure that Haskell would be great for, but I want it to be more generally useful than that because, although it's nice to always use the best tool for the job, it's also nice not to be using too many languages in-house. -- Mark
Mark Carroll wrote:
One of the projects I have coming up is a multi-threaded server that manages many clients in performing a distributed computation using a number of computers. [...]
(a) This really isn't what Haskell was designed for, and if I try to write this in Haskell I'll never want to touch it again.
(b) This project is quite feasible in Haskell but when it's done I'll feel I should have just used Java or something.
(c) Haskell's monads, concurrency stuff and TCP/IP libraries are really quite powerful and useful, and I'll be happy I picked Haskell for the task.
There's also: (d) You end up learning all sorts of new things about distributed processing (as well as Haskell) and, armed with the new knowledge, future problems of the same nature will be easier to solve no matter what language you use. That's what usually happens to me. (Personally, if I had this project coming up, I'd use it as an excuse to finally learn Erlang...) --Joe English jenglish@flightlab.com
Mark Carroll
One of the projects I have coming up is a multi-threaded server that manages many clients in performing a distributed computation using a number of computers. So, we care about state, and control flow has some concurrent threads and is partially event-driven.
Some possibilities come to my mind:
(a) This really isn't what Haskell was designed for, and if I try to write this in Haskell I'll never want to touch it again.
(b) This project is quite feasible in Haskell but when it's done I'll feel I should have just used Java or something.
(c) Haskell's monads, concurrency stuff and TCP/IP libraries are really quite powerful and useful, and I'll be happy I picked Haskell for the task.
In my experience features such as Haskell's type system and the ease with which you can handle higher-order functions are extremely useful in code that has to deal with state and concurrency. I guess, the main problem with using Haskell for these kinds of applications is that relatively little has been written about them yet. SimonPJ's paper "Tackling the awkward squad" and SimonM's Web server improved the situation, but, for example, none of the Haskell textbooks covers these features. Nevertheless, there are quite a number of people now who have used Haskell in ways similar to what you need. So, don't hesitate to ask on this or other Haskell lists if you have questions or need example code. Cheers, Manuel
participants (3)
-
Joe English -
Manuel M. T. Chakravarty -
Mark Carroll